Build, buy, partner or wait: the AI decision framework, in full

Reviewed October 2026. The one-page version of this framework is at the end; the rest explains each test and shows it applied to real kinds of use case.

Contents: The four answers · Test one: whose knowledge · Test two: how standard is the workflow · Test three: will the market solve it · Test four: what it costs to be wrong · Putting the tests together · What “build” means in 2026 · The partner option, properly · When waiting is right · Worked examples · Traps · The one-page framework

Every AI use case a business considers has four honest answers: build it, buy it, partner to get it, or wait. Most programmes default to one of them, usually buy, because it feels safe, or build, because the engineers are keen, and apply it to everything. The framework here replaces the default with four tests. It fits on a page, and it is what we use in the consolidation phase of discovery to turn a scored portfolio into a sourcing plan.

The four answers

Build. Develop the capability yourself or with an engineering partner, on a platform you choose. You own the result and its evaluation set; you carry the engineering and the operation.

Buy. Licence a product that does the job. Fastest to value where a product exists and fits; you accept the vendor’s roadmap, data terms and limits.

Partner. Engage a specialist to deliver and often to operate the capability, with transfer of ownership or an ongoing arrangement. The right answer when the capability is strategic but the skills are not yet yours.

Wait. Do nothing now, deliberately, with a date to revisit. The right answer more often than programmes admit, and the one that keeps budget for what matters.

Test one: whose knowledge does it run on?

The most important test. Ask: does this use case depend on knowledge that is specific to our business, or on knowledge that is general?

Answering a customer’s question about a product from our catalogue, our policies and our history with that customer: our knowledge. Drafting a press release: general knowledge. Predicting which of our machines will fail: our data. Transcribing a meeting: general.

Where the knowledge is ours, buying a generic product gives a generic result; the value is in grounding the AI in our documents, our data and our rules, and that is a build or a partner answer, even when a product provides the shell. Where the knowledge is general, building is wasted effort; the products are good and getting better, and buy is the answer.

A useful sub-question: if a competitor bought the same product, would they get the same result? If yes, the product is not a source of advantage, and that is fine for efficiency use cases and wrong for differentiating ones.

Test two: how standard is the workflow?

Products are built for the common case. Ask: is the workflow this use case sits in standard across businesses like ours, or particular to us?

Expense processing, meeting notes, CRM hygiene, first-line IT support: standard, and products are plentiful. Our quote-to-order process with its three approval paths and the exception that only Sandra knows: particular. Products fit standard workflows well and particular ones badly; the integration and configuration cost of forcing a product onto a particular workflow often exceeds the cost of building for it.

The trap in this test is believing your workflow is particular when it is standard with a few local habits. Discovery usually finds that two-thirds of “our unique process” is the industry process. Buy for the two-thirds; build or partner for the third that is real.

Test three: will the market solve it first?

AI capability is arriving in every product you already licence. Ask: in twelve months, will our ERP, CRM, helpdesk or document system do this out of the box?

If the answer is probably yes, building now buys a year of advantage at the cost of a system you will then retire. For efficiency use cases that is rarely worth it: wait, or buy the interim product with a short commitment. For differentiating use cases the year may be exactly the point, and the roadmap of your vendors is not something to wait on.

The test needs an honest reading of vendor roadmaps, which are optimistic, and of how well the vendor’s generic feature will fit (see test two). “Our helpdesk vendor is adding an AI agent” is true for every helpdesk vendor; whether their agent will know your products is test one again.

Test four: what does it cost to be wrong?

Ask: if this AI makes a mistake, what happens, and who notices?

Low cost of error (a draft someone edits, a summary someone reads, a suggestion someone can ignore): buy or build quickly, with light oversight. High cost of error (a customer promised something, a safety-relevant decision, a regulated outcome): the escalation design, evaluation set and oversight are most of the work, and they have to be yours whatever the platform. That pushes high-stakes use cases towards build or partner, because a bought product’s oversight is designed for the average customer, not for your risk.

This test also catches the EU AI Act: a use case in the high-risk categories carries obligations that a product may or may not help you meet; see the EU AI Act guide.

Putting the tests together

The rows are guides, not rules. The point of the table is that each use case gets its own answer, and that a portfolio of twenty opportunities will usually contain all four.

What “build” means in 2026

