On 2 October 2026, Anthropic announced a programme to train 10,000 "Frontier Deployed Engineers" by the end of 2027. It is the clearest signal of something the industry has been saying for some time: the model is no longer the bottleneck. Getting it into a company's real operations is.
This piece is not about who has the most deployed engineers. It is about the question that whoever receives them should ask. The thesis: an agentic project with an external team is also measured by what it leaves written down in-house. If the deployment knowledge leaves with the engineer, what you have bought is not a system: it is a dependency.
What a deployed engineer is
The term comes from software companies that placed engineers at the customer's site so their product would actually work. a16z sums it up: these are the teams closest to the customer, who operationalise the model into a real-world solution. Their thesis is that, in AI, this layer of integration and context is where the advantage is built, even if it lowers the margin.
Anthropic's programme, the Claude Frontier Academy, puts numbers on the bet:
The participants the announcement names include consultancies such as Accenture, Bain, Capgemini, Deloitte and McKinsey, and companies such as Commonwealth Bank of Australia, Morgan Stanley and Novo Nordisk. The path it describes goes "from the right use case through security review to handover". Matthew Mayo, at KDnuggets, puts it in one sentence: "The technology is capable, and the last mile into the enterprise is still hard."
None of this is bad. It is good news for any company that has seen a pilot die at the boundary of its systems: there will be more people who know how to cross it.
Who does the learning work for?
The uncomfortable question comes from the KDnuggets article itself. To tell a deployed engineer from a consultant, it proposes a test: "does what you learn at the customer actually reach the product roadmap?" If it does, it is a deployed engineer. If not, "it's consulting with a better title."
Notice where the learning goes in that definition: back to the vendor. That is reasonable from their side, and it is exactly what a16z calls trading margin for moat: controlling where and how data enters the system. But the moat belongs to the vendor. The same KDnuggets article does not say what the customer keeps, and it mentions engagements that get extended rather than concluded.
It is not who comes or how many. It is what your team will be able to do without them the day after they leave.
What has to stay written down
In a system with agents, much of what makes it work is not in the code. It is in decisions: what the system has to do, under which rules, how you know it does it well and who decides when there is risk. If those decisions only live in the head of whoever built it, they leave with them.
| What stays | What it answers | How you check it exists |
|---|---|---|
| Specifications | What the system does and the criteria for accepting it | They are in your repository and someone on your team can explain one without reading it from the vendor |
| Agent rules and permissions | What the agent may do and what it must not do | They are versioned files, not instructions given in a meeting |
| Evals (cases with a known answer) | How you know an answer is good | Your team runs them unaided and understands why one fails |
| Who signs off on what | Where a person decides and on what criteria | Every decision point has a name from your company, not from the vendor |
| Operations guide | What to do when quality drops or cost rises | There are alerts, thresholds and a procedure your team has already followed once |
onext's own reading; not a standard or a closed list
Each row has its own piece. Acceptance criteria can become the merge gate, as we explain in your spec is already an eval. Where a person has to sign off is covered in specs and agents: where you sign off. The rules a team shares, in shared, curated instructions. And what happens when an agent reaches production without evals or monitoring, in the quality gap of agents in production.
This is not a documentation obsession. DORA, Google's research programme on software teams, found in its 2021 and 2022 studies that internal documentation quality drove the implementation of every technical practice it studied. That research is not about agents. But it points to the same thing: what is not written down, or cannot be found, the team cannot use.
Four questions for the kick-off meeting
Before signing with an external team, whether it is a vendor's deployed engineer, a large consultancy or a boutique, it pays to have these answers in writing:
- Which repository does what you build live in? If the answer is "on our platform", ask what you could take with you if you switched vendors tomorrow.
- Who on my team works alongside you from the first week? Handover is not a meeting at the end: it is someone who has seen every decision being made.
- Can my team run the evals without you? If it cannot, it cannot tell whether a change makes the system worse.
- How do we check that the handover has worked? A reasonable proposal: your team changes a rule, runs the evals and deploys, without calling anyone.
The first question is the same one we use to decide between building and buying in AI engineering from pilot to production: if in two years you wanted to switch vendors, what would you take with you?
When dependency does pay off
It would be dishonest to present dependency as always a mistake. It is not.
For common infrastructure that does not set you apart, depending on a vendor can be the sensible choice: that is the framework of build, buy or bring in a partner. And a16z is right that someone has to do the hard integration work; the vendor doing it is not abuse, it is their business model.
The problem appears somewhere else: when the system encodes how your company works, its rules, its exceptions and its quality criteria. There, the knowledge is your asset. If it only exists in the head of an external engineer, you have not bought it: you have rented it.
Limit What is written down does not transfer everything. Some judgement is only learnt by watching decisions being made, which is why the second question weighs as much as the first. And documenting costs: DORA notes that documentation has to be created and maintained, and that this is work. A serious handover is budgeted; it does not come free at the end.
How we approach it at onext
It is the principle we work with on agent projects: what we build stays with your team, and a person decides where there is risk. It is not a promise that your team will be autonomous within a given time: it is the goal the project starts with, and the four questions above are the ones you can ask us.
Frequently asked questions
What is a forward deployed engineer?
A software engineer who works at the customer's site to turn a model or a platform into a solution that works in the customer's real operations: integrations, data, security and deployment. a16z describes these teams as the ones closest to the customer, who operationalise the model into a real-world solution. Anthropic uses the name Frontier Deployed Engineer for its training programme.
How is it different from a consultant?
According to the test KDnuggets proposes, it depends on whether what the engineer learns at the customer ends up changing what their company builds next. If that learning goes back into the vendor's product, it is a deployed engineer; if not, it is consulting with a better title. For the customer, that difference matters less than another question: what stays in-house when the engineer leaves.
What should be written down at the end of an agent project with an external team?
At least five things, in a repository you own: the specifications of what the system does, the rules and permissions the agent works with, the evals (cases with a known answer your team can run), who signs off on which decision and the operations guide (alerts, costs and what to do when quality drops).
Is depending on an external vendor always a mistake?
No. For common infrastructure that does not set you apart, depending on a vendor can be the sensible choice. The problem appears when the system encodes how your company works and that knowledge only exists in the head of whoever built it. In that case the dependency was not bought: someone stopped asking for it in writing.
Is it enough to ask for documentation at the end of the project?
No. A document written on the last day describes what someone remembers, not what the system does. What works is for specifications, rules and evals to be the material the team works with from the start, and for someone from your team to work alongside from the first week. DORA also points out that documentation has to be created and maintained, and that this takes work.
How do I check that the handover has worked?
With a test, not a meeting: your team changes a rule or a criterion, runs the evals without the vendor's help and deploys the change. If that is possible, the knowledge is in-house. If every change means calling the external team again, it is not there yet.
Sources
- Anthropic, "Claude Frontier Academy", 2 October 2026 (consulted on 12 October 2026).
- Joe Schmidt (a16z), "Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups", 4 June 2025.
- Matthew Mayo (KDnuggets), "Forward Deployed Engineer: AI's Hottest New Career, or Consulting With a Better Title?", 2 October 2026.
- DORA, "Capabilities: Documentation quality", based on the 2021 and 2022 State of DevOps reports (undated page; consulted on 12 October 2026).
- The table of what stays and the four questions are onext's own reading.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →