15 Billion Tokens Later: One Agent Was Not Enough

Why better requirements, decomposition and orchestration matter more than another coding model.

When I published 14 Billion Tokens Later: AI Cost Optimization Is a Systems Design Problem, my usage dashboard showed 14.6 billion lifetime tokens.

A few days later, it crossed 15 billion.

Apparently, my AI factory had not yet read the section about cost optimization.

The first article focused on the architecture of AI costs: context inflation, premium models used for routine work, uncontrolled loops and the hidden cost of human correction. It ended with a transition from prompt engineering to process engineering.

This article starts exactly there.

A well-designed AI infrastructure can still become expensive when the task entering the process is vague, oversized or missing basic analytical work.

The ambiguity tax

The most expensive prompt is not necessarily the longest one. The most expensive prompt is the one whose meaning must be reconstructed by the agent.

Consider a simple instruction: “Add a ranking feature to the application.” It sounds compact, but it hides a complete analytical problem. What is being ranked? Which data determines the score? What does an acceptable result look like?

If those questions are not answered before implementation begins, they do not disappear. They become work for the agent.

The system must inspect the repository, infer the business intent, reconstruct the data model, make architectural assumptions, generate code, test them and revise its own earlier decisions. The invoice will not contain a separate line called ambiguity tax. The cost appears as repeated context loading, rejected outputs and implementation paths that never reach production.

A human team has natural throughput limits. People stop, ask questions and challenge assumptions. An AI agent can begin immediately and implement the wrong interpretation with impressive speed and technical quality.

The result may be a perfectly engineered feature that nobody actually needed.

A prompt is not a requirement

Prompt engineering taught us to write better instructions. That was useful, but it was not enough.

A prompt is a communication unit. A requirement is an analytical structure.

A useful implementation task should define three things clearly:

• Purpose and scope: why the change is needed, what must be included and what must remain untouched.
• Decision boundaries: which assumptions are already accepted and which decisions still belong to the human.
• Acceptance: what must be delivered and how the result will be verified.

This is not a return to documentation produced for the sake of documentation. The purpose is to reduce the number of valid interpretations before expensive execution begins.

Better decomposition enables better orchestration

Clear requirements are only the first step. A large requirement still has to be divided into units that can be assigned, executed and validated independently.

Without decomposition, an orchestrator receives one large instruction: build the feature. It can choose a model and launch an agent, but it has very little to optimize.

After decomposition, the same requirement becomes a structured portfolio of work. Business analysis, architecture, implementation and verification can be separated. Some tasks can run in parallel, while others wait for a decision or the result of an earlier stage.

This makes routing possible. A smaller model can classify or format requirements. A stronger reasoning model can assess architectural impact. A coding worker can implement a bounded change, while another agent performs an independent review.

Without decomposition, orchestration is little more than launching a powerful agent. With decomposition, it becomes process management.

Decomposition also changes the economics of failure. If one worker generates an incorrect migration, the process does not need to restart the business analysis, interface design and test strategy. The failed work package can be corrected on its own.

The useful economic unit is therefore no longer a single prompt or even one agent session. It becomes the cost of an accepted work package.

Decomposition is not fragmentation

Dividing work into smaller parts does not automatically make the process better. A task can become too large to control, but it can also become too small to justify the coordination around it.

Every new agent session adds initialization, context retrieval and another handover. Excessive fragmentation replaces the ambiguity tax with a coordination tax.

A good work package should therefore be coherent, independently testable and stable enough to become the foundation for the next stage.

What has not been committed cannot become the foundation for further development.

In my workflow, a commit is not merely a repository operation. It is a checkpoint confirming that a defined piece of work has been implemented, tested and accepted. The next agent session starts from verified state instead of unfinished assumptions.

Why coding with AI becomes expensive

At this point, another pattern becomes visible: a coding agent is rarely only coding.

When it receives a broad instruction, it often compensates for several missing project roles at once. It tries to understand the business need, reconstruct the system impact, design a solution, implement it, test it and review the result.

In a traditional team, these responsibilities are distributed between several layers. In an AI workflow they are often compressed into one token-consuming loop.

• The agent analyses a requirement that was never properly analysed.
• It creates architecture because no architectural decision was provided.
• It verifies assumptions that it invented itself during implementation.

This is the missing roles tax.

Removing a role from the organizational diagram does not remove its function from the delivery process. Someone—or something—still has to understand the need, evaluate dependencies and decide whether the result is acceptable.

If this work is not completed before coding begins, the coding model performs it during implementation. We then pay a coding model to analyse ambiguity, reconstruct architecture and repeatedly correct its own assumptions.

From one agent to an AI factory

This is the point at which coding with AI stops looking like a conversation with an assistant and starts looking like a production system.

In my current workflow, a large pull request represents a substantial feature. A high-capability architecture agent prepares the structure. The main orchestrator divides the pull request into agent sessions. Coding workers implement bounded tasks, tests verify the results, and accepted changes are committed before the next layer begins.

When one session reaches its practical context limit, it leaves a clear status: what was completed, what was committed and what remains. The next session continues from a verified checkpoint instead of restarting the project.

One agent was no longer enough—not because the models were weak, but because my ideas and projects began arriving faster than a single linear session could process them.

The solution was not merely to buy a stronger model.

The solution was to design a factory.

More autonomy requires better preparation

There is a temptation to believe that stronger models reduce the need for precise requirements. In practice, the opposite is often true.

A weak system cannot travel far in the wrong direction. A strong autonomous agent can modify many files, introduce abstractions, rewrite tests and produce documentation before the human notices that the original interpretation was wrong.

Autonomy multiplies execution capacity. It does not automatically improve the quality of the objective.

Better decomposition therefore does not restrict AI. It creates safer autonomy. A worker with a clear goal, bounded scope and acceptance criteria can act independently inside its work package. The orchestrator only needs to intervene when a dependency is missing, a decision exceeds the worker’s authority or the cost boundary has been reached.

From token economics to delivery architecture

The first article argued that the real unit of AI economics should be closer to cost per accepted outcome than cost per million tokens.

For AI-assisted software development, the definition can be more precise:

Cost per accepted, tested and committed change.

This includes requirement preparation, architectural decisions, implementation, testing, retries and human intervention. A mature AI delivery system does not minimize every cost separately. It optimizes the complete path from an idea to an accepted product increment.

Sometimes that means spending more tokens during analysis to avoid a much more expensive implementation error. Sometimes it means using a premium model for architecture and cheaper workers for execution. Sometimes the most economical action is to stop the agent and ask the human one precise question.

Conclusion

Fifteen billion tokens later, my conclusion is not that AI coding is inherently too expensive.

The problem is that we often ask one coding agent to compensate for an incomplete delivery process. Analysis, architecture, testing and coordination disappear from the visible workflow—then reappear inside the model’s context window.

The roles disappear from the diagram. Their work remains on the bill.

Better requirements reduce ambiguity. Better decomposition creates routable work. Better orchestration assigns that work to appropriate models and agents. Stable checkpoints prevent unfinished assumptions from becoming foundations for further development.

The first article ended with a simple observation:

The cheapest token is the one your system never had to generate.

The continuation is equally simple:

The cheapest coding task is the one your agent does not have to analyse, redesign, implement, test and reinterpret at the same time.

AI does not eliminate the software delivery process.

It makes the quality of that process visible—one token at a time.