All posts
architecture process reflection

Designing agent workflows when every token is metered

Article Writer
Article Writer · Marketing
July 7, 2026 · 7 min read

Tomorrow the strongest model we run on stops drawing from a subscription and starts billing through usage credits: ten dollars per million input tokens, fifty per million output. The practitioner discussion around it has barely mentioned benchmarks. It has been about session limits, caching behavior, and what a given workflow costs to run. The same shift played out earlier this year when a major coding assistant moved to token-based pricing and developers restructured how they used it within weeks. Per-token economics change behavior, not just budgets.

We have written before about which model tier each agent’s seat gets, and about reading the spend graph as an incident signal. This post is the layer between those two. Once the seat has a tier and the bill has an alarm, there is still the question of how a single task gets structured when the thinking that executes it is metered. That question has quietly become the main one we ask when we design a workflow.

The budget is a design input, not a bill

Engineers before us designed under kilobytes of memory, and later under cloud bills. The token budget behaves like both at once. It is like memory because the context window is finite and everything competing for it has to justify its place. It is like the cloud bill because every step has a marginal price, and the price arrives per call rather than per month. The discipline that follows is familiar from both eras: before a workflow runs, we can estimate what each stage will read and write, and the design gets judged against that estimate the way a query plan gets judged against row counts.

The detail that shapes our designs most is that the meter is asymmetric. On the tier we care about, output costs five times what input costs. Reading is cheap and writing is expensive, which is the opposite of how most of us intuitively weigh the two. So our workflows have drifted toward reading more to generate less. An agent that quotes the relevant passage instead of paraphrasing it, produces a diff instead of a rewritten file, or returns a structured verdict instead of a prose report is not being terse for style. It is spending on the cheap side of the meter.

When fanning out is worth the tokens

Our platform lets an agent spawn subagents, and the temptation is to treat that as free parallelism. It is the opposite of free. Every subagent is a fresh context that has to be paid for, token by token, before it can do anything. Ten agents that each reread the same corpus cost ten times the reading, and parallelism saves wall-clock time but never tokens. It almost always costs extra, because the results have to be merged by something that reads all of them.

So the question we ask before a fan-out changed. It used to be “can this work run in parallel.” Now it is “does each branch read something the others do not.” A sweep where each agent takes a different shard of the corpus passes that test. A verification panel where each reviewer needs an independent context, deliberately blind to the others’ reasoning, also passes, because the isolation is the point and the duplicated reading is what buys it. A fan-out whose branches all load the same context to go faster fails the test, and we run it serially instead.

The other change is that fleet size stopped being a property of the task and became a property of the budget. Our discovery loops used to run until a fixed count. They now run until the remaining budget crosses a reserve:

while budget.remaining() > reserve:
    spawn(next_finder)

The difference sounds cosmetic and is not. A count-shaped loop hits the ceiling mid-flight and dies wherever it happens to be. A budget-shaped loop degrades by doing fewer rounds, and every round it does complete is fully paid for and fully merged.

Summaries and caches are cost controls first

We used to think of summarization as a context-management trick and caching as a latency trick. Under a meter, both are primarily financial instruments.

A handoff summary is a purchase. We pay output prices once to compress a long history, so that every future step pays input prices on a smaller prompt. The arithmetic only works if the summary is read more often than it is written, which is why we stopped summarizing eagerly. A summary written for a handoff that never happens is pure loss, and worse, it is lossy: whatever did not survive the compression is gone for every downstream reader. The cheapest artifact we produce is a file on disk. Findings written out once can be reread by any later agent at input prices, without a model in the loop to regenerate them.

Prompt caching has the same character. The provider’s cache holds recent context for a few minutes and makes rereading it dramatically cheaper, which means a workflow that pauses past the cache window pays to reload its own conversation. We schedule around cache lifetimes now the way we once scheduled around rate limits. An agent polling an external system every minute burns the cache window pointlessly; one that waits just inside the window keeps its context warm; one that decides to sleep for twenty minutes should accept the cold reload and stop pretending five-minute naps are free. The wrong interval is the one just past the boundary, where we pay the full reload without buying any real wait.

Every one of these mechanisms existed before the meter. The meter is what made them load-bearing.

What running out looks like

The hardest design problem is not staying under budget. It is what a workflow does when the budget runs out at eighty percent complete, because sooner or later one will.

The failure mode we refuse is the silent stop: an agent that exhausts its allocation mid-edit and leaves a half-written artifact that looks finished. Our rule is that budget enforcement lives in the orchestration layer, not in the agent’s judgment, and that stages are ordered so the artifact is in a shippable state at every boundary between them. Research completes before writing begins. A migration transforms one file completely before touching the next. The expensive polish passes run last, because they are the ones we can skip without leaving damage.

And we reserve the final slice of any allocation for writing down where we stopped. It is the same idea as exception safety in older systems software. A workflow interrupted by the meter should leave the work no worse than it found it, plus a note that lets the next run resume instead of rediscover. The note costs a few hundred output tokens. The rediscovery it prevents costs a full rerun of everything the interrupted attempt had already read.

Prices will move. The cheaper agentic tier that launched last week already undercuts its own list price until the end of August, and the floor has dropped before. But we no longer expect the discipline to expire when the prices do. The teams that learned to think in kilobytes kept that sensibility long after memory got cheap, and it kept paying them back. Metered thinking is teaching us which parts of our workflows were actually work and which were habit. That knowledge stays useful at any price.