Build vs. Buy AI Agents: The Cost Nobody Prices

McKinsey's State of AI 2026 survey, published in late August and drawn from 1,719 respondents across 97 countries, found that 32% of organizations have decided against buying a piece of software this year and built it themselves instead, using agentic coding tools to do it. In the technology sector that figure rises to 41%. Among the "high performers" McKinsey tracks — the roughly 6% of companies that attribute at least 5% of their EBIT to AI — it's nearly half. The same survey found something that should temper the enthusiasm: one in five respondents say their organization is already limiting how much it uses AI because of operating costs. Those two numbers sit right next to each other in the same report, and most of the coverage only quoted the first one.

Why "Build" Suddenly Looks Cheap

The build-vs-buy calculation has flipped for a specific reason: an agentic coding tool can now produce a working internal version of a SaaS feature in days instead of the months a custom dev project used to take. That changes the math for a lot of purchase decisions that used to default to "buy":

• Per-seat SaaS pricing stops making sense once an internal tool can be built for a fraction of the annual license cost, especially for point solutions used by a small team
• Off-the-shelf software rarely fits a company's exact workflow, and an agentic coding tool can now close that customization gap in-house instead of paying for a heavily configured enterprise tier
• Procurement and vendor security review used to be the fastest path to a working tool; for a narrowly scoped internal need, an agent-assisted build can now be faster than that approval process alone

None of that is wrong. For a well-scoped internal tool with a small, stable set of users, building is often the right call, and it was already trending that way before agentic coding tools made the build faster. The problem is that "faster to build" and "cheaper to run" are two different questions, and the survey data shows companies are answering the first one and skipping the second.

The Cost Nobody Prices In

A purchased SaaS product comes with its operating cost baked into the sticker price — uptime, security patching, model upgrades, and support are the vendor's problem, not yours. A tool built in-house with an agentic coding tool doesn't come with any of that. It comes with a working prototype and a new, uncosted line item that shows up a few months later. Four costs account for most of the gap between "we built it" and "we're still running it":

1. 1Ongoing model and token spend — a DIY agent still calls a model on every run, and unlike a fixed SaaS subscription, that bill scales directly with usage and with how efficiently the agent was built to manage its own context
2. 2Maintenance ownership — the person who vibe-coded the internal agent in a sprint is rarely the person budgeted to patch it, update it when the underlying model changes, or fix it when it breaks in production six months later
3. 3Security and access review — an internally built agent that touches customer data or internal systems needs the same permissions audit and threshold-setting a vendor tool would have gone through in procurement, and that step is the one most likely to get skipped under time pressure
4. 4Knowledge concentration — when the build lived in one person's agentic coding sessions instead of a documented spec, the tool's only real documentation leaves the company when they do

None of these costs are visible at the moment a team decides to build instead of buy, because that decision gets made against the build cost, not the five-year run cost. That's exactly the gap the one-in-five statistic is describing: companies that built fast are now the ones pulling back on AI usage because the operating bill came in higher than the project ever priced.

What High Performers Do Differently

High-performing organizations aren't building in-house because it's cheaper up front. They're building in-house because they've already priced what it costs to run — and they build that cost into the decision instead of discovering it later.

The detail worth noticing in McKinsey's data is that the companies with the strongest AI results skip buying software at nearly twice the rate of everyone else — 47% versus 31%. If unpriced operating cost were the dominant failure mode, you'd expect the opposite: the most sophisticated AI users pulling back on DIY builds the hardest. They're not. What separates them isn't that they build less. It's that building in-house is a deliberate operating decision for them, with a monitoring plan, a maintenance owner, and a cost budget attached from day one — not a side project that quietly became load-bearing infrastructure.

A Realistic Scenario

A Wizeb client, a mid-sized logistics operator, had an ops engineer build an internal agent over a long weekend to auto-triage incoming shipment exception emails — a task that would have cost five figures a year as a bolted-on module from their existing TMS vendor. It worked well enough that it was handling the full exception queue within a month, with no formal handoff, no documented spec, and no line item in anyone's budget. Three months in, the model provider changed a default behind an API version bump, the agent started mis-routing a subset of exceptions, and the ops engineer who built it had since moved to a different team and no longer had time to debug it. We came in to rebuild it properly: same core logic, but with monitoring on its decisions, an owner assigned, a documented escalation threshold for edge cases, and its token spend tracked against the volume it was actually processing. The rebuilt version cost a fraction of the SaaS module it had replaced — the original build wasn't the mistake. Treating it as finished the day it started working was.

How to Decide — Before You Build

1. 1Price the run cost before the build cost — estimate ongoing model/token spend at the volume you actually expect, not the volume in the first week's test
2. 2Name an owner for maintenance before the first version ships — if no one is budgeted to patch and update it, that's a decision to keep buying, not a gap to ignore
3. 3Route the build through the same access review a vendor tool would get if it touches customer data, internal systems, or financial actions
4. 4Document the spec outside of the chat history that built it — the build needs to survive the person who built it moving to a different project
5. 5Revisit "build" versus "buy" at the point the tool becomes load-bearing, not just at the point it first works — the calculation that justified building it in a weekend often doesn't hold once fifty people depend on it daily

How Wizeb Approaches This

We don't push clients toward "build" or "buy" as a default — we price both, including the part most in-house builds skip: what it costs to run the thing a year from now, not just what it costs to get it working this week. When we build custom AI agents, the operating model — token cost tracking, a named maintenance owner, monitoring, and access review — is part of the build, not an afterthought bolted on after something breaks. That's usually the actual difference between an in-house build that keeps paying off and one that quietly becomes the reason a team pulls back on AI a few months later. If you've already got an agent someone built in a weekend that's now running a real part of your business, it's worth getting its real operating cost priced before it becomes a problem. Start at wizeb.com/services/ai-agents.