Anthropic Hires 1,000 People a Day, Trains Tens of Thousands of FDEs: Its Bet Isn’t on the Model

As models become more powerful, what may truly be scarce isn’t people who are better at using AI, but those who can embed AI into real-world operations.

Yesterday, Anthropic announced two seemingly unrelated initiatives.

First, a $150 million investment to train 1,000 Claude Corps. Anthropic will train these young people to use Claude and then place them in nonprofit organizations across the United States for a year to solve real problems.

Second, a partnership with DXC Technology. DXC will train tens of thousands of Claude FDEs, integrating Claude into the long-running systems of banks, airlines, insurance companies, manufacturers, and government agencies.

One looks like a philanthropic project.

The other looks like a major enterprise partnership.

But I think Anthropic is betting on the same thing:

AI won’t enter organizations on its own. Between the model and the business operations, you need a layer of translators.

For the past two years, everyone has been debating which model is stronger, which agent is smarter, and which company has a longer context window.

But when models actually enter enterprises, the biggest obstacle is often not their lack of intelligence.

It’s that no one can clearly articulate the operational landscape.

Enterprises Don’t Lack Models; They Lack the Middle Layer

AI needs in enterprises often start out looking very similar.

“We want AI to help review contracts.”

“We want to automate expense report auditing.”

“We want to build a business analysis assistant.”

“We want AI to automatically generate bid materials.”

None of these statements are wrong.

But they are not requirements; they are wishes.

When you actually start doing it, the problems quickly become concrete.

What exactly does contract review entail? Finding missing clauses, checking against company templates, or assessing legal risk? Can business units directly adopt AI’s suggested edits, or must they be verified by legal? When a contract version updates, how are old rules decommissioned?

Where does the data for business analysis come from? Are sales, gross profit, and collections under the same definition? Who explains abnormal fluctuations? Which data can management see, and what stays within the finance department?

Once an expense receipt is identified, does the system just check the fields, or does it need to determine if it complies with the company’s travel policy? When encountering over-limit amounts, duplicate claims, or special approvals, does the system reject directly or flag the anomaly for finance?

The model won’t answer these questions for the enterprise.

Because they aren’t model problems.

They are process problems, data problems, permission problems, responsibility problems, and organizational problems.

Between model capability and business outcomes lies a long road. What Anthropic is doing now is essentially filling the human gap along that road.

FDE Isn’t a Job Title; It’s a Set of Capabilities

FDE stands for Forward Deployed Engineer.

Many people hear this title and think of it as “an on-site engineer with stronger technical skills”: someone who understands models, can write code, and can quickly change requirements at the client’s site.

That’s only half right.

Being on-site is just a work location, not the value of an FDE.

The real value lies in their ability to navigate between technology and the operational site.

When a client says something vague, the FDE can sense that behind it might be three departments, five processes, and a dozen responsibility boundaries.

They don’t rush to connect the model. Instead, they first determine: Who is actually doing this work? Where does the input come from? Who receives the output? Which steps can be automated? Which steps require human confirmation? Who takes responsibility if something goes wrong?

I increasingly believe that FDE isn’t a fancy job title; it’s a competency structure.

Whether you call yourself an AI Product Manager, Solutions Consultant, Pre-Sales, Implementation Engineer, Business Architect, or FDE, if you’re working on enterprise AI, you can’t avoid the following five things.

Layer 1: Translate Nouns into Actions

The easiest mistake in enterprise AI projects is meeting around nouns.

Agent, RAG, digital human, knowledge graph, workflow, intelligent middle platform.

These words are useful, but they don’t directly guide delivery.

The bigger the word, the more you need to break it down into smaller pieces.

Break it down to a specific person, a specific action, a specific input, a specific output, and a specific failure handling.

For example, “automatic generation of bid materials” is too large.

But “After the project manager uploads the bidding documents, AI extracts qualifications, past performance, technical parameters, and disqualification items, generates a material checklist, and then the responsible person confirms item by item.” Now that starts to look like a task.

The first capability of an FDE isn’t being able to answer the client, but being able to keep asking the client questions.

If a requirement is full of nouns and no verbs, the requirement hasn’t truly started.

Layer 2: Find the Smallest Runnable Closed Loop

On-site problems are always more complex than the solution.

If you try to build “full-process intelligence” from the start, the project easily gets bogged down in endless interfaces, permissions, data, and organizational coordination.

A more realistic approach is to first find a segment of actions that can form a closed loop.

In contract scenarios, you don’t necessarily need AI to decide whether a contract can be signed. You can start by flagging clauses that deviate from the company template and explaining which rule was triggered.

In financial scenarios, you don’t necessarily need to fully automate the expense report process. You can first stabilize receipt classification, policy comparison, and anomaly flagging.

In recruitment scenarios, you don’t necessarily need AI to decide whether to hire. You can first organize resumes based on hard requirements and hand over the screening rationale to the hiring manager for review.

A minimum viable closed loop isn’t about building a pretty demo.

It’s about taking a real business workflow, from input to processing, confirmation, and feedback, and running it completely at least once.

Layer 3: Define the Boundary Between AI and Humans

Many AI solutions only describe what AI can do, rarely what AI should not do.

But enterprises often care more about the latter.

Which results can be executed automatically?

Which results should only be given as suggestions?

When confidence is low enough, must it be escalated to a human?

When payments, contracts, complaints, or production safety are involved, who has the final decision?

If an error occurs, can it be rolled back? Is there a record? Can you trace which data and rules were used?

A mature FDE won’t treat “full automation” as the default answer.

