You deployed an agent to handle a 5-step workflow. In testing, it ran clean. In production, your LLM bill jumped $3,000 in a week. When you asked which agent caused it, nobody could tell you.
This is not a bug in your agent. It's a visibility problem built into how agents actually work in production.
A single API call is simple to budget for. You send tokens in. You get tokens out. You pay for both. Done.
An agent working through multiple steps is different. It's not one call. It's several full-context calls stacked one after another.
Here's what actually happens. Your agent starts step 1 of a 5-step workflow. The LLM processes the system prompt, the task, and any context you passed in. It returns an answer. Cost: maybe 500 tokens.
Step 2 runs next. But now the context includes the original system prompt, the original task, step 1's output, and the new instruction for step 2. The LLM processes all of it. The cost doubled.
Step 3 adds step 2's output to the context. Context grows again. Tokens grow again.
By step 5, the context is 3x larger than step 1. The model processes all of it every iteration. Most operators don't realize this is happening until the invoice arrives.
You thought you were paying for one task. You were actually paying for five full-context calls, each one bigger than the last.
This is where the real cost problem lives.
In a short workflow with 3 to 5 steps, context growth is manageable. You might pay 2x or 3x what a single API call would have cost.
But something changes when you deploy agents in real production. The agents run all day. They handle different tasks. They fail and retry. They accumulate context.
An agent that handles customer support tickets doesn't just run step 1, step 2, step 3, and stop. It runs dozens of times a day. Each execution adds to the conversation history. Each retry adds more tokens. Tool outputs accumulate. Context balloons.
An engineer's monthly bill for LLM costs can easily dwarf their actual salary once you stack multiple agents running without supervision.
You can't see any of this happening. Your monitoring dashboard shows your agent is working. Your logs show it completed tasks. Your bill shows a number you don't understand.
Here's the hard truth: most operators don't have visibility into token spend by agent, by workflow, or by execution.
You know your overall LLM bill. You don't know which agent caused 60% of it. You don't know if the customer support agent is cheap or catastrophic. You don't know if the document processing workflow is running tight or bloated.
Without that visibility, you can't make intentional tradeoffs. You can't tune cost. You can't budget for it. You can't hand the agent to a team and tell them what it actually costs to run.
The decision point is before you deploy, not after the bill arrives. This is similar to how ownership and visibility shape what breaks in your operations. If nobody knows who's accountable for cost, nobody optimizes for it.
You need to build cost tracking into your agent architecture from day one. This means measuring tokens at each step. This means logging context size at each step. This means knowing the cost of a single execution before you let the agent run 1,000 times.
The operators who stay in control of cost are the ones who measure it in staging, make intentional choices about tradeoffs, and deploy with limits, not hope.
Three metrics separate operators who control cost from operators who get ambushed by it.
First: tokens spent per step. You need to know what each step actually costs. Not an estimate. Not a guess. Real data from a real run. If step 1 costs 200 tokens and step 5 costs 800 tokens because context grew, you need to see that pattern before you deploy.
Second: how deep can the agent go. How many steps can your agent take before context growth becomes unacceptable? If your agent starts going deeper than planned, retrying, adding context, when do you kill it? You need to decide this before the agent runs, not after it costs you $500.
Third: total token budget per task. You need a hard ceiling. A task gets N tokens. If it needs more than that, the task fails and a human handles it. This is not a limitation. It's the only way to run agents at scale without your bill becoming unpredictable. Setting approval gates and handoff points is how you stay operationally sane, and the same principle applies to cost.
Set these limits in staging. Watch the agent run. See where context grows. See where it fails. Adjust before production.
The operators who skip this step end up with agents that seemed cheap in testing and catastrophic in production.
Agents doing multiple steps are not cheaper than single API calls. They're a different cost structure entirely. You own that cost. The only way to stay in control of it is to see it happening in real time, before the bill arrives.
Visibility is not optional. It's the first decision you make when designing an agent for production.
This means measuring token count at every step. This means setting hard limits on how deep the agent can go and what it costs to run once. This means logging what the agent did, how much it cost, and why. This means being able to answer the question "which agent burned $3,000 this week" before the bill arrives.
The operators running agents successfully in production are not the ones with the most sophisticated models. They're the ones with the clearest visibility into cost.
If you're building agents into your company, start here. Measure token spend before you measure anything else. Make visibility non-negotiable from day one. You'll deploy faster, fail smaller, and stay in control of the cost.
Acrein Group builds and runs agentic operations for founders and operators. We instrument token tracking into every workflow because we run these systems and we see exactly what happens when visibility is missing.
The right conversation at the right moment changes everything. Let's have it.
Talk to us