The comparison between custom AI agent vs platform cost has one crossover point, and it is not a number you can look up. It’s a formula, and the answer it gives swings by more than thirty times depending on a single input: what your platform charges per session relative to what a session costs you in raw inference.

Run the model below with a platform at $2.00 a session and the crossover lands near 72,000 sessions a year. Change that one input to $0.20 and it lands near 2.7 million. Same build cost, same team, same everything. That’s why “we did the math and you should build” and “we did the math and you should buy” are both routinely true.

One more thing up front, because most comparisons omit it: the row that decides many of these cases is neither the subscription nor the inference bill. It’s the evaluation and correction work that keeps an agent behaving as the world shifts underneath it. You pay that on both paths, and nobody’s pricing page mentions it.

Platform pricing is roughly linear in usage. Per seat, per session, per conversation, per resolution — the shape differs, but the bill tracks how much you use it. Little up front, and a cost that grows with success. Custom is the opposite shape: high fixed cost to build, low marginal cost afterwards.

Two lines, different slopes, different intercepts. They cross. The rest of this article is about locating your crossing.

Complicate it, though, because the clean version misleads. The custom line isn’t flat after launch — it carries an ongoing engineering term that doesn’t shrink with efficiency. And the platform line usually hides a step function, where a tier boundary or an enterprise agreement changes the per-unit price. Both distortions matter more than the slope difference at the volumes most companies actually run.

You need five numbers. If you can’t put a defensible figure on all five, you’re not ready for the build-versus-buy conversation — you’re ready to go find these out.

Sessions or conversations per year. Growth rate matters as much as level, because a build commits you for years and you’re choosing against future volume, not today’s.

Be careful what you count: “sessions” on a platform invoice and “sessions” in your analytics are frequently different things, and the definition that reaches the bill is the vendor’s.

Not “the model integration.” A production agent is four things: orchestration, an evaluation suite, integrations into your actual systems, and a control surface for the humans who own it.

Teams underestimate the last two badly. Integrations are ordinary systems work, priced accordingly. The control surface — a way for a non-engineer to inspect what the agent did, correct it, and adjust behaviour without a deploy — gets skipped in early estimates and built in year one anyway, because operating without it is intolerable.

Inference is obvious. Retrieval, storage, and egress get forgotten, and retrieval can rival inference in a RAG-heavy design.

Model this per session, not per token — per-token pricing tells you nothing until you know how many tokens a session consumes. Measure that from real transcripts rather than estimating. Estimates here are wrong by multiples, not percentages, because reasoning and tool-calling loops consume far more than a prompt-plus-answer guess suggests.

There’s a long-standing planning heuristic in custom software that annual maintenance runs around 15–25% of the original build cost. It’s repeated everywhere. What you won’t easily find is an independent study behind it — the sources are largely vendors and agencies citing each other and a rule of thumb that predates all of this. Treat it as a planning range with a sensible basis, not a measured statistic, and be suspicious of anyone citing it as one.

My own position, labelled as a position rather than data: for agents I’d plan at the top of that range or above it, because they carry a maintenance category conventional software doesn’t have.

Conventional software fails loudly. A regression breaks a test, throws an error, pages someone.

Agents fail quietly. The model updates, a prompt tuned for the old one degrades slightly, a retrieval corpus goes stale, a downstream API changes its response shape and the agent gamely improvises around it. Nothing errors. Quality just erodes, and unless you’re measuring continuously you hear about it from a customer.

Preventing that is recurring work: maintaining an evaluation set, running it against every model and prompt change, investigating regressions, correcting behaviour. It doesn’t decline over time the way conventional maintenance does. Arguably it grows, as your eval set expands with each newly discovered failure mode.

Neither side’s marketing prices it. The platform vendor doesn’t, because it makes their product look like more work than the demo implied. The custom shop doesn’t, because it makes the build look more expensive.

Everything below is illustrative arithmetic, not market data. The figures are round numbers chosen to show the mechanics. Every assumption is listed so you can replace it with yours — and you should, because the conclusion is far more sensitive to your inputs than to the model’s structure.

Assumptions (illustrative):

