Build, buy or embed: three ways to get AI capability

The finding that gets misquoted

MIT's Project NANDA published The GenAI Divide: State of AI in Business 2025 in July 2025. Two of its findings are usually reported together and point in different directions.

The first: tools built with external vendors succeeded roughly twice as often as internally built ones.

The second, less quoted and more useful: pilots that blended internal AI specialists with external expertise reached a 67% success rate, against 22% for IT-only builds.

The first finding is routinely read as "outsource your AI". The second says something more precise. The best outcomes did not come from handing the work to a vendor. They came from teams that combined outside engineering experience with inside domain knowledge.

That distinction should shape how the work is resourced.

Three structures

Build internally. Your team, your people, your knowledge retained. Works when you have senior engineers with production AI experience already, when the domain knowledge is the hard part and the engineering is routine, and when the work will recur often enough to justify building the capability. Fails when the team is learning on your budget. The tuition is real and it is charged in months. MIT's 22% figure for IT-only builds is not a comment on the competence of internal teams; it is a comment on what happens when a team meets a class of problem for the first time on a deadline.

Buy from a vendor. Fast, bounded, someone else's problem to maintain. Works for well-specified, common problems where a product already exists and your requirements are close to the median — document extraction for standard formats, standard integrations, commodity workflows. Fails when the problem is specific to your operation. You end up either configuring a product past its design intent, or changing your process to fit the product. The second is sometimes the right answer and is almost never the one that was budgeted for.

Embed external seniority in your team. An experienced engineer works inside your operation, with your people, on your systems. Works when the opportunity is clear but the specification is not, when your team has the domain knowledge and lacks senior AI engineering capacity, and when knowledge transfer matters as much as the deliverable. Fails when it is used as staff augmentation — a body against a backlog, with no ownership and no transfer. That is contracted capacity wearing a different label.

The embedded structure is the one that most closely matches what MIT found working. It is also the least common, because it is the hardest to procure: it does not fit a fixed-scope statement of work, and it requires the client to give real access rather than a requirements document.

How to choose

Four questions settle most cases.

Is this problem specific to us, or common? Common problems have products. Specific problems have builds. The mistake is assuming your problem is specific when it is common — that assumption is expensive and flattering.

Will we do this again? A one-off favours buying or a bounded engagement. A recurring capability favours building it internally or transferring it in.

Where is the knowledge that makes this hard? If the difficulty is in your domain — your exceptions, your regulations, your customers — external teams working from a specification will produce something that works in test and fails in production. That is the case for embedding rather than contracting.

What happens when the engagement ends? If the answer is that nobody in your organisation understands the system, you have bought a dependency, not a capability. This is the question most often skipped and most often regretted.

The honest version of our own position

We build, and we embed. So take the following as an interested party being explicit rather than as neutral advice.

We think most enterprises should build less than they plan to and buy more than they expect — commodity problems genuinely have commodity solutions, and internal teams routinely underestimate what production AI engineering costs the first time. We also think the work that genuinely matters to an operation, the workflow that is specific and load-bearing, is worth doing with senior people alongside your team rather than at arm's length from it.

And we think the test of any external engagement is what your team can do after it ends. That is why our engagements finish with documentation, runbooks and pairing, and why retainers with us exist for improvement rather than for keeping the lights on. A vendor whose commercial interest depends on you not learning is structurally misaligned with the 67% number.

Before you commit

• Write down which of the three structures you are actually buying, in one sentence. Vagueness here produces the staff-augmentation failure mode.
• Name the internal person who will hold the domain knowledge in the room. If there isn't one, MIT's 22% is your base rate.
• Define what "transfer complete" means and when it happens, before signing rather than after.
• Cost the buy option even if you intend to build. Sometimes the product is good enough and the build was ego.