Building agents for on-call and incidents?

Token efficiency in AI agents: charging for the work, not the tokens

Varun Krovvidi, Product Marketing at Resolve AI, on why token counts became the industry's scoreboard, what a well-run investigation reads and skips, and why Resolve AI bills for completed work instead of consumption.

Why did tokens become the scoreboard for AI?

Because nobody knew how to evaluate AI's outcomes, so people measured what they could count. Token usage became a flex. But a token count just represents how hard the AI is working, and how hard it's working doesn't really matter. A big bill can mean a hard problem, a thorough investigation, or an agent going in circles, and the count can't tell you which. What matters is the outcome it helped you deliver.

What does token efficiency actually measure?

The tokens you burn to get one outcome done. For that to mean anything, the outcome has to be a real unit of work, and for Resolve AI that is investigating an alert, or getting an engineer to the root cause of an incident.

That closes an obvious loophole: an agent can't look efficient by quitting early, because a cheap run that stops at the wrong answer didn't actually deliver the outcome. Cost should be predictable. Quality should be high.

Where is the token game won or lost?

Context. An incident throws off far more evidence than the answer needs: deployment history, config changes, logs, and metrics across every service the request touched. The agent pays for whatever it decides to read, so where it looks matters more than which model it runs. An agent that starts from the change that shipped an hour before the alert reads a fraction of what a service-by-service log-trawling service does, and it usually gets to the answer sooner.

What do underexploring and overexploring look like in an investigation?

Think of the agent like a detective.

  • A stupid detective takes the first answer it gets and closes the case. That's underexploring. It looks cheap, but a first plausible explanation and the actual root cause are different things, and every wrong conclusion sends an engineer back in to redo the work.
  • A nervous detective speaks to everyone in town. That's overexploring: it pays for evidence it never needed and might not even reach a conclusion.

A smart detective does neither. It first gets a map of the city, asks different kinds of questions across different sources, and has to understand code, infrastructure, and telemetry to get to the precise answer. It stops when the sources agree, not when there's nowhere left to check.

Why does quality peak instead of climbing with more context?

Plot agent quality over the amount of context you're giving the agent, and it'll look like a hill.

  • On the left, you've underexplored and quality is low. The agent is guessing: with too little evidence, the most plausible story wins, and that story isn't reliably the true one.
  • On the right, you've overexplored and quality is low again. Every extra document competes for the model's attention with the ones that matter, so beyond a point, more context makes the answer fuzzier rather than sharper.

There's a peak at the top, and no fixed amount of context keeps an agent on it. The Resolve AI team cracked this early, and reaching that peak in every investigation is what the research is about.

How do you engineer an agent to stay near the peak?

It's genuinely a hard engineering problem, and three decisions carry most of the cost.

  1. Use cheaper tokens for cheaper tasks. You can't run the most capable model on every simple step; a frontier model summarizing a log file is a waste, so routine work goes to smaller models, and the expensive one handles only the steps that actually need it.
  2. Make tool calls precise. Every time the agent uses a tool, the tokens go through the roof, because whatever the call returns sits in the context window for every turn after it. One sloppy fetch keeps costing until the investigation closes.
  3. Make today's investigation context for the future. Most of what an investigation learns, which services depend on which, and where the system tends to break, is still true next month. An agent that has to rediscover all that every time is paying twice for the same knowledge.

Why does Resolve AI charge on outcomes instead of tokens?

Resolve AI charges for the amount of work the agents do, the investigations run, and the root causes found, not for the tokens burned along the way.

That means taking on the token-efficiency risk at scale. It also makes the hill a business problem rather than just a research one: an agent that overexplores now costs Resolve AI money on every run, so the company has the same interest in efficiency as the customer does.

What does that change for a customer building a budget?

It gives the customer a fixed number. Someone writing a budget sheet shouldn't lose sleep over how many tokens the agents will burn. With outcome pricing, they don't have to; they put down a fixed cost for the amount of work they expect, which, for a platform team, is roughly the alert and incident volume they already track. How many tokens that work takes is Resolve AI's worry.