Edra landed Sequoia, HubSpot, and Asos by mapping processes before pitching product – most AI startups have the order exactly backwards.
ENTRY ANGLES
Platform to make forward-deployed engineering more efficient and scalable · Infrastructure for automatically building knowledge bases from documentation and process observation · Tools helping employees systematically hand off workflows to AI agents
VERTICALS
CAPABILITIES
Business process mapping and codification, Knowledge extraction and documentation automation, AI agent workflow integration
EDRA FOUNDER
“Trading Margin for Moat: Why Forward Deployed Engineers Became the Hottest Job in Startups.”
Edra emerged from nowhere with $30 million from Sequoia Capital and a handful of other prominent funds – plus early clients including HubSpot and Asos.
On the surface, Edra built a business process automation platform – a crowded category. But the specific product it built is different: a platform that teaches itself how a client's business works, then automates accordingly.
Setup begins by connecting Edra to all of the company's knowledge sources – not just documented procedures and process guides, but logs, messages, support tickets, and anything else that reflects how the business actually operates. Edra's AI analyzes this entire corpus and constructs a working knowledge base on its own.
From that point on, whenever any employee has a question, Edra doesn't just answer it – it executes the appropriate sequence of actions: sending a Slack message, logging something in the company database, or performing whatever step the company's established process calls for.
But Edra's real differentiator is that it keeps learning:
- If it's uncertain how to handle a request, it asks the right people and adds the answer to the knowledge base.
- If it encounters a non-standard situation, it watches how employees resolve it and documents a new process from what it observes.
- If it discovers that an established procedure is now being handled differently in practice, it updates the relevant sections of the knowledge base on its own.
A key part of the sales motion: Edra can be deployed on a single workflow within one week – enough to demonstrate the technology and prove a measurable productivity gain before any broader commitment.
Edra's founders previously led Palantir's Forward Deployed Engineers program – specialists embedded directly inside client organizations to adapt Palantir's technology to each customer's specific workflows.
This method, which Palantir pioneered, is widely credited as a major driver of its success. But the work was genuinely difficult and labor-intensive. Deployed engineers had to manually map out how clients actually operated, then track every process change that inevitably emerged over time.
The hardest part of the deployment, it turned out, wasn't the technology itself – it was extracting operational knowledge from employees who had never had to put into words what they actually do.
For context: Nixo ([related review](/review/chem-glubzhe-potrahaeshsja-tem-bolshe-zarabotaesh)), a recent Y Combinator graduate, is building a platform specifically to reduce this burden through partial automation of the knowledge extraction process.
Palantir has used deployed engineers for years. But in 2024, the model suddenly became the hottest topic in enterprise software – enough for Andreessen Horowitz to publish a piece titled "Trading Margin for Moat: Why Forward Deployed Engineers Became the Hottest Job in Startups."
The logic: deployed engineers represent an incremental cost for software vendors. But they allow vendors to embed their products so deeply into client workflows that switching becomes genuinely painful – creating durable competitive protection.
AI models have become sophisticated enough to write code and solve advanced math problems. But the value of AI inside enterprises isn't determined by raw capability – it's determined by how well the AI understands how that specific business works.
Companies may have extensive documentation. But most institutional knowledge isn't in documents – it lives in people's heads, and deployed engineers exist precisely to extract it. Moreover, whatever's in those documents is often outdated – partially correct, partially obsolete.
Most enterprise AI vendors tell companies: "Give us your process documentation and we'll build agents that follow it." But having documentation that's current, complete, and internally consistent is already 90% of the work involved in building those agents. The remaining 10% of technical implementation a capable team can handle on its own.
So the first problem is creating and maintaining process documentation that's actually accurate and complete.
The second problem is keeping it updated when reality drifts from the spec, or when gaps and contradictions surface.
That's why the most important component of Edra isn't the agent orchestration layer – it's the system that teaches agents the client's business in the first place.
Edra's agents learn from existing documentation, observation of live workflows, and structured conversations with employees. They don't simply accept what they're told, because any given input may be incomplete or contradictory. The platform cross-references information, runs simulations, and compares its conclusions against what's actually happening in practice before updating the knowledge base.
When reality and the knowledge base diverge again later, the system identifies why and updates accordingly – keeping the knowledge base accurate, complete, and consistent as the business evolves.
What makes this most interesting is that it reflects a broader shift: in the AI era, every employee is effectively becoming a teacher.
The primary contribution of each employee is no longer to do the work themselves – it's to teach the AI how to do it instead.
"Forward deployed engineers" and "every employee becomes an AI teacher" are two sides of the same coin. Whether the knowledge extraction comes from outside specialists or internal staff, the core challenge is identical: figuring out how a company actually operates, and codifying that understanding so AI can act on it.
Two directions toward the same goal:
From the outside in – deploying your own engineers to embed your products deep inside client operations, and building platforms that make forward-deployed engineering more efficient and scalable.
From the inside out – building infrastructure that lets employees transfer their expertise to AI. This includes platforms for automatically building knowledge bases from existing documentation and process observation, as well as helping employees systematically hand off their workflows to AI agents.
Or both simultaneously – as Edra does: lightening the burden on deployed engineers while helping employees directly transfer their knowledge to the platform.
This is a large space with many entry points. The unifying principle: focus on business processes, not technology. Technology is the enabler; process understanding is the actual value.
Which angle would you approach from?