Build no longer means training a model. For most business use cases it means configuring a foundation model (Claude, OpenAI’s models, or others) with retrieval over your documents, tools that reach your systems, rules that encode your policies, an evaluation set that proves it, and escalation that keeps it safe. That is weeks for a knowledge assistant and months for an agent that acts, not years. It also means the platform choice is separable from the assistant your staff use day to day; see Claude vs Copilot vs ChatGPT.

Build is the answer more often than it was, because the cost has fallen, and less often than engineers would like, because the products have got good. The tests above are how to tell which.

The partner option, properly

Partner is not “buy consultancy”. It is the answer when the capability is strategic (ours, particular, high-stakes) but the skills to build and run it are not yet in the business. A good partnering arrangement delivers the capability, leaves the business owning it (the code, the evaluation set, the runbooks, the platform accounts), and transfers enough skill that the next cycle can be run with less help. A bad one delivers a dependency. The test is the same as for any consultancy: at the end, could you take what you hold to someone else?

Our agent development and frameworks services are partnering in this sense: we build on a framework we have already proven, and the client owns the result.

When waiting is right

Waiting is the answer when the market will solve it, the use case is not differentiating, and the cost of doing nothing for a year is small. It is also the answer when readiness is missing: a use case whose data does not yet exist, or whose knowledge is not written down, should wait behind the work that fixes that. Waiting is wrong when it is indecision wearing a strategy’s clothes. The discipline is a date and an owner: “revisit in Q2 when the ERP release ships” is a decision; “let’s see how it develops” is not.

Worked examples

Customer support agent for an ecommerce business. Knowledge: ours (products, orders, policies). Workflow: largely standard (helpdesk) with particular edges (returns rules, B2B accounts). Market: helpdesk vendors are adding agents, generically. Cost of error: moderate; a wrong promise to a customer. Answer: build the grounding and escalation on a framework, integrated with the helpdesk; or partner for it. This is what Agency51 did.

Meeting transcription and notes. General, standard, market solved, low cost. Buy; it is in the assistant you already licence.

Predictive maintenance on a fleet of industrial machines. Ours (our telemetry, our failure history). Particular (our machines). Market: equipment vendors are adding it for their own machines, not mixed fleets. Cost of error: high if it drives maintenance decisions. Answer: partner to build, then own; start with anomaly flagging for engineers to review rather than automated scheduling, which lowers the cost of error for the first phase.

Contract review for a professional-services firm. Mixed: general contract knowledge plus our playbook. Workflow: fairly standard. Market: legal-tech products are good and improving. Cost of error: high. Answer: buy a product if one fits the playbook and the oversight; build a retrieval layer over the playbook if it does not; either way the review stays with a person.

Recruitment screening. Ours and general. Standard. Market solving it. Cost of error: high, and an EU AI Act high-risk area. Answer: wait, or buy only a product whose provider documentation supports your deployer obligations, with a person deciding. Not a first project.

Internal knowledge assistant for engineers over standards and SOPs. Ours. Particular. Market: generic enterprise search is improving but does not know our documents’ structure. Cost of error: low to moderate with citations. Answer: build; it is weeks, and it is often the best first project a business has.

Traps

• One answer for everything. A programme that builds everything burns engineering on commodities; one that buys everything owns nothing and differentiates nowhere.
• Build because it is interesting. The tests exist to protect the budget from enthusiasm, including ours.
• Buy because it is safe. A product that does not fit the workflow is a long, expensive way to discover test two.
• Confusing the assistant with the platform. Choosing Copilot for staff does not decide where agents get built.
• Waiting without a date. Indecision is a cost; name it.
• Ignoring cost of error until the pilot. Oversight designed late is expensive and the pilot stalls; see why pilots never reach production.

The one-page framework

For each use case, answer four questions:

1. Whose knowledge does it run on? Ours, or general?
2. How standard is the workflow? Standard, or particular to us?
3. Will the market solve it in twelve months? Probably, or not?
4. What does it cost to be wrong? Low, or high?

Then:

• General knowledge, standard workflow → buy, or wait for the incumbent if it is coming.
• Our knowledge, low cost of error → build the grounding; buy the shell if one fits.
• Our knowledge, high cost of error → build or partner, oversight designed first.
• Strategic but the skills are not ours yet → partner, then own.
• Not differentiating and the market is solving it → wait, with a date and an owner.

Run it across the portfolio from discovery and the sourcing plan writes itself. If you would like it run with you, opportunity prioritisation is the engagement, and it is short.