They will first draw the responsibility boundary.

Because in real organizations, being conservative doesn’t necessarily mean being behind the times. Often, being conservative is a sign of professionalism.

Layer 4: Turn “Feels Good” into Verifiable Outcomes

The most dangerous four words in an AI project are “looks good.”

During a demo, everyone thinks the responses are smart. But after going live, no one knows what value it actually created.

What should you measure for contract review? Not just how many risks were flagged, but recall rate for key clauses, false positive rate, legal review time, and missed reviews.

What should you measure for expense report auditing? Not just how many receipts were processed, but policy hit rate, anomaly detection rate, manual review volume, and average processing time.

What should you measure for a bid agent? Not how many pages of materials were generated, but whether disqualification items were missed, how much material preparation time was reduced, and how many times the final version was reworked.

If something cannot be verified, it is hard to deliver reliably and optimize continuously.

The truly important work of an FDE isn’t just building the system, but defining what “success” looks like before the project starts.

Layer 5: Embed Project Experience into Organizational Assets

This is the biggest difference between an FDE and a premium on-site contractor.

A premium on-site contractor sells time.

An FDE sells structure.

If someone is constantly firefighting at the client site, the client becomes increasingly dependent on them, and all the rules live in their head, then they are valuable, but the project hasn’t built organizational capability.

A truly good delivery should leave something behind.

A business process flow diagram.

A set of input/output formats.

A human-machine collaboration boundary table.

A set of verification metrics.

A failure sample repository.

A deployment checklist that can be reused.

These things may not be sexy, but they determine whether the next delivery can be faster, and whether the enterprise can rely less on a specific firefighter.

If a project ends with just a running agent and no reusable assets, it’s still just a one-off project.

Why Are These People Becoming More Valuable as Models Get Stronger?

Many people think that as models become more powerful, this middle layer of people should shrink.

I think the opposite will happen in the short term.

The stronger the model, the more things it can do, and the more needs enterprises will surface.

Previously, a requirement would be dropped because the technology couldn’t do it. Now that the model says “it can do it,” the truly difficult part begins.

Can it connect to existing systems?

Is the data usable?

Do processes need to change?

Will employees be willing to cooperate?

Who bears the cost of errors?

How will the benefits be seen?

The cheaper generation becomes, the more expensive judgment becomes.

The more a model looks like a universally capable general laborer, the more enterprises need someone to decide: Where should it work? Under what rules? At what point must it stop?

This is why the Claude Corps and DXC partnership is worth paying attention to.

Anthropic isn’t just training users how to use Claude.

It’s training a group of people who can enter organizations, identify problems, build processes, drive adoption, and take responsibility for outcomes.

In other words, large model companies are starting to realize: Selling models is not the same as delivering value. The real market requires people to bring models deep into business operations.

If You Want to Transition into an FDE Role, Don’t Rush to Learn More Tools

If you want to get into this kind of work, the easiest path to go astray is to keep bookmarking tools.

Learn one agent framework today, an automation platform tomorrow, and build three seemingly complete demos the day after.

These are helpful, of course.

But a demo only proves it can move; it doesn’t prove it can deliver.

What’s more worth practicing is to pick a business action you’re familiar with and draw a business workflow card.

Answer only seven questions:

• Who was doing this before?
• What input starts this process?
• What are the specific intermediate steps?
• Which step is the best fit for AI?
• Which situations must be escalated to a human?
• What metrics determine if it’s effective?
• How do results and failure samples flow back?

Being able to clearly write out these seven questions proves your value far more than building another chatbot.

Because what an enterprise ultimately buys isn’t a demo that can answer questions.

It buys a system that can enter existing operations, be used by employees, have someone to take responsibility when things go wrong, and produce verifiable results.

Conclusion

In the past, the most important skill for an engineer was translating requirements into code.

Now, an increasingly important skill is translating the operational site into a system where humans and AI can work together.

This role can be called FDE, or many other names.

The name doesn’t matter.

What matters is that there are people willing to leave the clean model demos and step into pages of messy contracts, inconsistent business reports, expense forms that go back and forth, and the unclear responsibility boundaries between departments.

It reminds me of Apollo 13 in 1970.

After the oxygen tank explosion, carbon dioxide levels in the spacecraft kept rising. The command module had square filter cartridges, but the lunar module’s ports were round. The materials were on the spacecraft, but they couldn’t be used directly.

The Houston ground team listed every item the astronauts had on hand: cardboard, plastic bags, tape, and tubing. They built an adapter on the ground and transmitted the assembly steps to space via radio. The astronauts followed the instructions, and the filtration system worked again.

What saved lives wasn’t that a single component suddenly became stronger, but that someone understood the differences between the two systems and reorganized the constraints, materials, steps, and verification methods.

They translated the complex operational site into a set of steps that the astronauts could follow and verify.

Apollo 13 Mission Operations Control Center. Source: NASA.

Apollo 13 Mission Operations Control Center. Source: NASA.

AI won’t enter organizations on its own.

Someone has to bring it in, tell it where to work, how to work, when to stop, and leave that method behind in the organization.

I think that’s what Anthropic is betting on.

References

• Anthropic: Introducing Claude Corps
• Anthropic: DXC will integrate Claude into critical enterprise systems
• NASA: Apollo 13, The Successful Failure - https://www.nasa.gov/missions/apollo/apollo-13-the-successful-failure/
• NASA: Mission Control, Houston, April 13, 1970 - https://www.nasa.gov/image-article/mission-control-houston-april-13-1970/

Information as of June 12, 2026.