With a sequenced roadmap in hand, the next question is who delivers each wave - your team, a vendor, or a partner. Get it wrong and you either drown your best engineers in commodity work or hand your differentiation to someone else. Here is how to decide, use case by use case.

In the last article we turned a segmented backlog into a sequenced, fundable roadmap. That leaves one question before anything gets built: who builds each wave?

The instinct is to answer it once, as policy - “we build” or “we buy”. That is the wrong frame. It is a decision you make per use case, and the old binary is now a trio: build, buy, or partner. Most mature programmes run all three as a portfolio; industry surveys through 2026 show a clear majority of enterprises now favour a blend rather than a single lane, as agent adoption has climbed steeply.

One distinction settles most of it: commodity or differentiating

The lens that resolves most of these decisions is simple. Commodity capabilities run the business but do not set you apart - document handling, FAQ answering, ticket triage, generic copilot-style help. Your competitors will have much the same, whether they built or bought it. Differentiating capabilities define how you compete - your proprietary workflows, your pricing and allocation logic, the domain judgement and the data no competitor should be able to rent from the same vendor.

From that one distinction comes a rule of thumb that holds up well: buy your commodities, build what encodes durable advantage, and hybridise the connective tissue in between - the vendor provides the chassis, you provide the engine.

Buy - when speed and standardisation win

Buy when the process is standardised, the value is in speed, reliability and cost rather than uniqueness, the vendor’s defaults are good enough, and the relevant data already lives in the vendor’s system. These are table-stakes capabilities: worth having, but not worth building.

The trap here is over-buying - adopting a vendor product for something that is core to how you differentiate, then discovering a year in that the vendor’s roadmap does not follow your strategy. What you buy, you rent; make sure it is something you are content to rent.

Build - when it is truly yours

Build when the capability encodes proprietary advantage, depends on data you cannot hand outside, or is core to the product itself. When it is the thing that makes you you, owning it is the point.

But be clear-eyed about the cost, which is rarely the build. A small in-house agentic team is a sustained commitment running to a high six or seven figures a year once you count people, infrastructure and the ongoing upkeep, and the gap between a working prototype and a governed, monitored, production-grade deployment is wider than it looks. Even organisations with first-rate engineers sometimes choose not to build, because the opportunity cost of pulling those engineers off core work is higher than the business case admits. The mirror-image trap is over-building - rebuilding commodity capabilities from scratch because it feels more serious than buying them.

Partner - when you need capability and capacity, not just software

Partnering is the option most decision guides underplay, and the most relevant if you have a capable internal team you want to deploy selectively. It is worth being precise about what a good partner engagement is, because the word covers two very different things.

The weak version is arm’s-length delivery, or a licence you are left to configure alone. The strong version is a team that sits alongside yours, builds the differentiating work with you, and transfers the capability so your own people can run and extend it afterwards. You get capacity now and a stronger internal team later. That model fits differentiated-but-not-core work, situations where you need to move faster than hiring and ramping allow, and - most commonly - the waves your internal team has already scoped but does not have the bandwidth to deliver.

A capable internal AI team is a scarce asset to aim, not a mandate to build everything.

The prior question everyone skips: is the data ready?

Before any of the three, there is a question most organisations skip: is the data ready to support this use case at production quality? The majority of agentic failures trace back to data discovered to be missing, inaccessible or too messy to trust - found six months into a build, not six weeks before launch. It is almost always discoverable up front, and it changes the sourcing answer. A use case that is not data-ready is a data-readiness workstream first, whoever eventually builds it.

How to decide, use case by use case

For each use case on the roadmap, four questions settle it:

• Does it differentiate us? If competitors will have much the same thing, lean buy. If it is how we compete, lean build or partner-build with ownership.

• How sensitive is the data? If it cannot leave our control, that pulls towards build or a partner working inside our environment.

• How fast do we need it? Speed favours buy or partner over a standing start in-house.

• Do we have the bench - to build and, more importantly, to run it? Running a production agent is the larger, quieter cost.

Answer those and the pattern falls out: commodity, non-sensitive and needed quickly points to buy; differentiating, sensitive and core points to build; differentiated-but-not-core, or scoped-but-unstaffed, points to partner. Most organisations land on a mix - and the mix shifts as the internal team’s capability grows.

If you already have an AI team

A specific word for organisations that have built internal AI engineering capability. The win is neither to build everything nor to outsource everything. It is to point that scarce, expensive team at the handful of things that genuinely differentiate you, buy the commodity layer, and bring in a partner for the differentiated-but-not-core work your team has scoped but cannot staff. That is how you get leverage from the team you have without it becoming the bottleneck for the entire programme - and how a partner adds to your capability rather than substituting for it.

The bottom line

Build, buy or partner is not a one-time policy. It is a decision you make per use case, and re-make as your team and the market move. The organisations that get it right treat their internal capability as a scarce asset to aim, not a mandate to build everything. If you would like help drawing that line across your roadmap - what to buy, what to build, and where a partner earns its place - that is a conversation we have often. visit our AI solutions for more information.