Your AI Agents Have a Meter Running. Here's the Bill Nobody Modeled.

The blended cost of enterprise AI fell 67% in a year — from $18.40 to $6.07 per million tokens between Q1 2025 and Q1 2026, per a Fortune analysis of roughly 2.4 billion enterprise API calls. For equivalent capability, a16z pegs the decline at closer to 10× per year.

Enterprise AI bills went up anyway.

Uber found this out the hard way. As first reported by The Information, the company burned through its entire annual budget for AI coding tools in about four months — adoption of one tool jumped from 32% of its ~5,000 engineers in February to 84% by March, with power users spending up to $2,000 a month each. Uber’s CTO said he was “back to the drawing board” on budgets; per Bloomberg, the company now caps every employee at $1,500 a month, per tool.

And notice what that story actually was: humans using AI tools, with a person watching every session. Autonomous agents are the same meter running 24/7 — with nobody at the keyboard. If supervised usage can vaporize an annual budget in four months, unsupervised loops deserve a much harder look.

Uber is not the outlier. The FinOps Foundation’s State of FinOps 2026 — 1,192 practitioners managing over $83 billion in cloud spend — found that 73% of organizations exceeded their AI cost projections, and that 98% now actively manage AI spend, the fastest-rising cost category in the survey’s history.

Cheaper tokens, bigger bills. The math only works one way: enterprises are budgeting for how much work agents do, but agents don’t bill by work done. They bill by how much they have to re-read to remember what they’re doing.

And this is no longer a finance-department problem. Uber’s CTO reportedly burned $1,200 in a single two-hour session himself. When cost accrues one API call at a time, it’s decided at the keyboard, not in a budget spreadsheet — the engineer who ships an agent, the ops lead who approves it, the architect who designs it, and the finance team who forecasts it all own a piece of the same bill. Which means everyone on the team needs to understand how the meter actually works.

Most cost models miss this entirely. Let’s fix that — with real numbers.

First, understand how an agent actually bills you

An LLM has no memory between calls. None. Every time an agent “takes a step,” you’re making a fresh API call, and the only way the model knows what it already did is if you re-send the entire history — system prompt, tool definitions, every previous action, every previous result.

So a typical agent loop looks like this:

The message array only grows. Every turn, you re-buy every token you already bought. Anthropic’s own engineering team has published the multipliers: agents consume roughly 4× the tokens of a chat interaction, and multi-agent systems about 15×.

The consequence is nasty: input tokens per turn grow linearly, but cumulative billed input across the loop grows quadratically. Say your system prompt plus tool definitions come to 2K tokens, and each turn adds ~1K of new material (a tool call plus its result):

• Turn 1: 2K input
• Turn 2: 3K input
• Turn 3: 4K input
• Turn 10: 11K input
• Total billed across 10 turns: ~65K tokens — for a “conversation” that is only 11K tokens long.

You paid for 65K. The actual transcript is 11K. The other 54K was re-transmission.

And one more tax nobody budgets: tool schemas are serialized into the prompt on every single call. If your supervisor agent has 30 tools registered, you pay for all 30 schemas — roughly 4,500 tokens — on every turn, even if the run only ever touches 2 of them. Over a 10-turn loop, that’s 45,000 tokens spent describing tools that were never used.

That’s the theory. Now let’s watch it happen to one email.

One real email, fully billed

The task: an agent watches a shared Office 365 inbox, classifies each incoming email (invoice? complaint? purchase order?), and files it into the right folder. About as simple as automation gets.

Here’s the email that just arrived:

Our agent is lean and well-built: a 500-token system prompt (classification rules, folder mappings, guardrails) and 8 Office 365 tools registered (~1,500 tokens of schemas). Fixed overhead: 2,000 tokens per call. The fetched email comes back at ~400 tokens; the extracted invoice text from the PDF is ~600 tokens.

Processing this one email takes four model calls. Here is every one of them, billed:

Three things to sit with:

The business case said 600. If you’d estimated this the way most pilots do — fetch ~100, download ~100, classify ~300, move ~100 — you’d have budgeted 600 tokens. Reality billed 19× that. Now you know exactly why 73% of enterprises overshot their projections: the pilot math counted the work; the production bill counted the re-reading.

70% of the bill is the agent re-reading its own instructions. The 2,000-token fixed block (system prompt + tool schemas) was billed on all four calls — 8,000 of the 11,280 input tokens. The agent spent four times more tokens re-reading its own setup than it spent reading the actual email.

The final transcript is only ~3,500 tokens. You were billed 11,700. The gap is pure re-transmission — and this was a short loop. This same math on your 10-turn document agents and 15-turn research agents is what the quadratic curve above does to them. Add retries, error handling, or verbose API JSON (a raw Graph API response is often 1,000+ tokens before trimming), and these numbers are the generous case.

