Why is ‘Build versus buy’ for agent platforms two decisions?
An AI agent and its control systems follow opposite rules. Agents are cheap to build and tailored to your business. They change constantly. The control layer is the reverse. It is costly to build and works the same everywhere. It must always keep running while everything above it is rebuilt.
Treating them as a single procurement question produces the two failures you see most often: an organisation that bought a platform to run three agents, and an organisation that built a control plane because its first agent was easy.
The reframe matters commercially as well as architecturally. A vendor selling you the ability to create agents is selling you the cheap half, and a build proposal that scopes only the agents has estimated the cheap half. Both errors come from collapsing two decisions into one.
What should you almost always build?
The agents. They encode how your business actually works, which is the part no vendor can supply and the part you would not want them to. This is also, honestly, the easy half, and it has got easier every quarter since agent frameworks became commodity open source.
What sits in this layer is genuinely yours and genuinely straightforward to produce.
- The prompts and the domain logic. What good looks like in your business, which nobody outside it knows.
- Which tools each agent may call, and in what order. A decision about your systems and your risk appetite.
- The evaluation criteria. What counts as a correct outcome here, which is the hardest thing on this list and still yours. See agent evaluation.
- The workflow shape. Which steps need discretion and which should stay deterministic, covered at agentic workflow.
Worth stating plainly because it cuts against most vendor material. The agent framework layer is commoditised, open source and improving fast. A competent engineer can have a useful agent running in an afternoon, and the honest read of that is not that agents are trivial but that the difficulty was never there. If a proposal justifies platform spend by making agent creation sound hard, that is the claim to press on. The framework question is covered at agent frameworks.
What is expensive to build and rarely differentiating?
Everything that makes a population of agents operable rather than a demonstration. None of it is visible in a pilot, all of it is required in production, and no part of it distinguishes you from a competitor who has also built it.
Eight components, and the useful test is whether you would ever describe any of them to a customer as a reason to choose you.
| Component | What it takes to build well |
|---|---|
| Registry and discovery | Auto-discovery across every platform agents get created in, not a form people fill in. This is the one most underestimated |
| Identity and scoping | Per-agent credentials, intersection of agent and user permissions, and rotation. Hard to get right, catastrophic to get wrong |
| Audit trail | Every model and tool call with actor attribution, unsampled, tamper-evident, retained for the period your regulator expects |
| Cost attribution | Per agent, per model, per user. Aggregate spend is easy; the breakdown that lets anybody act is not |
| Promotion gates | Dev, QA and production with version lineage, so a change is reviewable rather than a redeploy |
| Kill switch | Per agent, cascading through everything downstream, operable by somebody who is not an engineer, at a weekend |
| Observability | Step-level traces where a wrong answer returns a success code, which conventional monitoring does not catch |
| Policy enforcement | Rules that hold at runtime rather than sitting in a document, which is the argument at agent governance |
Two things about this list are worth noticing. Every item is invisible until you have more agents than you can hold in your head, which is why the build estimate made during the pilot is almost always low. And not one of them is something a customer would ever choose you for.
When does building the platform genuinely win?
Building your own control layer is the right choice more often than vendors admit. Five situations make the case for building. If two or more describe your business, the default flips. You then have to justify buying instead of building.
These are not edge cases. Several are common.
- 01
The agent behaviour is the productIf what you sell is the agentic capability itself, the control plane is part of your product rather than overhead. Buying here means outsourcing your differentiation and inheriting somebody else's roadmap for it.
- 02
You will never have many agentsPlatform economics assume a population. Three agents that rarely change do not amortise a platform, and the governance problem those three create is small enough to solve with a spreadsheet and a good habit.
- 03
You already own the adjacent capabilityMature internal identity, a real observability stack, an existing service catalogue with owners. The marginal build is then far smaller than the greenfield estimate, because most of the control plane is integration rather than invention.
- 04
Your constraints exclude the marketGenuinely air-gapped, a sovereignty requirement no vendor meets, or a stack nothing integrates with. Worth testing rather than assuming, and when true it settles the question.
- 05
The abstractions are still movingBuying commits you to one vendor's model of what an agent is, during a period when that is being renegotiated. A thin layer you control can be cheaper to change than a platform you are embedded in.
The fifth point has become weaker over the past year and is worth revisiting rather than repeating. Open protocols have made agents more portable than they were, which cuts against the lock-in argument on both sides: it makes buying less committing, and it also removes some of the reason to build. See MCP and A2A.
What are you comparing?
Usually two things that are not comparable. A build estimate prices getting to working. A platform price covers staying working. Setting one against the other is the most common error in this decision, and it is the reason build cases look favourable at the moment they are approved.
The gap shows up in year two, and by then the decision is not revisitable at reasonable cost.
- The build estimate is made by the people who would do the building. Not dishonestly. Engineers estimate construction well and maintenance badly, because maintenance lands on a future team with a different budget.
- The ongoing cost is real and unbudgeted. Model providers change interfaces, protocols version, a compliance requirement arrives. Someone maintains that indefinitely, and it is rarely in the business case.
- Opportunity cost is the largest line and never appears. A platform team building an audit trail is a platform team not building anything your customers notice.
- Buying has an unbudgeted cost too. Integration, migrating what exists, and the work of changing how teams operate. A platform price is not a total cost either, and treating it as one is the mirror-image error.
How do you decide?
Forecast the population, then price the control plane honestly against it. The number of agents you expect in two years decides this more than any other input, because everything expensive on the control plane list scales with population rather than with sophistication.
Five steps, and the first usually settles it.
-
Forecast agents in twenty-four months, not use cases today
Under ten, across one or two teams, changing rarely: build, and keep it thin. Dozens, across many teams, created by people you do not manage: the governance problem dominates and buying usually wins.
-
Cost the eight components, not the agent
Take the control plane list and have somebody estimate each properly, including the second year. Compare that total against the platform price, because that is the like-for-like comparison.
-
Ask who maintains it in year three
By name, with the budget line. If the answer is the team that built it, check whether that team expects to still be doing this, and whether anybody has told them.
-
Check the five build-wins conditions against yourself
Honestly, not aspirationally. Two or more and building is probably right. None and you are proposing to construct something that will never distinguish you.
-
Test the exit in both directions
How would you leave the platform, and how would you migrate off your own build if it stalls. If neither answer exists, the decision is more committing than it looks and deserves more scrutiny than it is getting.
One pattern worth considering, because it is what several organisations settle on and it is rarely presented as an option. Buy the control plane and build the agents on top of it, which follows directly from the two-decisions framing. It keeps the part that encodes your business inside your team and hands over the part that is identical everywhere, and it is generally the cheapest position to change your mind from later.