The question almost always arrives the same way: "should we buy an agent tool or build our own?" And it’s almost always framed wrong, because it’s asked in the abstract —as if "buy" and "build" were two religions and you had to pick a side—. They aren’t. They’re two tools for two different kinds of problem, and the only useful answer depends on one thing: whether the process you’re about to automate is your competitive advantage or a toll you pay like everyone else.
I’m writing this from the side of whoever keeps it running in production, not the side that signs the deck. And from there the pattern is stubborn: most companies buy where they should build and build where they should buy. They stand up a custom support chatbot —six months of development for something any off-the-shelf product does— and at the same time they cram their most particular process, the one nobody else has, into a rigid tool that doesn’t understand it. The mistake isn’t buying or building: it’s doing it backwards.
What buying wins (and where it sinks you)
Buying an agent product —a platform, an AI SaaS, a vertical assistant— gives you speed. Someone already solved the generic 80%: the interface, the integration with the common stuff, error handling, updates when the model underneath changes. If your problem is standard —classifying tickets, answering FAQs, scheduling—, buying is almost always right: you pay to not reinvent a wheel that rolls fine.
Where it sinks you: in the last 20%, which is usually exactly where your difference lives. The bought tool assumes a "normal" flow, and your operation has an exception that, for you, isn’t an exception —it’s the business. When you try to bend the product to handle it, you start paying in fragile integrations, in "that can’t be configured", and in lock-in: the day you want to switch, your process lives inside their box. Buying is cheap at the start and expensive when your case stops looking like the one in the brochure.
What building wins (and where it ruins you)
Building —standing up the agent on the models’ APIs, with your logic and your data— gives you control and an exact fit. The agent does your process, not an approximation of it. If that process is your advantage —the particular way you qualify a lead, prioritize an order or review a contract—, building is what protects it: you don’t put it in anyone’s box, you turn it into software of your own. That’s the case where custom wins hands down.
Where it ruins you: when you build what already exists. Custom-building a FAQ chatbot or a generic classifier means paying three times —the development, the maintenance, and the opportunity cost of not having bought it ready-made—. And careful, because building doesn’t end the day it works: an agent in production has to be watched, versioned and fixed when the model underneath changes behavior. If you’re going to build the generic, you’re signing a maintenance mortgage to own something worse than what’s on the market.
| Axis | Buy | Build |
|---|---|---|
| Time-to-value | Days or weeks | Weeks or months |
| Fit with your process | The brochure’s, with forced exceptions | Exact: it does your thing |
| Upfront cost | Low (subscription) | High (development) |
| Long-term cost | Rises with lock-in and patches | Ongoing maintenance, but it’s yours |
| Where it shines | Standard, common problems | Where the process is your advantage |
The rule: is the process your advantage or your toll?
The whole decision fits in one question: is this process something you compete on, or something you pay for like everyone else? If it’s a toll —necessary but undifferentiated, the same for you as for your competitor—, buy the best on the market and don’t touch it. If it’s your advantage —the reason a customer picks you—, don’t outsource it to a rigid box: build it, because you’re turning your know-how into an asset. Before deciding, four honest questions:
- Does someone already sell this and do it well? If yes, and your case looks like the brochure’s, buy. Don’t build an agent just to brag that it’s yours.
- Is the hard part my difference or plumbing? If the hard part is standard integration, a product solves it. If the hard part is your particular logic, that’s where building pays.
- How much does lock-in cost me if this grows? A core process inside a vendor’s box is a strategic dependency, not a line item. Count that cost up front, not when you want out.
- Can I maintain it? Building with no team (in-house or external) to watch the agent in production is buying debt. If you won’t be able to maintain it, buy it even if it fits worse.
There’s a third path that’s almost always the good one, and that the false "buy or build" dichotomy hides: buy the base and build on top only the layer that differentiates you. You use off-the-shelf models and tools for the generic 80% and put your engineering only into the piece that’s yours. It’s what we do when we build AI agents for a company: we don’t reinvent the model or the standard connector; we build your process logic on top of already-solved pieces. Not all ready-made nor all custom: each thing where it belongs.
The mistake of doing it backwards
The expensive failure isn’t choosing wrong when in doubt; it’s choosing by reflex. The technical company builds by instinct —"we do this ourselves"— and ends up with three half-maintained generic agents that a €40-a-month product would do better. The non-technical company buys by instinct —"let a tool handle it"— and crams its most valuable process, the one that sets it apart, into a SaaS that flattens it until it’s the same as everyone’s. Both have burned money and time optimizing the wrong box.
The way not to fall in is to separate before deciding: inventory the processes you’re going to touch and mark each one "toll" or "advantage". Tolls, buy; advantages, build (or buy-the-base-and-build-on-top). When the split isn’t clear, start by buying and watch where the product forces you to bend: that friction point is, almost always, the sign that there’s something of yours there that deserves its own code. If you want the map of when to automate a process with agents and when not, we develop it in the guide on automating processes with agents; and if you’d rather someone build the custom part on top of your operation without it turning into a zombie pilot, that’s what AI employees do.