You can afford the AI pilot. Can you afford the production system?

Suppose an agent completes one business transaction using 5,000 tokens. On its own, that number doesn't look particularly alarming. Depending on the model and how those tokens are distributed, an individual transaction may seem trivial.

Now give the system 10 million transactions. 5,000 transactions become 50 billion tokens. At 100 million transactions, we are at 500 billion.

Nothing about the individual task changed. We allowed multiplication to do what multiplication does.

This token consumption is one reason I think the economics of agentic AI needs to become an architectural question much earlier than it often is.

What are we actually paying for?

A simple interaction model can be relatively easy to understand. Information goes in, the model produces a response and tokens are consumed.

Agents can be more interesting. To complete one task, an agent might retrieve contextual information, ask a model to interpret it, reason, call a tool, inspect the result and decide what to do next. It may repeat parts of that sequence several times, and an unexpected result can send it down a different route altogether.

This reasoning is part of what makes agents useful. They can work through a problem instead of merely following a predefined sequence. It also means that the price of one model call tells me very little about the economics of the completed job.

I would want to know: 

• how many calls the agent needed 
• how much context it carried into these calls 
• which tools it used 
• and how often it repeated an action 

I would also want to see whether an easy case behaves differently from a difficult one. Then we have something meaningful to multiply.

You may also find parts of the process where the smartest AI decision is to stop using AI.

Pilots hide multiplication rather well

With a limited group of agents, inefficiencies may barely register. The agent might receive far more contextual information than it needs. Perhaps it uses a highly capable model for tasks a less capable one could handle, or one particular tool causes it to retry frequently.

At enterprise transaction volumes, details like these begin to matter.

There are several ways to improve the economics. Teams could examine model selection, routing, caching, context size and how agents use tools. Monitoring runtime behavior could reveal where the expensive cases originate rather than merely showing the total bill afterward.

Before doing any of that, however, I would examine a more basic question:

Does the system need to think about this again?

Imagine that an agent has done something genuinely difficult. It has interpreted an unusual request, collected information from several sources and established the facts of the case. The next step is governed by a business rule that the organization has already defined, tested and approved.

We could give that rule to the model and ask it to work out the answer each time. At high transaction volumes, the system would repeatedly pay for reasoning to arrive at logic the organization has already established. If an existing deterministic service can apply the rule directly, the agent can call that service and continue with the result.

Model-based reasoning remains available for the part of the problem that required reasoning in the first place.

Follow the cost back into the architecture

A monthly AI bill is an operating figure, but it can also tell us something about the design: 

• If one class of transaction repeatedly consumes far more tokens than another, why? 
• If the agent keeps looping, what sends it back? 
• If every transaction invokes the most capable model available, does every transaction genuinely require that advanced capability?

Questions like these can expose design decisions that were almost invisible during the experiment.

They matter beyond financial cost too. Reasoning consumes computing resources and energy. Precise environmental impact depends on infrastructure, hardware, model choice and energy sources, so broad carbon claims need to be treated carefully. The basic engineering question is simpler: Does the reasoning add useful value to the result?

This point is where economics and architecture begin to overlap. If reasoning provides value, we should be prepared to pay for it. If the system repeatedly asks AI to rediscover an answer we already have, the problem may lie in how we designed the system.

Do the multiplication early

Pilots should tell us whether an idea works. I wouldn't burden every experiment with the full operating model of some future production system.

Before scaling it, though, do the multiplication. Measure what a completed task consumes. Look at the difference between simple and complex cases, examine the agent's tool calls and retries, and compare those figures with the transaction volumes the real system will face.

Then look at the expensive steps and ask why they need AI reasoning. 

You may decide that the reasoning is worth every token. You may also find parts of the process where the smartest AI decision is to stop using AI.

 

We’re looking forward to our sponsorship at Adopt AI 2026, December 3-4, in Paris. Each Thursday leading up to the event, Agile & Digital Enterprise Architect Peter Kalmijn, a member of the Future Makers Research Community (FMRC) at Atos, will explain why good AI architecture starts by saying no.