What Claude Frontier Academy is
On 2 October 2026, Anthropic announced Claude Frontier Academy, backed by a $100 million commitment. Its goal is to train 10,000 Frontier Deployed Engineers (FDEs) by the end of 2027. Anthropic's Steve Corfield describes them as engineers who can "take Claude from an idea to a system in production."
The first programme is the Frontier Deployed Engineer Residency. It runs in two parts:
- An in-person programme of several days, built around a simulated enterprise deployment that runs "from the right use case through security review to handover", then a graded practical. Engineers who pass earn the Claude Resident Engineer badge.
- A 12-week residency in which each engineer leads a real Claude use case at their own organisation. Engineers are reassessed at the end, and those who pass earn the Claude Frontier Deployed Engineer badge. Anthropic expects the first ones in early 2027.
Participation is by nomination, and each engineer arrives with a named Claude project. The first cohorts are running in San Francisco, New York and London, with engineers from Accenture, Bain, Capgemini, Commonwealth Bank of Australia, Deloitte, McKinsey, Morgan Stanley and Novo Nordisk, among others.
Why Anthropic is training people, not shipping a model
Anthropic's own explanation is that the people with the skills "to make it work inside a real business have become the hardest talent to find." Our reading: access to strong models is no longer what limits most enterprises. Getting a model into production, through security review, integration and adoption, is.
The forward deployed engineer role itself is not new. Our guide to forward deployed engineers covers where it came from and what it involves. What is new is the scale. Ten thousand engineers trained on one curriculum means deployment is starting to be taught as a repeatable process, rather than learned one project at a time. Five of the eight first-cohort organisations Anthropic names are consultancies, which deploy for many clients.
The simulation ends at handover. Governance starts there.
The simulated deployment at the heart of the in-person programme runs to handover, and that is the right place to end a training exercise. In a real deployment it is where the hard part begins.
During a deployment, the engineer makes dozens of decisions: which data the agent may read, which actions it may take without approval, which systems it must not touch, which exceptions were agreed with the security team and why. Some end up in a design document. The rest live in the engineer's head and in conversations with the client, unless someone records them.
When the engineer moves on, the system keeps running and keeps changing. New agents are added, prompts are revised, coding agents modify the integration code. Each change is made by someone, or something, that was not in the room when the original decisions were made. This is the failure we described for forward-deployed architects: the architect becomes another silo, the one person the system's knowledge depends on.
What changes at 10,000 engineers
One engineer leaving one deployment is a handover problem. Thousands of engineers, many at consultancies that deploy for many clients, turn it into a structural one:
- Each deployment accumulates its own local decisions, with no shared format.
- The same consultancy may deploy similar systems for different clients with different constraints, and those constraints must not leak between them.
- The client's own engineers, and their coding agents, inherit systems whose rules they never saw being made.
Training more deployers raises the number of decisions being made. It does not, on its own, give those decisions a home after the deployer leaves.
The missing layer is organisational decisions
What has to survive handover is not the model, the prompts or the code. Those are already versioned. It is the decisions: what was agreed, which part of the system each decision covers, who agreed it, whether it still holds, and how anyone can tell it is being respected.
That set of decisions needs the properties described on the engineering decision governance concept page: scope, authority, lifecycle and evidence, recorded in a form both people and agents can use. We call the place they live a decision layer. It sits under every agent in the deployment, not inside any one of them.
Why this matters beyond Claude
Nothing here is specific to Anthropic. Enterprises run Claude next to other models, coding agents from several vendors, and internal automation. A decision about which customer data an agent may touch has to hold whichever agent is acting. If each vendor's tooling keeps its own copy of the rules, nothing keeps the copies consistent.
The coding-agent side of FDE work shows the same pattern at the code level. The deployment is multi-vendor, so the decisions that govern it cannot belong to one vendor.
What engineering leaders should do
- If you nominate engineers, ask for decisions as a deliverable. The residency project should end with its key decisions recorded, scoped and owned, not only working software.
- Treat handover as a transfer of decisions. Before a deployer leaves, list what was decided, who agreed it and what it applies to.
- Keep decisions outside any one vendor's tooling. Rules that live inside one agent's configuration will not govern the next agent you add.
- Check the enforceable ones automatically. Where a decision can be expressed as a rule, check changes against it rather than relying on the next engineer to remember it.
Where Mneme fits
Mneme is an open-source decision and control layer for agentic software development, and it is tool-independent. Today it covers architectural decisions in a repository. It records them with lifecycle and version history, and enforces the ones expressed as typed rules deterministically when supported coding agents, including Claude Code, OpenAI's Codex command-line interface (CLI) and Kiro, write files, and again in continuous integration (CI). A decision layer that spans an organisation's systems beyond the repository is the direction this argument points to, not a shipped capability.