Build vs Buy AI Agents: The Decision That Is Actually Four Decisions

Why is the build-versus-buy question wrong for agents?

Because an agent is not one purchase. It is four boundaries drawn in four places, and only the first of them is the decision people think they are making.

When a team asks whether to build or buy an AI agent, the comparison on the table is usually a platform subscription against an engineering estimate. That framing treats the agent as a single object with a single owner, and the agents that survive contact with a real process are never that. They are a model that someone else trains, a runtime that someone else or you operate, a set of tools that touch your systems of record, and a body of recorded cases that decides whether the thing still works after anything changes. Each of those can belong to a different party, and the interesting question is not "which platform" but "who owns which boundary".

I build these systems and I also sit on the buying side of vendor selections, which means I have argued for both answers in the same month. The pattern I trust is this: the model is a near-certain buy, the runtime is usually a buy, the tool boundary is worth building more often than buyers expect, and the evaluation set is worth owning no matter what else happens.

There is no all-build and no all-buy. Buy the model and probably the runtime; the decisions that determine whether the system stays yours are who owns the tool boundary and who can prove a regression did not happen.

Boundary 1 — The tool surface: what your agent can actually touch

An agent with no tools is a chat window. The moment it can read a ledger, write a ticket, or send a quote, the tool layer becomes the place where your process lives — and it is the boundary that platforms want to own.

Buying means your tools are connectors. They are configured in a vendor's interface, they carry the vendor's retry semantics, their schemas are whatever the connector exposes, and a field you need that the connector does not surface is a feature request rather than a pull request. That is a perfectly good arrangement for tools that touch commodity systems in standard ways: a calendar, a document store, a CRM with a well-documented API.

Building means the tools are yours: a small number of typed definitions, each with a written contract, versioned in your repository, testable without the model in the loop. In practice that is two to four tool definitions per workflow, and it is the layer I would build first even when everything else is bought, for one reason that has nothing to do with sentiment: it is the only layer where the semantics of your business are expressed. How a "customer" is identified, whether a refund can be issued twice, what happens when an invoice number is ambiguous — none of that is in the connector's schema, and all of it is what your operators know.

The concrete shape of that layer is an MCP server that survives production: typed tools, explicit failure modes, and idempotency at the write.

Boundary 2 — The control loop: who decides when the agent is allowed to act

Every agent that touches money, customers or systems of record needs a gate: a point where the model proposes and something else decides.

In a bought platform the gate is a configuration option, and it is usually binary — an approval step yes or no, applied to a run rather than to a decision class. In a built system the gate is code, and it can be as specific as the risk warrants: draft quotes under a threshold auto-send, anything that changes a price above it goes to a named reviewer; a classifier that is confident about intent but not about entity goes to a queue; a retry after a timeout must be idempotent before it is allowed to run at all.

The reason this matters commercially rather than aesthetically: the gate is where your operating cost sits. A gate that is too coarse forces review of everything and the workflow stops paying for itself; a gate that is too fine produces silent errors that nobody sees until a customer does. The configuration toggle cannot express "review when the discount exceeds fifteen per cent or the customer is in the top decile by revenue", and that is not an exotic requirement — it is what the operations lead says in the second meeting. Designing a human-in-the-loop that works is the longer treatment of where those lines belong.

Boundary 3 — The model: the layer that is genuinely a commodity

Buying the model is not a compromise; it is the correct answer in almost every case. Training or hosting a frontier model to run invoice intake is not a strategic position, it is a capital expense with a research team attached.

Two things are worth insisting on anyway, and both are contract terms rather than technical choices. First, the system must record which model version produced each run, because an unannounced upgrade can change the behaviour of a process your revenue depends on, and without the recorded version you cannot tell whether the change you are seeing is the model or the data. Second, you need your own way to re-test after that upgrade. Which brings us to the boundary that decides everything else.

Boundary 4 — The evaluation set: the artifact that makes you the owner

