Should you build or buy AI agents?

Building one agent takes about a week. Running forty of them for two years takes a team. Build or buy is a question about the second year, and the estimate is usually made in the first month.

Every build or buy discussion starts the same way. Somebody wires an agent to a real process over a few evenings, it works, and the room concludes this is not hard. They are right. That part is easy. The estimate goes wrong on what comes after the demo.

Why the build looks cheap

The first version looks cheap because it is tested on a friendly sample, with the person who wrote it watching. None of the expensive parts have shown up yet. Nobody demos the retry logic, the month end backlog or the form that changed without notice. Nobody demos the client asking about March, or a model version retired on someone else's schedule.

Five questions that settle it

1. /01

   Is the agent the product, or a way of doing the work? If customers are buying the automation itself, build it. If customers buy the outcome, the agent is a supporting part, and most companies buy parts like that.

2. /02

   Who carries the pager? Name them. If you cannot name the person who gets woken when a run misfires at month end, you are not building, you are prototyping.

3. /03

   What happens when that person leaves? Two years is long enough that they will. An in house agent with one owner becomes a risk the day that person leaves.

4. /04

   Could you produce an audit trail on demand today? Not logs. A record with evidence, cost and an accountable person, exportable when a client asks. Many teams only learn this when a customer asks, which is the worst time.

5. /05

   How fast does this need to work? Building takes as long as it takes. Buying takes as long as agreeing scope takes. If the answer is next quarter, the answer is already decided.

Build it yourself when these hold

1. /01

   You already run production software, and people already take on call shifts.

2. /02

   The judgement being automated is your real advantage, and writing it down for a vendor would be handing it over.

3. /03

   Your compliance position forbids material leaving your systems, and somebody has checked that rather than assumed it.

4. /04

   You have a second owner for it as well as a first.

Buy it when these hold

1. /01

   The process takes hours every week and the case for fixing it is clear. Waiting a year costs more than buying.

2. /02

   Nobody on staff wants to own the reliability of it, and pretending otherwise is how it rots.

3. /03

   You will be asked to prove what happened, by a client, an auditor, an insurer or a regulator.

4. /04

   You would rather spend your engineering on the thing customers pay you for.

Keep the judgement and buy the controls

Build or buy is a false choice here, because an agent has two halves that fail differently. One half is domain judgement: what counts as a match, when a claim is unusual, which supplier gets the benefit of the doubt. That is yours, it is hard to copy, and you should keep it. The other half is governance: scope enforcement, thresholds, limits, holds, records, exports, drift monitoring. That half is much the same in every company and tedious to build, and in house versions are often left unfinished.

So split it. Keep the judgement and buy the controls around it. Make the contract say the record is yours, in a format you can read without the vendor. Then leaving stays cheap, and staying is your choice.

GatehouseThose controls are what Gatehouse, Surehand's control plane, enforces while the agent runs: one signed manifest, a named approver, a sealed record. See Gatehouse

Write down one process before you decide

Whichever way you lean, start with one process. Write down a good outcome, what the agent may touch, what it must never touch, and who decides when it is unsure. If that document is hard to write, the problem is not build or buy. It is that the process is not understood well enough to automate yet, and both routes will fail on the same rock.