I inherit stalled AI agent projects for a living, and the cause is almost never the model — it's a build-vs-buy call made on momentum. Here is the honest 2026 answer: buy or deploy by default, and build a custom agent only where it reads proprietary data, takes a regulated action that needs an audit trail, or runs a process your competitors can't copy. Everywhere else, buying or configuring ships faster, cheaper, and with far less risk.
I'm not going to pretend that's a neutral take — I run an agency that builds agents, so the surprising part is how often we tell clients not to. The mistake I keep cleaning up looks the same every time: someone saw a launch, felt behind, and greenlit a custom agent for a workflow a configured tool would have handled in a fortnight. In 2026 that mistake got easier to make, because the platforms removed the excuse to treat "build" as the default.
So this is not a recap of who launched what. It's the decision underneath the news: now that capable agents are a budget line, where should a mid-market operator actually spend? Below is the test we run with clients before a single sprint is committed, an honest comparison of your three real options, and — because no competitor can write it — exactly which of the seven agents I built for my own business I would buy today instead.
What just changed — the build-vs-buy line moved
In a few weeks across mid-2026, three of the largest vendors moved agents from experiment toward procurement — but not evenly, and the differences matter. IBM made Agent Builder, plus prebuilt Sales and Procurement agents, generally available in watsonx Orchestrate — the one genuinely-on-the-shelf moment. Google released Gemini 3.1 Pro, tuned for the precise tool use and reliable multi-step execution that agentic workflows actually run on. And Microsoft announced Project Solara, an Android-based, chip-to-cloud agent-first device platform — which is the part most write-ups get wrong: it's an early-adopter programme now and a 2027 preview, not something you can buy this quarter.
Read together, the signal is clear and the timing is not: buying a capable agent has stopped being the hard part, and more of that capability is arriving on a roadmap you don't control. When capability becomes a catalogue item, the scarce resource stops being the technology and becomes judgement about where to apply it. That's a buyer's problem, and it's the one nobody at a launch keynote solves for you. The line between build and buy didn't disappear in 2026 — it moved, and it's worth knowing exactly where it sits now.
Why an agent isn't software — and why this isn't the same decision
We already publish a guide on the build vs buy decision for software, and it's mostly about engineering capacity: how many months a year you need developers. The agent version runs on completely different axes, which is why it earns its own page rather than a find-and-replace.
Software runs; an agent acts. Five things follow from that, and none of them appear in a normal build-vs-buy spreadsheet:
- Autonomy creates liability. An agent takes actions — sends the email, issues the refund, updates the record. You're now governing decisions, not just outputs, and someone has to be accountable when it acts wrongly.
- It needs tool access and permissions. Every system an agent can touch is a live security surface. "What can this thing do, and to what" is a question software docs never had to answer.
- It carries ongoing run cost. Token and execution cost scales with usage, every day it runs — this is rent, not a one-time build.
- It drifts. When the underlying model updates, behaviour shifts. An agent that passed every test in March can quietly regress in June.
- It needs an orchestration layer. The moment two agents coordinate, you own the wiring between them — the part no demo shows.
So "ownership" of an agent means owning the prompts, the tool-wiring and the evaluation harness — not just the source code. That single reframe changes most build-vs-buy calls, because the thing you're really deciding to own (or rent) is judgement and permissions, not just software.
When buying an agent wins
Buy when the workflow is common, bounded and not a differentiator — which is most of them. Support triage, meeting scheduling, internal knowledge lookups, document classification, standard back-office automation: these are the same for you as for everyone else, and a platform agent ships them in days. You inherit the vendor's evaluation, monitoring and model-drift maintenance for free, and you stop paying attention to a problem that was never going to win you a customer.
The honest test for "buy": if a launch next quarter could make your custom build redundant, it was always a buy. Commodity capability gets cheaper and better on the vendor's schedule, not yours. Paying build prices to own a maintenance burden for a feature three platforms now ship as a checkbox is the most common money-loser I'm called in to unwind.
When building an agent wins
Build when at least one of these is true — and be strict, because each one is a quarter of your team's time:
- Proprietary data. The agent must read or write data you can't expose to a third-party platform — pricing models, customer records, IP. That pushes toward a build or a self-hosted deployment.
- A regulated, high-liability action. The agent does something under compliance (finance, health, legal) and you need full audit control of every decision it takes. Buying an opaque action-taker here is a governance failure waiting to be found.
- A moat process. The agent encodes a workflow that is itself your advantage. Renting your moat to a vendor is how you lose it.
- An unacceptable permission model. Sometimes you simply can't accept the vendor's autonomy and tool-access defaults for a sensitive action. When the permissioning is the risk, you build to control it.
Most firms run this and find the same shape: one or two genuinely build-worthy agents, and a long tail of buy-worthy ones. The discipline is refusing to spend custom-build budget on the tail because a keynote made building feel urgent.
What each path actually costs
"Build vs buy" is really build vs buy vs deploy-with-a-partner — and the third path is the one the binary framing hides. Here's the trade-off across the levers that move an agent decision specifically, not a generic dev-cost comparison.
| Lever (agent-specific) | Buy (platform agent) | Build (in-house) | Deploy with a partner |
|---|---|---|---|
| Time to first value | Days to weeks | Quarters | 2–4 weeks per use case |
| Run / token cost | Bundled in licence, scales with seats | Yours, scales with usage — watch it | Yours, but cost-modelled before launch |
| Data & tool permissions | Vendor's model — limited control | Full control of the security surface | Full — runs inside your stack |
| Audit of actions | What the vendor exposes | Complete, by design | Complete, with a handover playbook |
| Model-drift upkeep | Vendor's problem | Yours — needs an eval harness | Yours, with the harness built in |
| Day-one ownership | You rent it | You own it (and maintain it) | You own it; partner builds it |
| Best for | Commodity, high-volume workflows | Data-sensitive, regulated, moat workflows | Differentiating work with no in-house AI team |
Capability and vendor positioning as of June 2026 — verify current platform terms before you commit, because this category is moving monthly.
Read the table as a sequence, not a menu: buy the commodity row to free up attention, build only the rows where "best for" genuinely describes a data-sensitive or moat process, and use the partner path for the awkward middle — agents too important to rent where you have no team to build and run them safely.
Want a Realistic Plan for Your Project?
No sales pitch. We will give you an honest read on what your situation actually needs, what it should cost, and whether AI is even the right tool here.
Book a Discovery Call →I built 7 agents for my own business in 6 days — here's which I'd buy today
This is the part I can write and a competitor can't. Last year I built seven AI agents to run KORIX's own operations, in about a week, and they're still running inside our stack — several of them monitor this very website as you read it. Now that IBM and Google have shipped agent platforms, I ran my own build-vs-buy test back over them. Here's the honest verdict.
The four I'd buy today, not build. Four were commodity monitoring: GSC Health (search-console coverage alerts), PageSpeed (Core Web Vitals checks on key pages), Sitemap Audit (daily structure checks), and Backup Verifier (confirms backups ran, escalates if stale). I built them because they were trivial — a few hours each. But they touch nothing proprietary, and in 2026 they're exactly the kind of capability platforms and uptime tools ship as a checkbox. If I started today I'd buy or configure all four and spend the hours elsewhere. Owning them buys me nothing.
The three I'd still build. The other three wire into pipelines only we have. Auto-Index fires on our publish hook and submits new pages to Google within seconds; IndexNow pushes the same to Bing and Yandex on our cycle; Lead Monitor watches our specific inbound intake and escalates anything unprocessed past two hours. No product sells "do this against my exact publishing and intake wiring," because the value is in the integration, not the capability. These are twenty-line agents bolted to proprietary plumbing — textbook builds. That split — four to buy, three to build — is the whole thesis of this article in one real example.
Three agent projects I keep inheriting
Pattern recognition from years of rebuilding stalled AI work. Names are changed; the lessons aren't. And the through-line is the same: if your agent is a commodity, you don't need us — go configure it and move on.
Built the commodity, bought nothing
A services firm spent two quarters building a custom support-triage agent — a textbook commodity workflow. By launch, three platforms shipped the same capability as a configurable feature. They'd paid build prices for a buy problem and now owned the maintenance forever. Lesson: if a launch could make your build obsolete in a quarter, it was a buy.
Bought the moat, rented the future
A firm put its single differentiating workflow — the thing customers actually paid for — onto a third-party agent platform. Fast to launch, but the logic and data lived on the vendor's terms. When they tried to extend it, they were renting their own competitive advantage and couldn't get under the hood. Lesson: never rent the workflow that is your moat. That's a build.
Skipped governance, scaled the risk
A team shipped a finance-adjacent agent that took actions with no audit trail and no owner accountable for wrong ones. It demoed beautifully and quietly made unreviewable decisions in production until a regulator-style question had no paper trail behind it. Lesson: an agent that acts without a named owner and an audit trail is a liability — whether you built it or bought it.
The third path, and the test that decides it
For the agents that are too important to rent but where you have no in-house AI team, there's a third option the binary framing hides: deploy on your own stack with a partner. That's our Bring Your Own Software model — the agent runs inside your systems (Salesforce, Microsoft 365, SAP, your own databases) and you own the prompts, the tool-wiring and the data pipeline on day one. It's the structural answer to the ownership question, and it's how we ship client work — Anna Mazurowska's Numerology Matrix pilot and Lucky Valecha's Proteinverse build, both 5-star Clutch projects — on the client's own stack, with day-one ownership, so nobody ends up renting their core process from us.
Whichever path you're weighing, run this gate first. KORIX defines the Agent Build-vs-Buy Test as a five-question gate — proprietary data, a regulated action needing audit, a moat process, run-cost-justifying volume, and day-one ownership — where one honest "yes" on the first three is what justifies building rather than buying an AI agent.
- Proprietary data? Does the agent read or write data you can't expose to a third-party platform? Yes → build or self-host.
- Regulated action? Does it take an action under compliance where you need a full audit trail and control of the permission model? Yes → build/govern.
- Moat process? Does it encode a differentiator competitors can't copy? Yes → build to protect it.
- Volume & stability? Is the workflow high-volume and stable enough to justify a build's fixed cost and its ongoing run cost? Low-volume or fast-changing → buy or configure.
- Day-one ownership? When the engagement ends, who owns the agent, the prompts and the pipeline? If "buy" leaves you renting your own core process forever, that's a hidden reason to build.
The honest recommendation
If you're staring at the 2026 agent wave: buy the commodity workflows this quarter and don't feel behind for it — that's the disciplined move, not the timid one. Reserve building, or partner-building on your own stack, for the one or two agents that touch proprietary data, take regulated actions, or protect a real advantage. And whatever you choose, wrap it in governance — a named owner, an audit trail and a measured baseline — before it touches a customer.
Read Gartner's numbers together and the case for discipline writes itself: Gartner predicts more than 40% of agentic-AI projects will be cancelled by the end of 2027. In the same Gartner research, 33% of enterprise software is expected to embed agentic AI by 2028, up from under 1% in 2024. And a Gartner poll found 42% of organisations had made only conservative investments so far, with another 31% still waiting. Adoption is inevitable — but the cancellations cluster on the projects that built before they ran the test.
If you want help separating build-worthy from buy-worthy, the fastest honest answer is our 21-Day AI Pilot: one bounded use case, a governed agent against a real baseline, and a build, buy or deploy recommendation grounded in measured value. For adjacent decisions, see the build vs buy software guide, our honest landscape of AI agent development companies, and how the operating model works in agent deployment as a service.
For most firms in 2026 the answer is buy or deploy — build a custom agent only where it touches proprietary data, takes a regulated action that needs an audit trail, or runs a process competitors can't copy.
IBM's watsonx Orchestrate put production agents on the shelf, Gemini 3.1 Pro arrived tuned for agentic tool use, and Microsoft's Project Solara signals where enterprise devices head by 2027. The platform wave moved the build-vs-buy line — it didn't erase it. Run the five-question Agent Build-vs-Buy Test before you commit a sprint or a single run-cost dollar: buy the commodity agents, build the few that touch your data or your moat, and govern both.
Continue learning —
go deeper.
Should you build or buy AI agents in 2026?
For most firms, buy or deploy — don't build from scratch. In 2026 IBM made production agents generally available in watsonx Orchestrate, and Google's Gemini 3.1 Pro sharpened agentic tool use, so building only earns its cost when an agent reads or writes proprietary data, takes a regulated action that needs an audit trail, or runs a process competitors can't copy. For commodity work — support triage, scheduling, internal lookups, standard automation — a bought or configured agent ships in weeks instead of quarters. The honest default: buy the common, build the differentiating, and govern both.
What actually changed in 2026 — did the platforms make building obsolete?
No — they moved the line, they didn't erase it. IBM's watsonx Orchestrate made Agent Builder plus prebuilt Sales and Procurement agents generally available; Google released Gemini 3.1 Pro, tuned for the tool use and multi-step execution agents depend on; and Microsoft announced Project Solara, an agent-first device platform — though Solara is a 2027 preview, not a shelf product today. The net effect is that buying a capable agent stopped being the hard part. The scarce resource is now judgement about where building still pays.
When is it worth building a custom AI agent instead of buying one?
Build when at least one of three things is true: the agent must read or write proprietary data you can't expose to a third-party platform; it takes a regulated or high-liability action where you need full audit control of every decision; or it encodes a process that is itself a competitive moat. A fourth, quieter reason is permissioning — if you can't accept a vendor's autonomy and tool-access model for a sensitive action, you build. If none of those hold, you are usually paying custom-build prices for commodity capability.
Why do so many enterprise AI agent projects get cancelled?
Not because the models are weak. Gartner predicts more than 40% of agentic-AI projects will be cancelled by the end of 2027, largely from escalating run costs, unclear business value and weak risk controls. The pattern we see when we inherit stalled work is the same: teams build before they have defined the decision the agent owns, the data and tools it touches, and who is accountable when it acts wrongly. Agents fail on scope and governance, not capability.
How is buying an AI agent different from buying normal software?
Software runs; an agent acts. That difference changes the whole decision. An agent needs tool access and permissions (a live security surface), carries ongoing run and token cost that scales with usage instead of a one-time build, drifts when the underlying model updates, and creates liability for the actions it takes, not just the outputs it returns. So 'ownership' of an agent means owning the prompts, the tool-wiring and the evaluation harness — not just the code. Buy decisions have to weigh autonomy and audit, not only price and features.
What's the cheapest safe way to start with AI agents?
Pick one bounded, high-friction workflow and deploy a configured agent against a real baseline before writing custom code — then measure it for a few weeks. That validates value cheaply and tells you whether the workflow is even build-worthy. KORIX runs this as a 21-Day AI Pilot: one use case, real metrics, a governance wrapper, and a clear build, buy or deploy recommendation at the end, so the spend follows the evidence instead of the news cycle.