What an AI agent costs in production: the line items
By AlexandreCTPO and co-founder, AI, Product and Tech
A production AI agent has a real cost, but that cost breaks down into several identifiable line items. Before any diagnostic, a quoted price range means nothing: here is what actually makes up the bill.
Why a price range before a diagnostic means nothing
Business owners often ask, first thing, what an AI agent will cost once it is running. The question is fair, but the honest answer before a diagnostic is that nobody knows yet. The cost depends on the model chosen, the volume of requests, the complexity of the tasks, and the tools the agent needs to connect to. Stating a figure before looking at these elements is just guessing. The diagnostic exists precisely to measure these variables before committing to anything.
What a price quoted too early actually hides
When a vendor names a price before looking at your case, they are doing one of two things: applying a standard rate that matches none of your real usage, or padding the range to cover themselves against the unknown. Either way, that figure tells you nothing useful about what your project will actually cost. An agent answering ten frequently asked questions a day and an agent handling complex bookings with access to a shared calendar have nothing in common cost wise, even if both get called an "AI agent" under the same generic label.
The most visible line item: tokens consumed
Every exchange with an agent consumes tokens, the unit used to measure text read and generated by the model. This line item depends on three things: the size of the model called, the length of the responses produced, and the amount of context sent with each request, such as conversation history, attached documents, or system instructions. A larger model costs more per token. Longer responses consume more of them. Context loaded with entire documents on every call, even when only one line is useful, drives up the bill without improving the quality of the answer.
How this line item scales with usage
Token cost is not a flat monthly amount, it is a bill that follows actual usage. A lightly used agent costs little, a heavily used one costs proportionally more, unless certain settings are put in place to curb that growth. This is why it helps to reason in cost per exchange rather than a flat monthly figure from the earliest scoping stage: it lets you anticipate what happens if the service turns out more popular than expected, instead of getting a surprise on next month's bill.
Hosting, a choice with real consequences
An agent has to run somewhere. Depending on how sensitive the data is, hosting can sit with a model provider, on cloud infrastructure in France or the European Union, or on a local setup running an open model installed at the client's premises. That last option keeps data from ever leaving the network, at the cost of investing in machines capable of running the model. The choice is made case by case, based on what the agent actually handles.
Business situations that shape this choice
A firm handling health records or confidential legal files does not face the same constraints as a shop answering general questions about opening hours and products. In the first case, local hosting or a tightly controlled European infrastructure is often close to a requirement, even though it means a heavier upfront investment. In the second case, hosting with a standard model provider may well be enough, at a much lower starting cost. This choice deserves to be made explicitly at the start of the project, rather than discovered once the agent is already in production.
Integration with existing data and tools
A useful agent needs to read, and sometimes write to, the systems already in place: an ERP, a tracking spreadsheet, an inbox, a ticketing system. This integration is often the most underestimated line item. Connecting an agent to a clean, documented API takes little time. Connecting the same agent to a monthly Excel export, a closed piece of software with no API, or data scattered across several tools, requires engineering work that has nothing to do with the model itself.
A concrete example of cost creep
Picture an agent meant to answer stock availability questions, except that stock lives across three different tools, updated on different schedules, with no shared identifier between product records. The agent's own job stays simple: read a number and report it back. But the groundwork needed to make that number reliably accessible, unifying the sources and handling cases where they disagree, can end up as the bulk of the project budget. This kind of situation, invisible before looking at the existing systems, is exactly what a serious diagnostic needs to catch before pricing anything.
Questions to ask before estimating an agent project
- Which systems does the agent need to query, and do they offer a documented API or only manual exports?
- Is the necessary data centralised, or scattered across several tools that do not talk to each other?
- Who updates that data today, and how often?
- What volume of exchanges is realistically expected, and how might that volume grow in the months after launch?
- Which data is sensitive enough to require particular hosting arrangements?
Human oversight and keeping the knowledge base current
An agent in production is never shipped and forgotten. Someone has to review a sample of its answers, spot drift, and sign off on sensitive cases before they go out. The business keeps changing too: a new price, a new procedure, a product dropped from the catalogue. The instructions given to the agent and the documents it consults have to follow these changes, or it will answer with outdated information. This review and update work is human, recurring, and rarely budgeted for from the start.
Organising this oversight without a full-time role
In a small company, this oversight does not require a dedicated position. It can take the shape of a short but regular recurring moment, where whoever knows the business best reviews a sample of exchanges and flags answers that no longer match reality. What matters is that this moment actually happens and keeps happening, rather than being postponed indefinitely until a customer complains about receiving wrong information. Documenting changes as they occur, rather than doing one big update once a year, keeps the agent's knowledge base closer to what is actually happening on the ground.
Common mistakes that drive up the bill
A handful of mistakes come up repeatedly in AI agent projects. Picking the most powerful model available on the market by default, without checking whether a smaller one would do the job just as well. Sending an entire document with every request when only one section is relevant. Planning no human review time at all, which ends up costing more in emergency fixes than if that time had been scheduled from the start. Underestimating the integration work because only the model gets looked at, never the systems it needs to query. Finally, never revisiting the settings once the agent is in production, which is exactly when the savings levers become visible.
Measuring it, and cutting the bill without cutting the service
For every agent we put into production, we measure tokens consumed, cost, response time, and an estimate of carbon impact, with the factor used and its date. A life cycle assessment published by Mistral AI with Carbone 4 and ADEME puts the impact of a 400-token response at 1.14 g of CO2e and 45 mL of water, excluding user devices. That figure gives an order of magnitude for one model and one response, not a universal rule: every agent has its own profile depending on the model and the length of the exchanges.
Several levers cut the bill without degrading the service delivered. Choosing the smallest model that does the job correctly, rather than the most powerful one available. Limiting the context sent to what actually serves the response. Instructing the agent to keep answers short when length adds nothing. Not calling a model for a task a script already solves, such as a calculation or an exact lookup. Caching answers to questions that come back unchanged. This is the principle behind our diagnostics: AI only where it is needed, a script everywhere else, and the smallest model that does the job correctly. To see this approach in context, see our page responsible AI.
What a diagnostic checks before any pricing
Before providing any estimate, a proper diagnostic reviews the same points covered in this article: the systems the agent will need to query, the expected volume of exchanges, the sensitivity of the data involved, and a realistic amount of human oversight once the agent is live. This step goes beyond picking a model, it sketches out the whole architecture of the project and identifies, before any development starts, which line items will weigh most heavily on the budget. Our AI agent method and automation pages explain how we tell, project by project, what calls for a conversational agent from what calls for simple automation, which is often far cheaper for the same business outcome.
Asking a vendor the right questions
Before committing, ask your vendor how they plan to measure and limit each of these cost items once the agent is in production. A vendor who cannot explain how they monitor tokens consumed, how they plan to host your data, or who will handle human review over time, is leaving those questions unanswered until they show up on an invoice. An initial diagnostic exists precisely to ask these questions before any commitment, and our engagement page details how this follow-up continues once the agent is in service.
Why the cheapest quote is not always the cheapest agent
A low upfront quote can hide costs that only appear once the agent is live: a model too small for the task that has to be swapped later, an integration left unfinished that someone has to patch by hand every week, or a complete absence of human review that quietly lets wrong answers reach customers until one of them complains. Comparing two proposals on price alone, without checking whether they cover the same scope of hosting, integration, and ongoing oversight, tends to compare very different things under the same label. The lowest number on a quote is only meaningful once you know exactly what it does and does not include over the life of the agent, not just at the moment it first goes live.
Sources
Frequently asked questions
How much does an AI agent cost?
It depends on the model chosen, the volume of use, the tools to connect, and the level of oversight needed. A diagnostic measures these elements before any estimate; stating a figure before that step would have no real basis.
Why does token cost vary so much from one agent to another?
It depends on the size of the model called, the length of the responses produced, and the amount of context sent with each request. Two agents delivering the same service can have very different costs depending on these settings.
What is the most commonly underestimated cost?
Integration with existing tools and data. Connecting an agent to a clean API is fast; connecting the same agent to manual exports or closed software takes much longer engineering work.
How can the cost of an agent be reduced without lowering service quality?
By choosing the smallest sufficient model, limiting the context sent to what is strictly necessary, avoiding model calls for what a script already solves, and caching answers that come back unchanged.