Now ask the only question that matters

Look at those four calls again. Which one needed intelligence?

Call 3. The classification. Reading an unfamiliar email and judging “this is an invoice, route it to Accounts Payable” — that’s real judgment, different for every email.

Calls 1, 2, and 4? Fetching a message, downloading an attachment, moving an email to a folder. That logic never changes. It’s the same API call today, tomorrow, and next quarter. Yet the agent architecture forces every one of those calls through the LLM — each time re-sending the full history — so you pay intelligence prices, with compounding interest, for plumbing.

That’s the root cause. Not token prices. Architecture.

So let’s name the fix: the Hybrid Agent

A Hybrid Agent is an automation that separates build from run. It works in three phases:

Build once. Run a million times. That’s the whole idea — and it’s what makes the automation dynamic and deterministic at the same time, instead of forcing you to choose.

The intellectual roots here are solid, and worth naming. Anthropic’s influential Building Effective Agents essay drew the foundational line back in 2024: workflows follow predefined code paths; agents dynamically direct themselves — and you should use the simplest one that works. The research world has been converging from the other side: Stanford’s DSPy treats LLM pipelines as programs to be compiled rather than prompted repeatedly, and CMU’s Agent Workflow Memory showed that agents which distill their own successful runs into reusable workflows complete tasks in dramatically fewer steps. The Hybrid Agent connects those threads into one operational loop an enterprise can actually run: build, run, heal.

Here’s our same email, processed by a Hybrid Agent:

Notice what disappeared. No tool schemas — the workflow already knows its tools. No agent system prompt — just a 150-token classification instruction. No history — there’s no loop to remember. The one intelligent call sees exactly what it needs to judge, once, and nothing else.

One honest caveat: the exact ratio depends on the shape of the process. The bigger the judgment step relative to the plumbing — think heavy document analysis, where the one LLM call might itself consume 10K tokens — the smaller the saving. Across real processes, the range runs roughly 60–95%. Email triage sits near the top; the principle holds everywhere the plumbing outweighs the thinking.

“Can’t you just optimize the agent?”

Every engineer reading this is thinking it: prompt caching. Sub-agent delegation. Context trimming. And yes — these help. Cache the fixed system prompt and tool schemas, delegate steps to smaller sub-agents with narrower context, trim verbose tool results, and teams realistically shave 30–50% off the bill. Call it 40%.

But look at where that lands you:

You optimized your way from 19× over budget to 12× over budget. The optimized agent still costs ~6× what the Hybrid Agent does — because every optimization is a discount on re-transmission, and discounted re-transmission is still re-transmission.

The fine print makes it worse in practice. Prompt caches expire quickly by default — Anthropic’s default TTL is about five minutes — which is great for a chatty loop firing calls seconds apart, and nearly useless for a scheduled automation that runs a few times an hour and hits a cold cache every time (while still paying the cache-write premium). Sub-agents carry their own system prompts and re-receive the context you hand them, so delegation moves overhead around more than it removes it. And output tokens — the expensive ones — are never discounted by caching or anything else.

The sharpest engineers will raise a better objection: “We already build it this way by hand — a deterministic trigger, one model call, deterministic actions. That’s just good engineering.” They’re right — and that hand-built pattern is the run phase of a Hybrid Agent. But two things. First, the 73% overshoot number tells you that’s not what most organizations actually ship; the agent-loop default is what ships, because it’s what every framework hands you out of the box. Second, a hand-built pipeline is frozen the moment its author moves to the next sprint — nobody’s watching it, and when the world changes, it breaks and waits in a backlog. The claim here isn’t that the run phase is novel. The claim is that the build and the heal around it can now be automated — so the disciplined architecture stops depending on your best engineers hand-crafting and babysitting every pipeline.

The workflow engine needs none of these tricks. There’s nothing to cache, because nothing is re-sent. Optimization shrinks the meter. Architecture removes it.

To be fair: sometimes you need the full agent

This isn’t an anti-agent argument. Full agents are the right tool when the process itself changes with every execution.

Customer support is the canonical case. The process is the conversation — it branches on what the customer says, escalates unpredictably, and needs live judgment at nearly every turn. There is no stable sequence of steps to compile, so there’s nothing for a workflow engine to run. The token bill buys you genuine adaptability, and it’s worth paying.

But that’s not what most enterprise automation looks like. B2B back-office work — invoice processing, email triage, order-to-cash, onboarding packets, report generation, reconciliations — runs the same steps in the same order every time. Only the data changes.

So here’s the test to run on every automation in your pipeline:

If the process varies — support conversations, open-ended research, exploratory analysis — use a full agent and pay the meter gladly. If only the data varies, and you’re running it through an agent loop anyway, you’ve built a workflow wearing an agent costume — billed by the thought.

Most enterprise processes, honestly audited, fall in the second bucket.

