Earlier this month, Anthropic announced that it is committing $100 million to train 10,000 Frontier Deployed Engineers by the end of 2027. The programme is more substantial than the usual enterprise certification exercise. Engineers are nominated by their organisations, work through a simulated deployment, sit a practical assessment, then spend twelve weeks leading a real Claude project back inside their company. Anthropic compares the model to a medical residency: learn from people already doing the work, practise on realistic cases, then prove you can do it yourself.

Anthropic is not training 10,000 engineers because companies need help getting access to Claude. Access is the easy part. The harder problem is finding enough people who can take a capable model into a messy organisation, work out where it can actually create value, and stay with the problem long enough to get something useful into production.

Look at the other big AI companies and the same concern keeps appearing in different forms. OpenAI has launched an entire Deployment Company with more than $4 billion of initial investment and an agreement to acquire Tomoro, bringing roughly 150 experienced FDEs and deployment specialists with it. AWS has committed $1 billion to its own Forward Deployed Engineering organisation, with plans to embed thousands of engineers directly with customers. Google is putting its own FDEs alongside major systems integrators while funding the wider partner infrastructure around agent development and deployment. Pasted text

Different companies are approaching the problem differently, but the direction is remarkably consistent. The companies building the models are investing heavily in the people who sit between model capability and a working system inside a real business.

The easy part moved

For the last few years, most of the difficulty in AI sat fairly close to the model. If the model could not reliably write code, reason through a difficult task, use tools or operate across long contexts, there was an obvious ceiling on what you could build with it. Improvements at the model layer mattered because they removed those constraints.

A lot of those constraints have now moved. A large company can get access to Claude, GPT or Gemini without much difficulty. It can connect an API, buy the infrastructure and give a team access to tools that are improving almost monthly. What it does not get with any of that is an answer to which of its hundreds of processes should change, how those processes actually work, where AI should sit inside them, what happens when the system is wrong, or whether the people expected to use it will trust it when it arrives.

Those are not edge cases around deployment. They are the deployment.

There is a tendency to think that better models should steadily remove the need for this kind of work. If the model can write more of the code, the API is easier to use and the agent frameworks keep improving, surely the human implementation layer should get thinner too. In some places it will. But the behaviour of the major AI companies suggests that something else is happening at the same time.

As the technology becomes more capable, the number of things you could plausibly do with it expands much faster than an organisation’s ability to work out which of those things are worth doing.

Better models create more choices

Suppose a team has enough engineering capacity to automate three internal processes this year. Choosing the right three matters, but the space of possible projects is manageable. Now give the same team tools that let them build and test thirty possible automations in roughly the same period. Engineering capacity has stopped being the main constraint. Judgement has not.

This is one of the stranger effects of better AI tooling. Cheaper execution does not make choosing what to execute less important. It makes bad choices cheaper to start and easier to multiply.

A company can produce ten convincing demos and still have no idea which one should become a production system. It can build an agent around a broken workflow instead of asking whether the workflow should exist. It can automate a process nobody enjoys without noticing that the process itself is a workaround for something further upstream. The technology can be working perfectly while the project is still solving the wrong problem.

That is a fairly natural place for an FDE to become more useful rather than less useful. The role sits close to the point where technical possibility meets organisational reality. Coding is part of the job, but so is deciding what deserves to be coded, understanding why the obvious solution might be wrong and staying close enough to the users to notice when the problem changes underneath you.

Four ways to build deployment capacity

The differences between OpenAI, AWS, Google and Anthropic are useful because nobody has found one obvious way to scale this.

OpenAI’s answer is partly to buy experience. Tomoro gives the new Deployment Company a body of people who have already done this work inside large organisations, rather than waiting for that capability to emerge organically. The more interesting part is the decision to create a separate company around deployment at all. OpenAI could have simply hired more solutions engineers or expanded professional services. Instead, it has given the work its own structure, capital and operating model.

AWS is trying to make the capability repeatable. Its internal FDE organisation puts thousands of engineers directly with customers, but the Partner-Led FDE model goes further by trying to reproduce the way those teams work inside consulting firms. The useful part of the AWS announcement is not the title; it is the idea that each engagement should leave behind reusable technical and domain knowledge, so the next deployment becomes easier rather than beginning from zero.

Google starts with a different advantage: distribution. Its partner ecosystem already includes more than 330,000 people trained on implementing Google AI, so the obvious question is not how Google hires enough people to do every deployment itself. It is how the company puts enough technical depth into an ecosystem that already owns the customer relationships. Google is embedding engineers with selected partners including Accenture, Capgemini, Deloitte, HCLTech, PwC and TCS, while some major consulting firms are also getting early access to forthcoming DeepMind models. Pasted text

Anthropic’s answer is the most direct response to the talent shortage. If the market does not contain enough people who can take frontier AI from an idea to a production system, create a programme designed specifically to produce more of them.

