Enterprises have spent two years buying access to models. The constraint now sits one step later, in getting those models to do useful work inside a real organisation, on proprietary data, under existing controls. Hiring data tracks the shift. Postings rose more than 800% between January and September 2025, on a Financial Times analysis of Indeed data, and a separate review of over 1,000 postings by Bloomberry put growth at 1,165% year over year to October 2025.
Supply is the harder number. Executive search firm Christian & Timbers estimates roughly 2,000 engineers in the United States hold the combination of sector knowledge, applied AI experience and client presence the work needs, and told TechCrunch that this is the total population, not the number available to hire.
800%Growth in FDE postings, January to September 2025
~2,000US engineers estimated to fit the profile in total
$1BAWS investment in its own embedded engineering arm
The platform vendors have answered with capital rather than commentary. AWS announced a dedicated Forward Deployed Engineering organisation backed by a $1 billion investment to embed thousands of engineers with customers, describing teams that deliver systems structured for self sufficiency rather than ongoing dependency. In May 2026 OpenAI launched the OpenAI Deployment Company with more than $4 billion of initial investment, majority owned and controlled by OpenAI, and agreed to acquire the applied AI firm Tomoro to bring roughly 150 forward deployed engineers and deployment specialists in on day one.
Where the model came from
Palantir built the role in the early 2010s because its intelligence customers could not put their requirements in a brief. Rather than run discovery from outside, it placed engineers inside customer environments to observe the work and build against it. Internally they were called Deltas. Until around 2016 the company had more forward deployed engineers than conventional software engineers, and after the Foundry platform shipped many of them moved into core engineering carrying field experience with them, per The Pragmatic Engineer.
Two structures carried the work. Echo teams brought domain expertise from the customer's own field and decided which problems were worth solving at all. Delta teams built quickly under incomplete information. Together they behaved like a small startup sitting inside the account. Rough field solutions were then reviewed centrally for patterns worth standardising, a loop Palantir describes as turning gravel roads into paved highways. That loop is the real separation from consulting, because the custom work becomes an input to the product instead of a one off deliverable.
You can think of a Dev's focus as one capability for many customers, while a Delta's focus is many capabilities for one customer. Palantir engineering blog
What the role actually is
The distinction that matters is not seniority or travel. It is what the engagement produces, and what the person is judged on when it is over.
Role
What it produces
Where the work happens
How it is judged
Forward deployed engineer
A running production system
The customer's repositories, cloud and data
Whether the system works in production
Solutions architect
A design and an implementation plan
Mostly pre-sale, from the vendor side
Whether the plan is accepted
Consultant
Analysis and a recommendation
Workshops, interviews, review cycles
Whether the recommendation is adopted
The line blurs in practice. An analysis of roughly 1,000 live postings by Perspective AI found employers relabelling solutions engineering roles as FDE roles to compete for candidates, which makes the job title weak evidence on its own. Read the deliverables instead.
What the AI work consists of
Evaluation suites that measure whether the system is accurate enough to trust, written against real cases with the customer’s own domain experts.
Retrieval over proprietary documents that respects the permission model the source systems already enforce.
Agent orchestration and the artefacts around it. Anthropic’s posting lists MCP servers, sub-agents and agent skills as customer deliverables.
Life after go-live: drift, the edge cases the evaluations missed, and the patterns worth sending back to the product team.
What the record shows
Four engagements are documented in enough detail to be useful. All four are described by the vendor or the customer, so read the mechanism rather than the headline figure.
John Deere, with OpenAI. Engineers worked on planting-season recommendations, reviewed hundreds of real examples with agronomy experts and built custom evaluation systems. OpenAI reports Deere helped farmers cut chemical use by up to 70% and raise engagement sixfold.
BBVA, with OpenAI. What began as a ChatGPT Enterprise rollout is now scaling to 120,000 employees across 25 countries.
FIS, with Anthropic. The Applied AI team and its forward deployed engineers embedded to co-design a financial crimes agent and transfer knowledge so FIS could build further agents itself. Bank of Montreal and Amalgamated Bank are named as first deployers.
Ramp runs forward deployed pods of around fifteen engineers, tied to specific customers rather than to a product area.
Every outcome number on this page is reported by a party with an interest in it. We found no independent audit of any of them. The consistent, checkable part is the method: real cases reviewed with domain experts, evaluation built before rollout, engineers inside the customer's systems.
The objections worth taking seriously
The first objection is that this is implementation consulting with a better title. Ben Piper makes the case plainly: solutions architects and implementation consultants have done this work since client-server ERP rollouts, and AI is simply the category where the gap between product and production is currently widest. The defensible difference is narrow but real. The engineer writes production code in your systems and is measured on whether it runs, not on whether the recommendation was accepted.
The second is that the economics only work at the top of the market. Embedding a senior engineer inside one account is justifiable against an eight figure commitment. On smaller deals, as FDE Academy notes, the same arrangement starts to look like services revenue presented as product revenue, and sets an expectation the vendor cannot sustain as it grows.
The third is margin. a16z states the counter-arguments itself: a services motion limits scalability, thin gross margins can signal a commodity product, and the work arguably belongs with ecosystem partners. Its answer is historical. ServiceNow went public on a 63.2% gross margin and Workday on 54.1%, both far below the software ideal, and both reached the high seventies once the implementation work had produced a position worth defending.
The fourth is the one buyers raise least and should raise most. InfoWorld points out that these engineers work for the provider and advance when the customer adopts more of the provider's platform, so a programme presented as a neutral partnership is also a strategic sales programme. Its advice is worth keeping: use the help, add your own oversight, and build architectures you could leave.
None of these objections argues against embedded engineering. They argue for buying it on terms that leave you able to operate the result, which is a question of contract language rather than of engineering.
What to ask for
The five requests below are the ones that separate an engagement you can operate afterwards from one you have to keep paying for. None of them is unusual, and a vendor that runs this model properly will already have answers.
Code in your repositories from week one, through your review process.
An evaluation suite you own, written against your cases and your risk thresholds.
The harness as well as the system: ontologies, evaluation frameworks, MCP servers, runbooks and the architecture notes behind the choices. AWS describes this as the deliverable that stays with the team.
Knowledge transfer as an acceptance criterion with a date on it, the way the FIS engagement is written.
A portability test. One workload proven to run without the vendor’s engineers before the contract renews.
Read the answers as a set. A vendor willing to commit to all five is describing a delivery model. A vendor willing to commit to the first two but not the last three is describing a staffing arrangement, which may still be the right purchase, but should be priced and governed as one.
Sources and method
Every figure here comes from a named source and is dated to it. Where a number is reported by a company about its own product, that is stated in the text. Two categories of evidence are thin and should be treated as such: outcome claims from deployments, which are vendor reported, and compensation and hiring surveys published by recruiting firms, which have a commercial interest in the answer and are cited here only where a primary source repeats them. Searches were run in August 2026. The full list follows overleaf.
OpenAI, launch of the OpenAI Deployment Company, 11 May 2026. Primary source for the $4 billion figure, the Tomoro acquisition and the engagement model.
The model is not new and the title is not the point. What has changed is that the work of making AI run inside a real organisation is now the scarce part, and the companies that treat it as engineering rather than advice are the ones producing systems that survive contact with production.
Build grounded agents
Build agents that reason inside your business logic
See how lowtouch.ai turns enterprise rules, policies, and semantic context into governed agents running inside your appliance.
About the Author
Pradeep Chandran
Lead - Agentic AI & DevOps
Pradeep Chandran is a seasoned technology leader and a key contributor at lowtouch.ai, a platform dedicated to empowering enterprises with no-code AI solutions. With a strong background in software engineering, cloud architecture, and AI-driven automation, he is committed to helping businesses streamline operations and achieve scalability through innovative technology.
At lowtouch.ai, Pradeep focuses on designing and implementing intelligent agents that automate workflows, enhance operational efficiency, and ensure data privacy. His expertise lies in bridging the gap between complex IT systems and user-friendly solutions, enabling organizations to adopt AI seamlessly. Passionate about driving digital transformation, Pradeep is dedicated to creating tools that are intuitive, secure, and tailored to meet the unique needs of enterprises.