An evaluation set is a body of recorded cases with documented correct outcomes. Sixty to a hundred cases taken from real traffic, with the ones that escalated, took longest or were later reversed deliberately over-represented. It is unglamorous and it is the difference between owning a system and renting one.

With it, a model upgrade is a test run: replay the cases, compare the share handled without review, compare the confident errors, decide. Without it, a model upgrade is an incident, and it will arrive as one — a week of complaints, an argument about whether anything changed, and no way to prove either way.

This is the boundary buyers forget they are negotiating. A platform that will not let you run your own cases against its pipeline has not sold you a system you can maintain; it has sold you a system you can only believe. Ask for the export format before the pilot, not after the renewal, and keep the set in your own repository with the tool definitions. Sampling production logs is how the set gets built without inventing cases, and measuring quality without a lab is how it stays cheap to run.

What does a custom agent actually consist of?

Numbers, since the abstraction is where the argument usually hides. The differentiating layer of the agent systems I ship is typically:

That is four to seven weeks for one competent engineer, not a six-month programme, and it is smaller than most platform implementations I have watched. Those figures come from my own delivery logs and they are this small for a specific reason: the model, the hosting, the auth and the UI framework are all bought. What is built is the part that knows your business. A useful cross-check on the build side is the arithmetic in what a build-versus-buy decision actually turns on, which is about the process rather than the agent: if the process is not a source of advantage, none of the above is worth owning.

When is buying an agent platform clearly right?

Four situations, and they cover more of the market than the build case does.

Low volume with high variance. If the process runs a few hundred times a month, per-run cost is a rounding error and a bespoke build is a permanent maintenance obligation taken on to save nothing.

Standard tools and standard semantics. Ticket triage on a mainstream helpdesk, meeting summaries, calendar coordination, document Q&A over a shared drive. The connector already encodes the semantics because there are no semantics unique to you.

A process adjacent to your advantage rather than inside it. Your onboarding workflow is not why customers choose you; it should be purchased quickly with a defined exit and then ignored.

A genuine deadline and no owner. Building requires a named person who will still be responsible in year three. A platform subscription is a rational choice when that person does not exist and the process cannot wait for them to be hired.

Note what is absent from that list: "the vendor showed a good demo". Demonstrated capability is not evidence of production behaviour, which is why the evaluation questions in the procurement list are about failure paths.

When is building the agent genuinely justified?

Build when the tool boundary encodes knowledge that exists nowhere else — pricing judgement, underwriting rules, the escalation instincts of a specific team — when the agent's output is what the customer pays for, when the gate has to be finer than a toggle, and when you can name the person who owns it in year three.

Those conditions are rarer than the number of agent pilots suggests. The honest test is not "could we build this", because with MCP servers and a competent engineer the answer is almost always yes. It is "will we still be maintaining it deliberately in three years, or will it be a thing everyone is afraid to touch". The second outcome is common, and it is worse than a subscription.

What is the hybrid almost everyone should actually choose?

Buy the model. Buy the runtime if it earns its subscription. Build the tool definitions, the approval gate and the evaluation set, and require exports of the run history in a format you can join to your own records.

That split gives you three properties that neither pure option provides. The tool boundary stays yours, so the semantics of your business are not renegotiated at every renewal. The evaluation set stays yours, so a model change is a test rather than an incident. And the expensive, fast-moving layers stay someone else's problem, which is the point of buying anything.

The test of whether you got this split rather than a rental is a single day of work: clone the repository, run the recorded cases, reproduce the claimed numbers, trigger the failure path deliberately, and export everything — with none of the vendor's engineers in the room. What that acceptance test looks like in practice is the companion piece to this one, and it is the cheapest way to find out which boundary you actually own.

Write the four boundaries down before the next vendor call, with a name against each. The decision stops being philosophical the moment it is a column of owners, and the column that is empty is the one that will be empty in year three as well.