The economics of agentic AI: Questions to ask before implementation
Three decisions to make: What do we automate? Which architecture should we run it on? And which plan do we execute?
All three are governed by one question.
Does it create enough value to justify the cost and the risk?
A few months ago, I was in conversation with the head of operations at a leading utilities company. A question came up that neatly captures the current state of agentic AI in the enterprise.
“We have deployed AI agents in three areas. They work. But when I ask how much each AI decision costs us, nobody in the room can answer.”
This was not about the monthly cloud bill; that was fully under control. It was something deeper. There was no way to link spend to a specific query, workflow, agent or user. And above all, there was no way to decide, before running a task, whether it justified the cost it was about to consume.
In my experience, that gap is the most significant blind spot in the current adoption of agentic systems. And it is not solved with more observability tooling, but with a different design principle.
Optimization efforts and why it is not enough
Over recent years, efforts have been concentrated on evaluating and deploying AI models, frameworks and specialized solutions. These are mature and valuable tools, but they all share an implicit assumption: once an execution plan has been decided, it gets executed. The problem is that, in a real agentic system, the cost, latency and reliability of a plan are not known until a commitment has already been made. By the time they surface, course correction can be an expensive or futile effort.
The market’s customary answer has been FinOps and observability: instrumenting the system to know, after the fact, how much was spent and where. It is necessary, but insufficient because it explains spend after it has occurred, rather than shaping it before it happens.
And the orders of magnitude already warrant it.
Consider this simplified example: an agentic workflow handling five thousand queries a day, with an average chain of six to eight model invocations per query and several calls to external tools, can easily run up bills to the tune of hundreds of thousands of euros a year in model and API consumption alone. That is the order of magnitude you can typically see once use cases move from internal pilots to recurring business processes.
You may object that the price per token is falling steadily and that the problem will solve itself. However, experience suggests otherwise.
Consumption grows faster than prices fall, because every price drop enables more agents, longer chains and more tool calls. Unit-price deflation does not excuse anyone from governing spend; what it chiefly makes cheaper is the mistake of automating what should never have been automated. Faced with figures of this order, the question stops being technical and becomes one of governance: is the money being spent well?
The economic unit has changed
Traditional FinOps established a solid discipline: informing, optimizing and operating cloud spend, and the market’s established players have taken it to a remarkable level with platforms capable even of anticipating cost events. It is rigorous work. It is worth noting, however, where it impacts. On the infrastructure. On the instance, the container, the workload. The economic unit is the machine.
In an agentic system, the economic unit is not the machine. It is the query, the chain of reasoning, the execution plan that the orchestrator is about to launch. And that unit, the most decisive one in the economics of AI, is precisely the one that goes ungoverned at the moment that matters: before it is consumed.
Reframed from that angle, the design question is no longer “how do I reduce the cost of my infrastructure” but something more demanding. Questions that should be asked are:
- What genuinely deserves to be automated?
- On which model or architecture should it run?
- And how does the system come to decide, by itself and before acting, whether a specific plan justifies its cost?
These are three chained decisions, and they are best addressed in that order.
First level: Choose what to automate
Before any architectural consideration comes a prior decision, more strategic than technical: not every process deserves to become an agent.
I see organizations automating processes with agents where it is simply not required: because of low volume, a high cost of error, problems better solved by human judgement or, quite simply, the absence of any meaningful return. Any automation out of inertia guarantees two things: running inefficient processes faster and making the system more expensive.
Before writing a single line of architecture, you should map the operation by value streams. Walk the value flow. Decompose it and identify points where two conditions coincide, namely a clear return on investment and high operational impact. These are the legitimate candidates for agentic orchestration. We need to stop talking about isolated use cases and start talking about redesigned processes that orchestrate humans and agents within a single flow.
It is a deliberate filter. High-impact tasks with an unclear return can wait. So can clear-return tasks with marginal impact. Rather, the perfect opportunity lies at the intersection where automation releases tangible value and the process carries enough operational weight for that value to show. Starting there does more than maximize the return: it builds the internal credibility the subsequent phases will need.
Second level: Zero in on the architecture
Once the decision of what to automate is settled, a second one appears: Which architecture do we choose? This may seem equally important in its impact on cost but is usually debated with less rigor than it deserves.
Mature AI architecture is neither a product nor a single approach; it is a portfolio of coexisting decisions. Some organizations operate on premise for cost control or data sovereignty, and in many contexts that is the right call. In others, the business justifies bringing in a frontier model at a higher cost because the task demands it and the value compensates for it. Most often, when well designed, the answer is coexistence, i.e. an open, efficient model close to the data for the bulk of the volume, and frontier capability held in reserve for the moments when it makes a real difference.
The underlying point is that this choice is also an AI design and a variable in the cost equation. A routine, low-impact query needs neither a frontier model nor to leave the on premise perimeter. A critical decision with high exposure and a closing window of opportunity may justify both. Treating the deployment domain, the model and the location of compute as variables governed by the value at stake, rather than as a provisioning decision locked into a contract, is what distinguishes a well-considered architecture from a mere collection of integrations.
Simply put, the agent should not confine itself to choosing how to solve a task; it should also decide whether solving it that way is worth it.
Third level: Decide which plans to execute
The first two levels prepare the ground; the third is where the system acts on its own. On every query, a well-designed agentic system should evaluate several possible execution plans and decide which one deserves to run before committing to any of them.
It is worth placing this idea in context. Cost-aware routing is not something new: serious proposals already exist, both academic and commercial (model cascades, routers that select the cheapest model capable of answering), and the major providers are beginning to ship them as standard. But almost all of them operate at the level of the individual call and optimize a single dimension: the price of inference.
Three principles to guide you before implementation
The decision I am arguing here is of a different scope: it operates on the plan as a whole, incorporates business impact, and lives inside the agent’s own reasoning. The full architecture is a matter for another conversation, and part of it is patent-pending, but I can set out three principles I regard as non-negotiable for solving it rigorously.
1. The value decision must live inside the execution graph, not outside it.
A dashboard that raises alerts does not change the system’s behavior. The value assessment has to be a first-class decision node within the orchestrator itself, with the effective power to redirect or simplify a plan. Governance that merely observes from the outside does not govern.
2. The upfront estimate must be cheap. Otherwise, the exercise defeats itself.
There is a common trap, which I like to call the meta-cost paradox: using a generative model to judge whether using a generative model is worthwhile. The advance estimation of cost, latency and reliability must rest on deterministic and historical means, not on yet another generative invocation. Done well, deciding costs lesser than executing; done badly, the cure outweighs the disease.
3. Cost is not the only variable, nor the most important one.
Optimizing for price alone leads to poor decisions. The pertinent question is not which plan is cheapest, but whether the spend is worth it, given what is at stake. A critical incident with a closing time window justifies an outlay that a routine query does not. Operational impact, especially on severity, business value and latency, must be a critical deciding factor in the decision. The system has to reason about value, not merely about price.
Three levels, one question
Invariably, the three levels answer the same question: which processes deserve an agent, which substrate should they run on, and which specific plan is worth launching at any given moment. If you have not addressed these questions already, the result is an architecture that spends without governing itself.
Major players are beginning to move in the direction of FinOps for AI, of agent governance, of developer-oriented cost control. That is the usual sign that a problem has matured enough for the market to recognize it. But recognizing it is not the same as solving it. Most of what exists today acts during or after execution, and at the level of infrastructure or of the individual call. Before execution, a conscious value decision of the entire plan and inside the agent’s reasoning remains ground still to be won.
Reframing the objective
Returning to that initial conversation, the conclusion I would put to that executive today has nothing to do with the cloud bill and everything to do with the criterion by which the system is designed. The cost of AI is frequently treated as an efficiency problem. Its nature is more strategic: it is about deciding what to do, where to do it and how much to invest to maximize results.
Organizations that embed this value logic in their agents’ reasoning will not only obtain more efficient systems; they will also achieve platforms that are more auditable, more explainable and better aligned with the objectives of the business.
The technological capability already exists. Competitive advantage depends on a business’ capacity to govern its economics. Designing those economics by value at every level, and not only at the most visible one, is, in my view, the conversation we ought to be having right now.
>> At Atos Amplify we approach this dilemma from the design of the solution, not from the observation of the symptom. If your organization is grappling with costs, reliability or governance of agentic systems, connect with me and I would be delighted to exchange views.
Dive Deeper
