Build vs Buy vs Acquire AI Agents: The Calculus

Most build-vs-buy frameworks were written for software you run once and forget. Agentic AI breaks them, because agents keep costing money every time they think. The honest answer for enterprises eyeing acquisitions is that "build" and "buy" are no longer the only two doors, acquiring an agent company has become a third, and increasingly common, path. This piece walks through when each makes sense, why the math is sneakier than a SaaS comparison, and how to avoid paying acquisition multiples for something you could have rented for the price of an API call.

Why the Old Build-vs-Buy Framework Falls Apart
The Three Doors, Not Two
What "Build" Actually Costs in an Agent World
What "Buy" Gets You, and Hides
When Acquisition Becomes the Rational Choice
The Acqui-Hire Variant
The Capability Variant
A Decision Framework That Survives Contact With Reality
Due Diligence Questions Buyers Keep Skipping
Insights Most People Overlook
References

Why the Old Build-vs-Buy Framework Falls Apart

For thirty years, build-vs-buy meant one thing: do you write the software yourself, or license it from a vendor? You compared engineering salaries against license fees, factored in maintenance, and picked the cheaper path that didn't trap you. The decision was front-loaded. You paid most of the cost once, then ran the thing for years at near-zero marginal cost.

Agentic AI sold as a service, the broad category of agents-as-a-service, or GaaS, does not behave this way. An agent that drafts contracts, reconciles invoices, or triages support tickets incurs inference cost on every single run. The marginal cost never drops to zero. A traditional SaaS seat costs the same whether the user logs in once a month or all day; an agent that handles ten thousand outcomes costs roughly ten times what one handling a thousand outcomes does. That single fact rewires the entire calculus, because now "buy" might mean per-task or per-outcome pricing that scales linearly with your usage forever.

So the question is no longer "build once or license once." It's a question about who absorbs the ongoing, variable, model-cost-exposed economics of running autonomous workflows, and whether owning that capability outright is worth the premium the market currently puts on agent companies.

The Three Doors, Not Two

Enterprises evaluating agentic AI face three genuinely distinct options, and conflating them is where most decisions go wrong.

Build means assembling the capability in-house: your engineers wire foundation-model APIs into orchestration, build the guardrails, own the eval harness, and run it on your infrastructure. You control everything and you maintain everything.

Buy means contracting a GaaS vendor that sells the agent as a service, usually per-task, per-seat, or per-outcome. Someone else owns the orchestration, the reliability work, and the model relationships. You consume an output.

Acquire means purchasing the company that built the agent. This is the door that didn't exist in classic frameworks, and it's the one driving a wave of M&A activity as incumbents shop for agent teams. You're not buying software or a service; you're buying the team, the IP, the customer relationships, and, critically, the institutional knowledge of how to make agents reliable in a specific vertical.

The mistake is treating acquisition as just an expensive version of "buy." It isn't. Buying gets you the output today. Acquiring gets you the capability to produce that output, plus the option to redirect it, plus the talent that knows why the thing works. Those are different assets with different risk profiles.

What "Build" Actually Costs in an Agent World

Building looks cheapest on a spreadsheet and is almost always the most expensive in practice, not because of what you spend, but because of what you under-budget.

The visible cost is engineering time. The invisible costs are the ones that sink projects. Agent reliability is genuinely hard: getting an agent from a flashy 80% success demo to the 99%-plus that production demands is where most internal builds stall. McKinsey's research on enterprise AI adoption has repeatedly found that the gap between AI pilots and production-grade deployment is where value evaporates, and agents amplify this because each autonomous step compounds the error rate of the step before it.

Then there's the eval and observability tooling you'll build and rebuild, the prompt and model drift you'll chase every time a provider ships a new model version, the security surface of an autonomous system that can take actions, and the on-call burden of a thing that fails in novel ways at 3 a.m. None of that shows up in the initial estimate. A team that budgets six months for a "simple internal agent" routinely spends eighteen, and the maintenance never ends because the underlying models keep changing beneath them.

Build makes sense when the workflow is core to your competitive advantage, when you have genuine ML and infrastructure depth in-house, and when no vendor adequately covers your domain. For a bank's proprietary risk models or a hyperscaler's internal tooling, building is rational. For reconciling invoices, it usually isn't, that's a solved problem someone sells.

What "Buy" Gets You, and Hides

Buying a GaaS product gets you to value fast and pushes the reliability problem onto someone whose entire business depends on solving it. That's the pitch, and it's often a good one. A vertical agent vendor focused on, say, healthcare prior-authorization has seen ten thousand edge cases you haven't, and has the eval infrastructure and domain-specific guardrails you'd spend years replicating.

The hidden cost is economic exposure you don't control. When you buy per-outcome, your unit economics are now lashed to a vendor's pricing, which is itself lashed to foundation-model costs. If model prices compress, the vendor may keep the savings; if model providers raise prices or the vendor's margins get squeezed, you may eat it. There's also the durability question that investors themselves are wrestling with, whether usage-based agent revenue is as sticky as SaaS subscriptions, and you inherit the flip side of that uncertainty as a customer. A vendor with shaky unit economics may raise prices, get acquired, or shut down.

Buy makes sense, and it's the right default for most enterprises on most workflows, when the agent handles something important but not differentiating, when a credible vendor exists, and when you'd rather pay a premium to skip the reliability gauntlet. The strategic risk is dependency: if the workflow becomes core to you later, you may find yourself wanting to acquire the very vendor you started by renting from.

When Acquisition Becomes the Rational Choice