You can think of the four approaches as variations on the same problem: acquire the capability, hire it, distribute it, or train it.

This is not really a coding shortage

The Anthropic programme becomes more interesting when you look at what it actually teaches. The engineers are not spending twelve weeks learning how to call an API. The curriculum follows the shape of a deployment: identify a useful problem, work through security and technical constraints, get something into production, then hand it over in a form the organisation can continue using.

OpenAI describes almost the same territory in different language. Its FDEs are supposed to work with business leaders, operators and frontline teams to identify where AI can create value, redesign workflows, connect models to real systems and then build something reliable enough to become part of everyday operations. AWS talks about working under real customer constraints and building towards self-sufficiency rather than permanent dependency. Google puts FDEs alongside partners precisely because deploying AI inside large organisations involves more than giving those partners access to Gemini. Pasted text

There is a common shape underneath all of this. The work begins before the problem is fully specified and ends after the software technically works.

That matters because most traditional engineering processes assume somebody has already done a meaningful amount of problem definition. Requirements may be imperfect, but there is usually some agreement about what should be built. In forward deployment, figuring out what should be built is often part of the engineering work itself.

The customer says the problem is the dashboard. The FDE discovers it is the data definition. The customer asks for an agent. The FDE discovers the workflow has three approval layers nobody can explain. The customer wants a faster version of an existing process. The right answer may be to remove half of the process rather than automate it.

None of that requires less technical ability. It requires technical ability combined with enough context to know when not to use it in the obvious way.

The role gets more valuable as execution gets cheaper

There is an old assumption in software that engineering capacity is scarce, so good organisations become very careful about what they ask engineers to build. AI changes the economics of that. If a capable engineer can now produce, test and iterate on far more software than before, the cost of trying something drops dramatically.

That is good news, but it also changes where mistakes become expensive.

The expensive mistake is less often spending six months implementing something that turns out to be impossible. Increasingly, it is spending six weeks implementing something entirely possible that nobody needed. Or automating the visible part of a workflow while leaving the underlying bottleneck untouched. Or building something clever enough to demo but awkward enough that the team quietly goes back to Excel after a fortnight.

FDE work is unusually exposed to those failures because the person doing the building is also close enough to the customer to see them. That proximity can look inefficient if you measure it purely as engineering utilisation. It looks rather different if the purpose is to stop the organisation becoming extremely efficient at building the wrong thing.

The better the models become, the more useful that judgement may be. AI reduces the cost of producing an answer. It does much less to reduce the cost of asking the wrong question.

The difficult bit is scaling the role

The most interesting challenge now may not be proving that FDE works. It may be working out whether the thing that made it work can survive being scaled.

Forward deployment has usually been associated with unusually capable generalists given unusually broad scope. The good version of the role works because the person is trusted to cross boundaries, ignore neat divisions of responsibility and follow the problem wherever it goes. That is relatively straightforward when you have fifty carefully selected people. It becomes harder when Anthropic wants 10,000, AWS wants thousands more and consulting firms begin building large FDE practices of their own.

The risk is that the title scales faster than the behaviour.

A company can teach somebody a deployment methodology. It can assess technical competence, give them a framework for discovery and show them how to run an evaluation. What is harder to teach is the instinct to notice that the customer’s stated problem is probably not the real one, or the confidence to tell a senior stakeholder that the project they asked for should not be built.

That does not make the attempt to professionalise FDE wrong. Quite the opposite. Anthropic’s residency model is interesting because it treats this as something closer to a practice than a certification. AWS is trying to encode lessons from one deployment into the next. Google is pairing its engineers with partners rather than assuming training material alone will transfer the capability.

But there is a real tension here. The more precisely everyone defines the FDE role, the easier it becomes to recruit and train for. The more precisely everyone defines it, the greater the risk of sanding off the ambiguity that made the role useful in the first place.

From job title to operating model

There has been plenty of justified scepticism about the FDE boom. The title has spread faster than any shared definition of the job. Some companies have renamed solutions engineers. Others have put software engineers in front of customers and decided that proximity alone makes the role forward deployed. There will be plenty more of that.

What is becoming harder to dismiss is the underlying problem the role is trying to solve.

The companies building frontier models are not merely posting more FDE jobs. They are creating deployment companies, spending billions on dedicated organisations, teaching consulting partners how to work this way and building training programmes intended to produce thousands of people who can operate between the model and the business.

That does not prove every company needs an FDE team. It does suggest that the gap between model capability and organisational value is real enough that some of the best-resourced technology companies in the world are redesigning themselves around it.

For a while, the hope was that sufficiently capable models might close that gap on their own. What seems to be happening instead is more interesting. As the models get better, they make more things possible, and deciding which of those possibilities should become real systems becomes a larger part of the work.

The models are getting easier to use. Making them useful is still hard.