Three-year total cost at three volumes (illustrative):

Custom three-year cost is build, plus three years of engineering, plus marginal cost across all sessions. At 100,000 sessions a year the fixed cost hasn’t amortized and buying is straightforwardly correct.

Under these assumptions the crossover is about 157,000 sessions a year. Here’s the formula, which is the part worth keeping:

Crossover sessions per year = (Build cost + Years × Annual engineering) ÷ (Years × (Platform price per session − Your marginal cost per session))

Note what governs it: the gap between the platform’s per-session price and your marginal cost. Not the platform’s price. Not your inference bill. The gap.

You may have met a specific threshold circulating — roughly a million conversations a year — as the point where building starts to win. I went looking for its source before writing this, and it doesn’t hold up as a finding.

It traces to build-versus-buy analyses published by firms with a position in the market, at least one of which states plainly in its own text that its figures are illustrative arithmetic rather than measured data. That’s honest of them, and it’s exactly what my table is too. But an illustrative number built on someone else’s assumptions isn’t a benchmark for your decision, and it’s been repeated widely enough to look like one.

The model above puts the crossover at 157,000 on perfectly reasonable inputs. Change one and it’s 2.7 million. Both are “correct.” Neither is a threshold. Use the formula, not anyone’s number — mine included.

The most useful section, because it tells you which arguments in the room are worth having.

Platform price per session. Dominant by a wide margin. Holding everything else constant:

A factor of ten in platform price swings the crossover by a factor of thirty-seven. Nothing else comes close. So spend your effort getting the real negotiated rate rather than list price — and note this is the input a vendor can change with a discount, which is exactly what they’ll do once they learn you’re modelling a build.

Falling inference costs. The good objection, and it deserves a row rather than a prediction. Cheaper inference lowers your marginal cost, widening the gap and lowering the crossover — mechanically favouring build. But platforms buy inference too, and competition passes some through as lower per-session pricing, which moves the crossover sharply the other way. Since the platform term dominates, falling token prices most likely favour buying. That’s the opposite of what people usually assert. And the engineering terms are untouched either way: cheap tokens don’t maintain your eval set.

Per-seat pricing. If you’re billed per seat, the driver is headcount and the risk profile inverts: costs become predictable but scale with a number your HR department controls rather than your product does.

Integration depth. A platform that can’t reach your systems has a cost that never appears on its invoice — engineering time building connectors, or a workflow nobody adopts. Price integration work under both options. It rarely goes to zero on the buy side, and comparisons assuming it does are the ones that surprise people in year two.

Compliance. Residency, retention, or auditability requirements can eliminate options outright and make cost modelling moot. Establish those constraints before you model, not after you’ve picked a favourite.

Worth naming plainly: the platform category includes established products with real engineering behind them, and they’re chosen so often because they genuinely do reach production quickly. Speed to a working thing is a real economic benefit — it just doesn’t appear in a three-year table.

The binary framing is mostly wrong, and my two-column table quietly encourages the error.

What teams converge on is buying the foundation and building what’s specific to them. You don’t train a model. You may not build orchestration from scratch. What you own is the layer encoding how your business actually works: the integrations, the evaluation criteria that define “good” in your domain, and the control surface your operations people use.

The logic is straightforward. The commodity layer has real competition and falling prices, so owning it earns you nothing. The specific layer is where switching costs, differentiation, and the compounding value of your evaluation data live. Rent the first, own the second.

A note on evidence: I’d intended to cite a statistic about hybrid being the dominant enterprise pattern by this year, and couldn’t verify it. The nearest real datapoint concerns hybrid infrastructure — where compute physically runs — which is a different question from where the buy/build line falls in an agent architecture. So I’ve dropped the number and made the case on logic. If someone quotes you a hybrid-adoption percentage, ask which of those two it measures.

The practical consequence: Your build cost is usually smaller than a full-custom estimate suggests, pulling the crossover down, while ongoing engineering stays roughly the same, because the correction loop attaches to the specific layer — the half you kept. That asymmetry is the real reason hybrid tends to win. If you’re scoping which half is which, that’s the piece worth getting right early: A design decision with a cost consequence, not a procurement one.