Acquisition is the right door in a narrow but important set of circumstances, and recognizing them early saves a fortune.

The Acqui-Hire Variant

Sometimes you're not really buying the product, you're buying the people. Agent engineering talent is scarce and expensive, and the comp wars at top agent startups have pushed the cost of assembling a team organically to absurd levels. If a small team has cracked agent reliability in a domain you care about, acquiring them can be cheaper than the eighteen-month, high-failure-rate alternative of hiring and training your own. The product may even be incidental; the muscle memory of having shipped reliable agents is the asset.

The trap here is paying a product multiple for what is really a talent deal, then watching the founders vest-and-leave. Acqui-hires only work when retention is structured into the deal and the acquired team is given room to keep doing what made them valuable.

The Capability Variant

The stronger acquisition case is when an agent capability is becoming core to your business and you cannot afford to depend on a third party for it. If autonomous claims processing is going to be the spine of your insurance operation, renting it from a vendor who could be acquired by your competitor is an unacceptable risk. Owning it outright, the team, the IP, the customer-facing reliability, converts a strategic dependency into a strategic asset.

This is the logic behind the agent-attach acquisition thesis, where an incumbent buys a vertical agent specifically to bolt autonomous capability onto an existing platform and defend its category. The premium can be justified, but only when the capability is genuinely strategic and genuinely hard to replicate. Paying acquisition prices for a commodity agent is value destruction with extra steps.

A Decision Framework That Survives Contact With Reality

Run any candidate workflow through four questions, in order:

Is this workflow core to your competitive differentiation? If no, you almost never build and almost never acquire, you buy. Differentiation is the only thing that justifies owning the capability.

Does a credible vendor exist with proven reliability in your domain? If yes and the workflow isn't differentiating, buy and move on. If a credible vendor exists but the workflow is core, you're now choosing between a deep buy relationship and acquiring that vendor.

What's the three-year total cost of ownership, including inference? Model the variable cost honestly at your projected volume. A per-outcome contract that looks cheap at pilot scale can exceed the cost of building at production volume, or vice versa. This is where agent economics diverge hardest from SaaS, and where most spreadsheets lie by holding usage flat.

What's your exposure if the vendor disappears or gets bought by a rival? If the answer is "catastrophic," you've found your acquisition candidate, or your reason to build. If the answer is "annoying but survivable," buy.

The framework's whole point is sequencing. Most workflows exit at question one or two as a clear "buy." Only the rare workflow that is core, has a credible owner, and carries catastrophic dependency risk justifies the acquisition conversation.

Due Diligence Questions Buyers Keep Skipping

When acquisition is on the table, the diligence that matters for agent companies is different from standard software diligence. A few questions buyers consistently underweight:

What is the target's true gross margin after inference cost, not the headline revenue figure? Many agent companies show SaaS-like top lines on COGS that quietly scale with usage. A margin that looks healthy today can compress the moment volume grows or model pricing shifts, the same dynamic behind valuation haircuts when model costs squeeze agent margins.

How dependent is the agent's reliability on a single foundation model, and what happens on the next model version? An agent painstakingly tuned to one model can degrade when that model is deprecated. Model-agnostic architecture is a real asset; brittle single-model tuning is a hidden liability.

Is the "moat" the agent itself, or the proprietary data and feedback loops feeding it? Agents are increasingly commoditized; the durable value is usually in the domain data, the eval sets, and the customer feedback that makes a specific agent reliable. Buy the data flywheel, not the prompt library.

And the one everyone forgets: how much of the team's value walks out the door post-close? In a market this talent-constrained, an agent acquisition with weak retention terms is a depreciating asset from day one.

Insights Most People Overlook

The cheapest option is often "buy now, reassess in a year." Because agent capabilities and pricing are moving so fast, committing to a multi-year build or a nine-figure acquisition locks you into today's technology and today's prices. Renting a GaaS product for a year while the market sorts itself out is frequently the highest-expected-value move, even if it feels like indecision. Optionality has real value when the underlying technology halves in cost annually.

Acquisition multiples are partly buying scarcity that's evaporating. The premium valuations on agent companies assume reliable agents are hard to build. That's true today. But the tooling for agent orchestration, evals, and guardrails is improving fast, and what required a specialized team in 2024 may be a weekend project in 2027. Some acquisitions are quietly paying for a moat that the rising tide of tooling will fill in for free.

The build-vs-buy decision is really a margin-exposure decision in disguise. When you build, you own your inference bill directly and can optimize it. When you buy per-outcome, you've outsourced that optimization, and the vendor's incentive is not to pass savings to you. For high-volume workflows, the "expensive" option of building can become the margin-protective one precisely because you control the cost curve. The right frame isn't "who's cheaper today" but "who controls my unit economics in three years."

Acqui-hiring an agent team can be a defensive move that has nothing to do with the product. Sometimes the real reason to acquire is to keep a talented team away from a competitor, or to prevent a vendor you depend on from being bought out from under you. These deals look irrational on a product-value basis and entirely rational on a competitive-positioning basis. Just be honest internally about which game you're playing.

"Buy" can quietly become "build" anyway. Enterprises that buy a GaaS product and then layer extensive custom orchestration, data pipelines, and guardrails around it often end up having built most of the system while still paying vendor fees. Watch for this creep, if you're doing the hard reliability work yourself on top of a vendor's agent, you've stumbled into the worst of both worlds and should formally pick a door.

Build, Buy, or Acquire: The Real Calculus When Enterprises Go Shopping for AI Agents

Table of Contents