When you budget an AI agent, the conversation is about two things: the licence and the tokens. Those are the two lines on the proposal and the two any vendor can price. Then the agent starts working and the bill that climbs is a different one: the cost of everything the agent moves around it.
The thesis in one line: an agent's cost doesn't scale with the number of users, it scales with the number of agents and with what each one touches. One more employee clicks at their own pace. One more agent opens connections to every system it can reach, retries whatever fails and leaves a trail of everything it does. None of that shows up on a model price list.
The infrastructure cost of an AI agent: the line the proposal leaves out
Search for what an AI agent costs in Spain and you'll find everything from €10-40 a month to €500-37,000 a month, depending on the blog. We don't cite them, because none shows how it got to its number. A spread of three orders of magnitude isn't a price range, it's a sign that method is missing. Most add up licence and model usage, which is what's visible, and leave out what no pricing page shows.
What's left out? The infrastructure the agent activates when it works: traffic between your systems, calls to every connected tool, data leaving one cloud for another, storage for the trace of every action, and the observability to know when something breaks. That's the part that grows by itself: nobody bought it, nobody approved it, and it tends to land on another department's invoice.
How much more network traffic does an agent generate?
According to Cisco's own testing, tasks performed by agents can generate up to 450% more total network traffic once agentic AI traffic is included. And according to a Cisco analysis of aggregated direct-to-AI network telemetry, that traffic is on a trajectory to double every six months. Both figures appear in the press release Cisco AI Research: AgenticOps Scaling Quickly in the Enterprise, dated 23 September 2026.
In the same release, the Omdia study says the average organisation generates about 4,100 monitoring alerts and events a day, more than half of them network-related (same scope: large organisations in those three regions). Every agent you switch on is one more source of events that somebody has to watch, filter or pay to store.
Why cost scales with agents, not users
Because an agent doesn't behave like a user. A user makes a query when they need one. An agent works on a cadence and on assignment: it queries the ERP, the bank and the mailbox for every case, rereads context on every run, retries when something errors and logs every step. Adding users to an agent barely changes what it does. Adding agents multiplies the connections, and if they also talk to each other, calls grow with the mesh, not the sum, as happens in a multi-agent system.
| Line item | What triggers it | What it grows with |
|---|---|---|
| Model (tokens) | Each decision or read by the agent | Case volume |
| Traffic between systems | Each tool the agent reads or writes | Agents × connected systems |
| Data egress | Data crossing from one cloud or region to another | The architecture, not usage |
| Trace storage | Each step saved, with input and output | How long you keep it |
| Observability and alerts | Metrics and events from each agent | The number of agents |
An example without invented numbers
Picture a collections agent that queries the ERP, the bank and the mailbox for every overdue invoice. Whether one more person uses it or ten, what it does doesn't change. Now put in five agents (collections, purchasing, support, sales, admin), each with its own three or four systems. You don't have five times the activity: you have five query cadences, their retries, five sets of traces and five sources of alerts, hitting systems that now take everyone's traffic.
Which line items grow on their own?
- Retries and loops. An agent that fails tries again, and one stuck in a loop can burn in an afternoon what you budgeted for the month. With no cap per agent, the invoice sets the limit.
- Redundant reads. If the agent rereads the same context on every run, you pay traffic and tokens for something that hasn't changed. How you give an AI agent memory decides how much gets repeated.
- Data leaving where it lives. When the agent runs in one cloud and the system it queries is in another, every read is a data transfer somebody bills for.
- Traces. Keeping every step with its input and output is what makes auditing possible, and retention sets the size. How much to keep is a cost decision and an obligation at once: how long to keep an AI agent's logs.
- Alerts. Every agent adds metrics, and an operation already getting thousands of events a day doesn't need one more ownerless source of noise.
How to budget an agent: separate what depends on the model from what grows alone
- The variable part: the model. Measure it per resolved case, not per token. It's the line that moves with volume and with the model you pick, as the guide on which model to use in an agent explains.
- The part that grows alone: traffic, egress, traces and observability. Budget it per agent and per connected system, never per user. It's the one the sales proposal forgets.
- A cap on each. A spending limit per agent, an alert when consumption leaves its pattern, and a written trace retention with an expiry date.
- One owner for the bill. These lines land in three or four different cost centres. If nobody adds them up, nobody controls them.
- A monthly review. What grows alone shows up by watching the trend, and it's part of maintaining your AI automations.
That exercise of measuring, attributing, budgeting and capping is a function, not a one-off project, and it's the one we set up when we run cost control for your AI in production: the bill stops being a monthly surprise and becomes a line you can break down.
When is it safe to go from one agent to five?
When you know, for the first one, how much traffic, how many calls, how much trace and how many alerts each case generates, and you've multiplied those numbers by the systems the other agents will share. If you don't have those four measures from the first agent, the second isn't an expansion: it's a bet.
During the first thirty days of the first agent, measure this:
- The traffic it generates per run in each system it touches, compared with before you connected it.
- Calls per resolved case and the retry rate.
- Gigabytes of trace per week and the retention you've set.
- The events and alerts it produces, and how many need a person.
- Cost per case with both lines together: the variable one and the one that grows alone.
Continuous measurement is exactly what monitoring AI in production covers. And with those numbers in hand, calculating the ROI of an AI automation stops being a slide exercise: the denominator is the real one.
When this doesn't apply to you
If you have a single agent inside a closed SaaS that bills everything in the subscription and doesn't connect to your own systems, the infrastructure is already in its price and the classic licence-plus-usage model works. That changes when the agent connects to your systems, runs in your cloud or joins others. Even then it's worth reading what the rate includes, as in paying by outcome or by licence: what the vendor doesn't charge explicitly, you pay implicitly somewhere else.
The line to take away: budgeting an agent by licence and tokens is budgeting the part you could already see. The part that decides your bill is what the agent moves, and you measure that before you scale, not after.