“But things change. Things break.”

They do — and this is where traditional deterministic automation dies. An API changes, a new email format appears, a folder gets renamed. The old-school answer is a broken bot and a ticket waiting for a human.

This is the Hybrid Agent’s third phase — Heal. When the workflow hits something it can’t handle, the agent wakes back up: inspects the failure, repairs the workflow, completes the job that was mid-flight, recompiles the deterministic version, and goes back to sleep.

And before anyone in a regulated industry raises the obvious question — no, the agent doesn’t silently rewrite production logic. Every repair is a versioned diff: the agent proposes the fix, the change is reviewable, and in regulated deployments it gates on human approval before the recompiled workflow goes live. That’s the point of compiling in the first place — a workflow change is a concrete artifact you can inspect, approve, and roll back, not a shift in a model’s mood. Healing doesn’t break the audit trail. It is an audit trail.

Let’s cost that honestly, using the same math as everything above: a real repair is itself a multi-turn agent session — call it ~15,000 tokens, about the price of one full agent run. Say it happens twice a month: 30,000 tokens. And here’s the beautiful part — that repair budget scales with how often the world changes, not with how many emails you process. It’s a flat line while your volume grows.

Agent adaptability, workflow economics. Dynamic when it matters. Deterministic when it doesn’t.

Scale it, because your inbox isn’t one email

Monthly totals, 30 days, repairs included:

In money, at standard frontier mid-tier pricing (~$3/M input, $15/M output): the pure agent costs about 4¢ per email, the optimized agent about 2.4¢, the Hybrid Agent 0.4¢. At 300 emails a day, that’s roughly $4,300 a year versus $2,600 versus $430 — for one inbox, on one task. A typical enterprise automation pipeline runs 100–200 such processes. Multiply it out and the pure-agent architecture is a half-million-dollar-a-year line item that the Hybrid Agent handles for a tenth of the price. Cheaper models shrink every column — but never the ratios, because the ratios come from the architecture.

And the gap gets worse for agents as processes get richer. Add four more steps to a hybrid workflow — a validation, a lookup, a notification, an archive — and the token cost stays ~1,200, because deterministic steps are free. Add four more steps to an agent loop and you’ve added four more turns to a quadratic curve.

There’s a second dividend, and for regulated industries it matters more than the money: deterministic runs are auditable runs. The same input produces the same steps, every time, with a traceable log. When a compliance team asks “why did the system do that?”, a compiled workflow has an answer. A reasoning loop has a probability distribution.

How AutomatR solves this: Hybrid Automation in production

This architecture isn’t a thought experiment for me. It’s the bet we’ve made at AutomatR.

We call the category Hybrid Automation: an AI agent builds the automation once — resolving your intent into a deterministic workflow — and our execution engine runs it at scale, invoking AI only at the steps that genuinely need judgment. When something breaks, the agent wakes, heals the workflow, and goes back to sleep. Build once, run a million times, in production today across pharma, banking, and manufacturing — including fully on-prem and air-gapped deployments, where both the token bill and the audit trail are board-level concerns.

It’s also why we made a pricing decision that follows from the architecture: AutomatR bills on runtime, not token consumption. When your platform doesn’t burn tokens on plumbing, you don’t have to bill like it does.

If you’re running the process-vs-data test on your own automation pipeline and want to compare notes — or you’ve got an agent bill that looks like Uber’s — my DMs are open.

Further reading: going deeper on agent token economics

If this piece made you want to audit your own stack, these are the resources I’d start with:

• Anthropic — Building Effective Agents — the essay that defined the workflows-vs-agents distinction and argued for the simplest architecture that works: anthropic.com/engineering/building-effective-agents
• Anthropic — Effective Context Engineering for AI Agents — why context is a finite resource and how to curate what an agent actually sees: anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic — Prompt Caching docs — the exact mechanics: cache TTLs, the ~90% read discount, the write premium: docs.claude.com/en/docs/build-with-claude/prompt-caching
• OpenAI — Prompt Caching guide — the automatic-caching design and its 1,024-token minimum: platform.openai.com/docs/guides/prompt-caching
• PromptHub — Prompt Caching across OpenAI, Anthropic, and Google — a clear side-by-side of how each provider’s caching and pricing actually behaves: prompthub.us/blog/prompt-caching-with-openai-anthropic-and-google-models
• DSPy (Stanford, arXiv:2310.03714) — the “compile your LLM pipeline instead of re-prompting it” research lineage: arxiv.org/abs/2310.03714
• Agent Workflow Memory (CMU, arXiv:2409.07429) — agents that distill successful trajectories into reusable workflows: arxiv.org/abs/2409.07429

One last question

Run the process-vs-data test on your own pipeline this week. Then answer honestly:

How many of your “agents” turn out to be workflows wearing an agent costume?