Build, Hire or Partner: Who Should Deploy AI Inside Your Company?

On October 2, 2026, Anthropic announced a $100 million commitment to train 10,000 Frontier Deployed Engineers by the end of 2027. The company that builds Claude is now spending heavily on the people who turn models into working systems inside businesses.

That says something useful to any company planning its next AI step. Access to capable models is no longer the hard part. The scarce resource is the engineer who can take a real process, with its systems, data and exceptions, and make AI work inside it.

So the practical question for most leadership teams isn’t which model to use. It’s who will do that work. There are three realistic answers: develop the skill in your own team, hire it, or bring in a partner. This article looks at what each one takes, where each one breaks, and how to choose.

What the work actually requires

Before comparing options, it helps to be clear about the job. Deploying AI inside an operation needs three things in one person or one small team:

• Engineering depth. Connecting a model to an ERP or CRM, handling the data, and building something that runs reliably every day rather than once in a demo.
• Operational understanding. Knowing how the process really runs, including the workarounds and the customer-specific rules that never made it into documentation.
• Judgment about what not to build. Deciding when a simple integration or a process change will do the job better than AI.

The industry calls people who combine these forward deployed engineers. If you want the background on the role and how we run it at Neurony, see how a Forward Deployed Engineer works. This article starts one step earlier: where that capability should come from.

Option 1: Develop it in your own team

Anthropic’s program is the clearest public picture of what developing this skill involves. Organizations nominate engineers who already build with large language models. After an in-person kickoff built around a simulated enterprise deployment, participants spend a 12-week residency leading a real Claude use case inside their own organization, supported by Anthropic engineers. The credential comes only after a final assessment. Anthropic describes it as following the medical model, where people learn from practitioners and are assessed on real work.

Two things stand out. The training is long and supervised, and it only works because each engineer has a real project to lead. Deployment judgment is built by doing deployments.

This route makes sense when:

• you already have strong engineers who know your systems
• you expect a steady pipeline of AI work, not one or two projects
• you can free those engineers from their day-to-day work for months

Where it breaks: the first projects are also the training ground, so they move slower and carry more risk. And if the pipeline dries up after one or two deployments, the skill you invested in sits idle.

Option 2: Hire it

Hiring an experienced deployment engineer brings the skill in directly, at least on paper. In practice, two problems show up.

First, supply. Forward deployed engineers have become one of the most sought-after profiles in AI, and the number of people with real production experience is small. Anthropic’s own explanation for its investment is that this talent is hard to find.

Second, context. A new hire knows how to deploy AI but doesn’t know your business. They still need months to learn your systems, data and people before their judgment about your operation is reliable. One hire also concentrates a lot of critical knowledge in a single person, which becomes a risk the day they leave.

This route makes sense when: AI is becoming core to how your company competes, you have enough work to keep a dedicated person busy long-term, and you can offer the kind of problems strong engineers want to work on.

Option 3: Bring in a partner

A partner brings engineers who have already deployed AI in other companies, so the first projects don’t double as training. That repeated exposure is the main thing you’re buying. Someone who has seen order processing fail in three different ERPs recognizes the pattern faster in a fourth.

The trade-offs are real too:

• Ramp-up still happens. An external engineer needs access to the people, systems and data. If your team can’t make time for that, the engagement stalls.
• Knowledge can leave with them. If nothing is documented or handed over, you end up dependent on the partner for every change.
• Incentives can drift. A partner paid to build may lean toward building. Ask how they decide when something isn’t worth it.

This route makes sense when: you want a working result before you have the internal capacity to produce one, or when you need to learn which AI work is worth doing before committing to a hire or a training program. If you’re comparing providers, How to Choose an AI Integration Partner covers what to evaluate.

Four questions that usually decide it

1. How much AI work do you actually have? Count the workflows you would realistically change over the next year or two. A long list justifies internal capability. A short one usually doesn’t.
2. Do you know which work is worth doing? If you have a dozen ideas and no ranking, any route will struggle. Deciding comes before staffing.
3. Who will own the system after launch? Whatever route you choose, someone inside the company has to own the workflow once it is live. Ownership gaps are one of the most common reasons AI adoption stalls after a promising pilot.
4. What should stay in-house long-term? Knowledge of your processes and data should. The specialist deployment experience doesn’t always need to.

The path most companies end up taking

In our view, these options aren’t exclusive, and the strongest setups combine them. A partner carries the first deployment while your own people work alongside, so the operational knowledge stays inside and the deployment experience transfers over time. Once the first workflow runs in production, you have a much better basis for deciding whether to train, hire or keep partnering. Interestingly, that’s close to how Anthropic designed its own residency: real deployments, with experienced engineers alongside.

That’s also how we prefer to start. Our Forward Deployed Engineer engagement puts one of our engineers inside your operation for a week, working with the people who do the work, and ends with a written report that ranks AI opportunities by impact and effort.
Order processing at Meesenburg is a good example of why operational knowledge matters as much as engineering. In the Meesenburg implementation, 98% of processed orders required no manual modification. Getting there depended as much on the order rules the team had built up through experience as on the model. The Meesenburg case study has the details.

Where to start

If you can’t yet answer how much AI work you have, don’t start with a hiring plan or a training budget. Start by finding out. Pick one process that already costs you time or errors, put an experienced engineer next to the people who run it, and get a ranked view of what is worth changing. The staffing decision gets much easier once that list exists.

If you’re not sure your organization is ready for that step, the AI readiness assessment is a lighter place to begin.