This section is what makes the rest credible, so I’m not going to soften it.

Below your crossover. Run the formula with real numbers. If you’re under it and won’t cross within your horizon, building is a worse use of money, and architectural preference doesn’t change that.

When requirements are still moving. If what the agent should do changes monthly, you’d be building against a spec that doesn’t exist. Rent flexibility until the workflow stabilizes — iterating on a platform is cheaper than iterating on your own codebase, and that’s most of what you’re paying for.

Without a named engineering owner. Not a team to be assigned later. A specific person whose job includes this agent in eighteen months. Agents without owners drift, and drift stays invisible until it’s a customer complaint. This is the most common reason a well-modelled build goes wrong: the arithmetic was right and nobody was left holding it.

On an unvalidated workflow. If you don’t yet know whether an agent helps this process at all, answer that on a platform in six weeks rather than commissioning a build to find out.

Any one of those makes buying correct even when the spreadsheet disagrees. The spreadsheet assumes the build succeeds and stays maintained; those four conditions are what that assumption rests on.

If you recognise your own situation in that list, it’s worth a conversation before you spend anything — the useful version of that call is pressure-testing your model, not scoping a build.

TCO comparisons that stop at the invoice are why teams get blindsided in year two.

Here’s what happened with an agent we operate. Year one was mostly building it. Year two, I expected the work to fall off. It didn’t — it changed shape. Most of the second year’s engineering time went not to new capability but to keeping existing behaviour correct: expanding the evaluation set as we found failure modes we hadn’t imagined, re-validating after model updates, fixing quality regressions no test caught because no test knew to look, correcting behaviour when an upstream source changed what it returned.

None of it produced a feature. All of it was necessary. And the part that matters for the decision: almost all of it would have been necessary on a platform too. Different mechanics, same category of work. If your agent’s outputs matter, somebody on your side is validating them continuously, whoever hosts the model.

That’s the row missing from every comparison table I’ve seen. Both columns show subscription or inference. Neither shows the correction loop, which over three years is frequently the largest line in either.

So: before you argue about build versus buy, put that row in the table. Estimate it honestly for both — it won’t be zero on either — and see whether it changes the ranking. Often it doesn’t change which option wins. It changes whether the winner is affordable at all, which is more important to learn in advance.

The teams that get this right aren’t the ones that picked correctly. They’re the ones who knew what they were signing up for either way.

Is it cheaper to build a custom AI agent or buy a platform?

It depends on volume, and the threshold is a formula, not a number: divide your build cost plus multi-year engineering by the gap between the platform’s per-session price and your marginal cost per session. With plausible assumptions that crossover can land anywhere from under 100,000 to several million sessions a year. Below your crossover, buy. Above it, and with a named owner and stable requirements, build.

What does it cost to maintain an AI agent after launch?

Plan for the upper end of the 15–25% of build cost per year that’s conventional for custom software, or above it. That range is a long-standing industry heuristic rather than a measured statistic, so treat it as a planning figure. Agents warrant the higher end because they need continuous evaluation against drift — a maintenance category conventional software doesn’t have.

At what usage volume does building your own agent make sense?

There’s no universal threshold, despite figures circulating that suggest one. The crossover depends mostly on the gap between platform per-session pricing and your own marginal cost. Model it yourself with your negotiated rate rather than list price. Then confirm you’ll still be above the crossover in three years, since you’re choosing against future volume rather than today’s.

Will falling token prices make custom agents unnecessary?

Probably the reverse of what people assume. Cheaper inference lowers your marginal cost, which favours building — but platforms also buy inference and pass savings into lower per-session pricing, and the platform price term dominates the crossover formula. So falling prices most likely favour buying. Either way, engineering and evaluation costs are untouched by token prices.

What costs do AI platform pricing pages leave out?

Integration work to reach your systems, the evaluation and correction loop that keeps quality from drifting, the internal control surface your operations team needs, and the definitional gap between billed sessions and the sessions in your analytics. The correction loop is the big one, because it recurs indefinitely and lands on your engineers regardless of who hosts the model.