Putting a senior engineer inside a customer can look like expensive consulting with a better job title. The forward deployed engineering business model places a forward deployed engineer (FDE) inside the customer's workflow, and it only becomes something other than consulting when that engineer makes every later deployment easier.
That means running two loops at once. The delivery loop takes one customer from workflow discovery to a working production system. The compounding loop turns what the team learns into reusable context infrastructure, evaluations, connectors, workflow modules, and operating playbooks.
Distyl, Ode, Tribe AI, and Ciridae all use embedded engineering in different forms, according to their own descriptions of how they work (Distyl, Ode, Tribe AI, Ciridae). The investment question is not whether their engineers sit close to the customer. It is whether revenue can grow faster than the senior labor required to deliver it.
Proximity alone is not the moat. Reuse is.
Key takeaways
- A forward deployed engineer (FDE) owns discovery, engineering, integration, deployment, and adoption inside the customer's environment instead of delivering advice or a proof of concept.
- The forward deployed engineering business model compounds only when reusable context, evaluations, connectors, and playbooks cut the senior hours each new deployment consumes.
- Brain Co. reports that its deployed engineers spend roughly 70% of their time on engineering, 20% on client management, and 10% on other work (Brain Co.).
- Recurring revenue is not one thing at an FDE firm: software licenses, support, and managed operation carry different gross margins and different labor loads.
- Trade reporting describes Distyl's fees as linked to measurable outcomes, while most forward deployed engineering firms publish no pricing and no recurring revenue mix at all (Channel Dive).
FDE Is a Delivery System, Not a Job Description
The title tells you almost nothing. The handoffs tell you everything.
The structure has a traceable origin. Palantir separated field engineers from headquarters product engineers, and Bob McGrew, the Palantir executive credited with pioneering that split before becoming Chief Research Officer at OpenAI, described the approach on Y Combinator's podcast as doing things that do not scale, at scale (clip on X). One working FDE recounts that venture investors read it as a services business for most of the following decade, until Palantir's 2020 initial public offering (IPO) settled the question for Palantir (video interview). Every firm copying the structure has to win that argument again on its own numbers, and that is the test running through the companies building the enterprise AI implementation layer.
The conventional chain
A conventional enterprise project passes through strategy, requirements, solution design, engineering, integration, change management, and support. Each group sees a different version of the problem. The strategist hears what management wants. The engineer discovers what the data permits. The operator finds the exceptions after launch.
Every handoff loses context. It also gives each team a clean excuse when the system misses the business outcome.
The FDE chain
A forward-deployed team compresses that chain into one accountable unit:
- It shadows operators and subject-matter experts to find the real workflow.
- It builds against live data, legacy systems, security constraints, and exception rules.
- It deploys, evaluates, monitors, and changes the production system.
- It stays responsible for adoption and the agreed operating result.
Brain Co. gives the clearest public breakdown. Its deployed engineers say their work averages roughly 70% engineering, 20% client management, and 10% other work. The role spans user research, product development, integrations, deployment architecture, evaluations, error analysis, and data access. Those percentages are company-reported, but the task list is unusually concrete (Brain Co.).
The other firms describe the same accountability from different angles. Distyl says forward-deployed engineers and researchers work with purpose-built products and own the outcome (Distyl). Tribe's Map, Build, Activate sequence keeps engineers involved from problem selection through production and adoption (Tribe AI). Ode says it works from roadmap through deployment and stays involved after code delivery (Ode).
A forward deployed engineer combines discovery, product engineering, integration, production deployment, and operational adoption inside the customer environment, with responsibility that extends beyond advice or a proof of concept.
The commercial implication is sharper than the job title. The customer buys fewer interfaces and one line of accountability. The provider accepts a wider delivery surface, from technical performance to user behavior, which justifies premium fees and exposes it to delays it does not control. The contract has to separate what the FDE owns from what belongs to the customer's data, security, and operating teams.
That boundary, not the title on a business card, defines the model, and it belongs in the contract before work begins.
Why Enterprise AI Pulls Engineers Into the Field
Better foundation models do not remove the fieldwork. Once artificial intelligence (AI) touches a core workflow, the model is rarely the final bottleneck.
Context is local
The useful knowledge lives in policy documents, databases, inboxes, spreadsheets, old applications, and the judgment of employees who know which rules can bend. Two companies can use the same model for contract review and need completely different systems because their definitions, approvals, and liabilities differ.
Distyl built Distillery around this problem. Its published architecture has a context layer that lets subject-matter experts define, refine, and govern the knowledge used by applications, while retaining lineage back to the source. Distyl says later use cases can inherit context and governance from earlier work. That compounding claim is first-party, but it identifies the asset that matters (Distyl).
Reliability is operational
A generic benchmark cannot tell you whether an agent will process a disputed invoice, escalate a vulnerable customer, or interpret a legacy contract safely. Evaluations must use production data, real edge cases, human review rules, and the customer's tolerance for error.
Brain Co.'s engineers describe long-tail error analysis and evaluations as part of the job, not a testing phase that ends at launch (Brain Co.). That matters because the final percentage of exceptions often contains the financial and regulatory risk.
Practitioner accounts point at the same tail. Pankaj Jaiswal, a forward deployed engineer at SuperVity, described a document workflow running at roughly 10,000 invoices a day for the cement manufacturer Adani Cements, with about 68% completed without a human touching the case (video interview). That is one engineer's account of one deployment rather than audited data, and the remainder is the part worth underwriting. The cases that still reach a person are where the disputes, the regulators, and the margin sit.
Adoption changes the product
Embedded engineers see where staff bypass the new system, which data owners block access, and when an agent should assist rather than automate. They can redesign the human process while changing the software.
Ode's leadership makes a similar distinction between choosing a model and doing the systems engineering required for a production deployment. TechCrunch reported that the firm is Claude-first but not Claude-exclusive because the implementation problem extends beyond the model itself (TechCrunch).
The field is therefore not an inconvenient step before the product. It is where the product requirements are found. A demo proves only that a model can produce a plausible answer under chosen conditions. Production needs permissions, retrieval, audit trails, exception routing, cost control, monitoring, and someone willing to own the bad cases, and every one of those requirements comes out of the customer's operating environment.
How an FDE Engagement Makes Money
Three firms can deliver the same workflow and still have completely different economics. One sells a project, one licenses software with implementation, and one keeps operating the workflow after launch.
Typical revenue stages
The commercial path usually contains four stages:
- A discovery engagement or transformation roadmap identifies a measurable workflow.
- A paid wedge proves that the system works on real data and reaches production.
- A broader deployment adds integrations, governance, training, and adjacent workflows.
- Ongoing support, managed operation, or platform expansion creates recurring revenue.
That is a conceptual sequence, not a claim that every provider prices each stage separately.
Known public signals
Distyl offers the clearest reported signal. Channel Dive describes a hybrid platform-and-services model with compensation linked to measurable outcomes, but exact formulas and contract terms are not public (Channel Dive).
Tribe and Aivar publish implementation offers through the Amazon Web Services (AWS) Marketplace, which supports project and private-offer buying rather than transparent per-seat pricing (Tribe listing, Aivar listing). Invisible Technologies is an adjacent managed-operations benchmark. In one company-published case, it kept human experts in dispute handling, built two automations, expanded to five departments, and reported a 10x return. The outcome is first-party and not independently audited (Invisible). Ode and Ciridae do not publish detailed commercial terms.
What outcome pricing requires
Outcome pricing only works when the parties agree on a baseline, a measurable key performance indicator (KPI), attribution, the provider's control over delivery, and how risk is shared. A provider cannot sensibly guarantee cycle time if the customer controls data access, staffing, and approvals.
Read that waterfall in operational terms: pay for discovery, release more value at production, expand when the KPI moves, then charge for the platform or the continuing operation. The percentages belong in the contract, not in a market article.
I would also separate recurring revenue by what actually recurs. A software license can carry high incremental margin. Support recurs but still consumes specialist time. Managed operation retains well because the provider sits inside the workflow, yet it carries staffing, quality, and exception costs. All three are valuable and none of them deserves the same gross-margin assumption, so ask for revenue and delivery cost by layer before calling the model recurring.
Renewal alone does not prove attractive incremental economics.
What Compounds: The Intellectual Property Flywheel Behind the Engineers
If project ten needs the same senior hours as project one, the intellectual property (IP) has not compounded. A polished interface does not change that.
Five reusable asset classes
The reusable layer normally falls into five buckets:
- Context and semantic infrastructure that maps institutional knowledge to decisions.
- Evaluation, observability, audit, and governance components.
- Connectors, deployment templates, identity controls, and production infrastructure.
- Vertical workflow modules, exception patterns, and human approval designs.
- Talent selection, training, delivery methods, and post-launch playbooks.
Each asset should make a later engagement faster, cheaper, safer, or less dependent on a scarce individual.
What the companies appear to productize
Distyl has the clearest named horizontal layer. Distillery covers context, autonomous solution delivery, control, and application delivery, and Distyl says each use case inherits prior context and governance (Distyl).
Ciridae productizes vertically. It says proprietary kits, production infrastructure, and industry playbooks let its teams build workflow software in weeks and make each deployment faster than the last. That is a company claim, not disclosed deployment-cohort data (Ciridae).
Tribe's reusable system includes talent supply. The company acquired recruiting partner Candor in May 2026 to internalize the recruiting and staffing of forward-deployed engineers. Tribe says it had doubled its team since January and employed more recruiters than salespeople; no transaction price was disclosed (Tribe AI).
Ode has strong engineering talent and unusual access to Anthropic's Applied AI resources, but it does not publicly document a named horizontal platform comparable with Distillery or Brain Co.'s Atlas (Ode). That may change. For now, the public evidence supports a people, access, and distribution moat more strongly than a software one. That reading comes straight out of Ode's production engineering model with Anthropic.
The compounding test
Ask three questions after every deployment: What will be reused? What should cost less next time? What remains irreducibly customer-specific? If the answers are vague, the platform is probably a collection of projects.
The best proof is cohort behavior. Deployment four should reuse more tested components than deployment one, a mid-level team should absorb more of the standard work, and monitoring should arrive as infrastructure rather than a fresh design exercise. A provider that can also name what will never standardize, such as institution-specific decision rights or regulated approvals, makes the reusable layer more credible, not less.
Where the Model Falls Back Into Consultancy Economics
An FDE firm can grow quickly and become harder to operate with every new customer. Demand can hide the problem for years.
The labor traps
The model falls back into conventional consultancy economics when:
- Every workflow becomes a snowflake.
- Only senior engineers are trusted to discover and ship.
- Knowledge stays in individual heads or customer repositories.
- Change management expands without recurring fees.
- Outcome promises exceed what the provider controls.
At that point, growth requires more hiring, utilization management, and delivery supervision. The business may still be excellent. It simply has service economics and should be priced, managed, and valued as such.
Engineers can smell that outcome in the job posting. In an r/ExperiencedDevs thread on the sudden wave of FDE openings, one senior developer summarized the role as consulting with a futuristic name (r/ExperiencedDevs thread). That is sentiment from one thread, not evidence about any firm, and the instinct is aimed at the wrong object. The label is old. What is new, when anything is, sits behind the person: the components, evaluations, and playbooks the next deployment inherits.
The talent bottleneck
Ode makes the constraint visible. TechCrunch reported roughly 100 engineers and quoted leadership discussing the difficulty of preserving boutique quality during rapid growth (TechCrunch). Tribe's purchase of Candor shows a different response: own more of the recruiting system that supplies the delivery model (Tribe AI).
Neither signal proves weak economics. Both show that talent supply is part of the production function, not a back-office concern, a pattern visible across three contrasting deployment engines.
Demand for the title is also running ahead of the people who have shipped one. A technology education channel claimed, citing job-posting data it reviewed on camera, that FDE openings are up more than 1,000% year over year with New York overtaking San Francisco as the largest hub (video breakdown). That is a content claim, not a measured statistic, and the hiring direction it implies remains unverified. What it does capture is the framing: the constraint in this market is delivery capacity, not model quality.
Warning metrics
I would watch utilization pressure, project duration by cohort, senior hours per launch, component reuse, expansion without a fresh statement of work, founder involvement, and recurring ownership after go-live. These are diligence indicators, not disclosed problems at Ode, Tribe, or any other named firm.
I would also separate customer satisfaction from productization. A brilliant team can rescue bespoke deployments and build strong references while making no progress on marginal labor. High-quality consulting is not failed software. Confusing the two creates failed underwriting.
There is a second trap: mistaking utilization for efficiency. High utilization can lift short-term profit while leaving no time to turn project learning into products, and low utilization can mean weak demand or deliberate investment in shared tooling. Read billable percentage against product investment, time to production, and expansion. A compounding firm may sacrifice utilization this quarter to cut the labor cost of the next cohort.
Watch support as closely as implementation. If every production system creates a permanent queue of bespoke fixes, the labor liability has only moved from the project team to the support team.
Embedding is not the moat. Learning faster than the labor base grows is.
The FDE Scorecard for Founders, Buyers and Investors
Eight questions can reveal whether an FDE model is a strong service business or a compounding platform.
| Question | Evidence to request | Healthy signal | Warning signal |
|---|---|---|---|
| What is the first production wedge? | KPI, baseline, owner, deadline | Narrow workflow tied to value | Broad transformation mandate |
| How fast does it reach production? | Cohort deployment times | Later cohorts get faster | Timelines keep expanding |
| How many senior hours does it need? | Hours by role and phase | Senior input declines | Every launch needs the same experts |
| What gets reused? | Component and code map | Named modules with usage data | Generic claims about a platform |
| Who owns the system after launch? | Support and operation clauses | Clear handoff or recurring scope | Accountability ends ambiguously |
| How does pricing match value? | KPI and fee schedule | Provider control matches risk | Outcome fee without attribution |
| What revenue recurs? | Software, support, and managed mix | Expansion without full rebuild | New statements of work drive all growth |
| How does talent improve? | Training and promotion data | Broader bench ships reliably | Founders remain critical to delivery |
Founder lens
Instrument deployment effort from the first project. Track reused components, exceptions, senior hours, support load, and time to the first production KPI. Distyl, Tribe, Ciridae, and Ode all describe close customer involvement, but their public pages do not provide the cohort economics needed to judge marginal delivery cost (Distyl, Tribe, Ciridae, Ode).
Buyer lens
Put the production milestone, evaluation set, security responsibilities, handoff, monitoring, and human escalation path into the statement of work. Ask which parts already exist and which are being invented for you.
Investor and acquirer lens
Request revenue mix, gross margin by work type, utilization, expansion, concentration, and deployment cohorts. Check whether support cost falls as the installed base grows, and whether expansions reuse the original evaluation set and integrations instead of restarting discovery. A service can be valuable without becoming software. The mistake is paying for software economics before the delivery data exists.
For related analysis, see AI pricing models for MSPs and the vendor scorecard template.
FAQ
A forward deployed engineer works inside a customer's operational context from discovery through production, covering user research, full-stack engineering, integrations, evaluation, deployment, error analysis, and adoption. Brain Co.'s engineers describe that unusually broad mix in their account of the role (Brain Co.).
A solutions engineer usually helps a customer evaluate, configure, or buy an existing product, while a forward deployed engineer builds and operates the production workflow itself. Titles vary, so test accountability instead: who owns integration, evaluation, exception handling, and adoption after the sale?
Often yes, and the label settles nothing on its own. Forward deployed engineering only separates from consulting when field learning becomes reusable software, evaluations, connectors, and playbooks that make the next customer cheaper to serve than the last.
Forward deployed engineering scales like software only when field knowledge turns into reusable assets that reduce marginal labor. If every customer requires the same elite team for the same duration, revenue stays tied to headcount and the firm scales like a consultancy.
The proof is a cohort showing shorter deployments, fewer senior hours, and stable production quality.
Public evidence shows several models. Tribe lists project and private-offer implementation through AWS Marketplace, while trade reporting describes Distyl's fees as outcome-linked (AWS Marketplace, Channel Dive). Most providers do not disclose pricing, recurring mix, or risk-sharing terms.
Ask whether discovery, build, software, support, and managed operation are priced separately. Then match every outcome fee to a baseline, data source, attribution rule, and customer dependency. Without those definitions, outcome pricing is positioning rather than an underwritable commercial model.