Build vs buy AI agents: an honest decision framework

Build vs buy AI agents is a decision most teams make on the wrong evidence, because the prototype is genuinely easy. A working agent loop is a weekend. The distance between that and something you’d connect to a production inbox is where the year goes — and it’s spent on problems that aren’t visible from the demo.

We build this for a living, so treat the bias as declared. The framework below is the one we’d use if we were buying.

What the weekend actually gets you

A loop that calls a model, parses a tool call, executes it, feeds the result back, and repeats. Maybe fifty lines with a modern SDK. It will work on your happy path and it will be genuinely impressive.

That prototype is not a lie — it’s the real architecture. The problem is that it represents perhaps 20% of the work, and the remaining 80% is invisible until you deploy.

The eight things that consume the year

Tool selection at scale. With ten tools, put them all in the prompt. At a few hundred, they don’t fit in a context window, and accuracy collapses long before the token limit does. You need retrieval over capabilities — an engineering problem in its own right.

Credential management. OAuth flows for every provider, token refresh, encrypted storage, per-run scoping so a compromised step can’t use the whole grant, and revocation. This is security-critical code with no shortcuts.

The approval model. Deciding what’s destructive, presenting it comprehensibly, holding run state while a human deliberates, and resuming correctly. Harder than it looks, and the thing that determines whether anyone trusts it.

Failure semantics. What happens when step 7 of 12 fails and steps 1–6 had side effects? Retry, compensate, abort, escalate — chosen per step, not globally.

Cost control. Token budgets enforced before each call, step ceilings, circuit breakers. Without them, one retry loop is an unbounded invoice.

Observability. A replayable trace of every step, tool call and decision. You cannot debug an agent from logs written for a request-response service.

Model routing and fallback. Providers rate-limit and have incidents. One hardcoded model means every provider event is your outage. Routing is the fix, and it’s more than an if-statement.

Evaluation. How do you know a prompt change didn’t break the thing that worked last week? Non-deterministic systems need test infrastructure that most teams have never built.

None of these are exotic. They’re just each a few weeks, and there are eight of them.

When building is the right answer

Genuinely, and not as a hedge:

Your domain is the product. If the agent’s judgement is your competitive advantage — pricing, underwriting, clinical triage — you shouldn’t outsource the core loop.

Hard data-residency or air-gap requirements. Some environments can’t send anything anywhere, and that constraint dominates every other consideration.

You’re a platform. If agents are what you sell, buying someone else’s is buying your own roadmap from a competitor.

The scope is genuinely narrow. One workflow, three tools, one team, no approval requirements. That’s a script, and a script is the correct answer — don’t buy a platform for it.

When buying wins

The agent is infrastructure, not differentiation. Nobody wins a market on having built their own OAuth refresh logic.

You need breadth quickly. Hundreds of integrations is not a thing you catch up on; it’s a thing you accumulate.

Compliance needs an answer now. Audit trails, approval policies and data-residency controls take longer to build than to evaluate.

Your team is small. The eight items above are a team’s year. That’s the real price tag, not the licence fee.

The comparison worth making

The eight cost centers, as the decision table they imply:

Cost center	Build: what it takes	Buy: what to verify
Tool selection at scale	Retrieval over capabilities, ranked per turn	How selection accuracy holds past ~100 tools
Credential management	OAuth per provider, refresh, vault, per-run scoping	Encryption at rest, scope minimisation, revocation story
Approval model	Effect classification, run suspension, resumption	Whether approvals show the concrete action, not a summary
Failure semantics	Retry/compensate/abort chosen per step	What happens when step 7 of 12 fails mid-run
Cost control	Budgets enforced before each call, circuit breakers	Per-run caps and what stops a retry loop
Observability	Replayable traces of every step and decision	Whether you can export the trace, not just view it
Model routing	Multi-provider fallback, health checks	Behaviour during a provider incident
Evaluation	Fixture suites, negative assertions, regression runs	How the vendor proves a model swap didn’t break you

Compare total cost against outcome, not licence cost against zero.

Building costs engineer-years, ongoing maintenance as every provider changes their API, and the opportunity cost of what those engineers weren’t doing. Buying costs a subscription, a vendor dependency, and accepting someone else’s architectural opinions.

The question that cuts through it: if this works perfectly, does it make us better than our competitors? If yes, build it. If it just means the work gets done, buy it — and spend the year on whatever the honest answer to that question actually was.

The hybrid is legitimate too, and often correct: buy the platform, build the domain logic that runs on it.

See what buying looks like in practice — drive the OS in the demo, or read what an AI agent actually is.