Know what your agents will cost before they run

In June 2025 Gartner predicted that around 40% of agentic AI projects will be abandoned by the end of 2027 (Gartner press release, 25 June 2025, “Gartner Predicts 40% of Agentic AI Projects Will Be Abandoned by End of 2027”). Rising costs and weak controls were near the top of the reasons. Agents can do the work, so I doubt the technology is the problem. What I think the prediction describes is what happens when cost is something you report on after the fact, instead of something the system respects while it runs.

Picture a public-sector team that spends six months on an agent to process benefit applications. The demo is good. Accuracy is acceptable. Then someone projects the cost at full volume, including the reflection loops added to improve accuracy, the lookups on every application, and the large model chosen for the final decision. It comes back at four times the budget. Nothing technical failed. There was simply nothing in the system that would have stopped it spending four times the budget before anyone noticed, so the only safe option left was to stop the project.

I think a lot of the projects Gartner is talking about will end like that.

Why the obvious fix doesn’t work

Most people who think about this for five minutes suggest the same thing. Count tokens at each step, multiply by the price, keep a running total, alert when it crosses a line. You could wire it up in an afternoon with some middleware and a Slack webhook.

That’s what most first attempts look like. It tells you about the overspend after it’s happened, because of the way cost moves through an agent system.

An agent run isn’t a sequence of calls. It’s a tree, and the tree grows while it runs. A planner splits a job into seven tasks. Three of them decide their task is ambiguous and start a reflection loop, each of which makes several more model calls. One of those pulls ten documents for context. One document triggers a sub-agent to run a policy check, on a different model. By the time a simple counter sees the leaf calls, the money is spent. You didn’t overspend in one big step. You did it in two hundred small ones, each perfectly reasonable from where it stood, because no single step could see how much budget was left for the whole tree.

There are two more wrinkles. Cost per token depends on which model each step uses, and that choice is often made on the fly, so counting tokens without being able to change the model gives you tracking without control. And some work runs in the background, reflection and clean-up jobs that report back later, so a counter that only sees the main thread is always behind.

None of these are edge cases. They’re how any agent system that does more than one prompt and one answer behaves. It’s why monitoring after the fact can’t stand in for a limit that applies before each step.

What a limit that holds looks like

I’ll describe this by what it does rather than how to build it.

Before work starts, someone sets a ceiling for the job. Before each step runs, the system checks whether the step can be afforded given everything else already committed, across every branch of the work at once, including work that hasn’t finished yet. If it can’t, the step doesn’t start. The total never goes past the ceiling. Not “rarely”. Never.

The ceiling also shapes which model does what. Under a generous budget, each step gets its preferred model. As the budget tightens, steps where a cheaper model is good enough get the cheaper one. When even the cheapest acceptable option can’t be afforded, that piece of work stops and goes to a person. Stopping there is the system doing its job. The alternative is a system with no floor.

And the whole thing leaves a trace you can read afterwards: what was spent where, which model ran each step, and why anything was downgraded or stopped. Ideally that trace is the same record as the one that says what the agents did, so cost and audit can’t disagree. Deterministic replay is the audit trail goes into why that matters.

Reflection and context are where pilots come unstuck

The cost of a reflection loop isn’t obvious until you’ve run a few. A task that just executes and returns is cheap. Add a reflection cycle and the model has to read its own output, critique it, pass the critique back and write a revised version. Pull in extra context at each cycle and it grows again. One task with a couple of rounds of reflection can easily cost several times the plain version.

Reflection is often where the quality comes from, so banning it isn’t the answer. Pricing it is. If you can see the budget impact of allowing two reflection rounds instead of one before you commit to it, the trade-off between quality and spend becomes a decision someone makes, rather than something that just happens.

This is the pattern I’d bet sits behind a lot of abandoned pilots. The demo ran a few dozen tasks on clean data with generous model choices and two rounds of reflection, and the accuracy looked great. Production meant fifty times more tasks, more context on each one, and the same settings, because nothing linked those settings to the budget. Accuracy held. The bill didn’t.

Cost and rework are connected

There’s a link between cost control and rework that I don’t see discussed much. A lot of rework comes from steps run on the wrong model or without the context they needed, producing output that’s slightly off and has to be fixed by a person or another round of agents. Picking the model deliberately for each step, inside a budget, cuts the inference bill and also tends to cut the rework, because each step is matched to the work rather than chosen by default. I wrote about the rework side in AI made code cheap. Rework is where the money goes.

Questions to ask a vendor

The budget question separates systems that govern cost from systems that monitor it faster than any benchmark.

Ask them to show the system declining to start a task because it would break the ceiling. Not alerting. Declining. If what you see is a dashboard and a Slack notification, you’ve learned the system watches but doesn’t control.

Ask what changes when you lower the ceiling. If every step keeps the same model whatever the budget, the budget is decorative.

Ask where the cost record lives relative to the record of what the agents did. If cost is in a billing system, actions are in an orchestration log and model choices are in a config file, you have three sources of truth that will disagree during an incident.

Ask what happens when you run your own models on your own hardware. If cost control depends on a provider’s billing API, it disappears the moment inference moves in-house. For anyone who needs to run on their own ground, that’s the normal case.

Testing it in a pilot

Pick one expensive workflow where you know today’s cost: a quarterly control test, a coding backlog, a batch of applications with a known cost per item. Set the ceiling below what you spend now, low enough that the system has to make choices. If it can’t fit a useful amount of the work under that line, you’ve learned the economics aren’t there, and you’ve learned it cheaply.

Then watch three things. Does spend ever cross the ceiling? It shouldn’t, and if it does, that’s tracking, not control. Does the trace show cheaper models on easy steps and better ones on hard steps, changing as the budget tightens? And does the rate of work handed to people make sense? Too many stops means the ceiling is too low. None at all probably means you’re overspending on easy steps and could lower it.

Kizuna is built around the idea that agents work inside rules you set before they start, and a budget is one of those rules. We’re still in development and our pilot programme is open. If cost is the thing standing between your agent pilot and production, we’d like to hear from you.