There is no honest single-number answer to "What does an AI agent cost?" — but there is an honest structure. An agent costs in three blocks: once for the build, continuously for consumption, continuously for operations. Anyone who is only quoted the first block has not received an offer, but a third of one.
This article is an in-depth expert contribution from our content cluster. Discover the complete overview on our main page:AI Automation & Intelligent Agents →
- Three cost blocks, not one number: build (one-off), consumption (per token) and operations (monthly). Only all three together give you the twelve-month total.
- The build is the smallest block: a well-scoped agent is built at Pragma-Code in an AI sprint for a fixed €2,900 in 14 days. The price does not rise with intelligence, it rises with the number of integrations.
- Operations is the forgotten block: a workflow stops when something breaks. An agent keeps answering — including incorrectly. Without a regular quality sample, nobody notices.
1. Why "one price" is the wrong answer
The question comes up in almost every first conversation, usually within five minutes: "Roughly what would an agent like that cost us?" The honest answer is not "between X and Y" but a counter-question: for which of the three cost blocks?
An AI agent is not an object you buy and then own. It is closer to an employee than to a machine: there is a one-off investment to make it capable of working, there are ongoing costs for it doing the work, and there are ongoing costs for someone checking that it still does the work correctly. Budgeting only the first item means planning around two thirds of the truth.
This split is not pricing rhetoric — it follows the technology. The build is project work with a defined end. Consumption is a usage-based invoice from a model provider that is not yours and that you can cap but not abolish. And operations exists because an agentic workflow, unlike conventional software, does not stop with an error message when it breaks.
What "an agent" means in this article
The term has become blurry, and the blurriness costs money — because two parties discuss different things while comparing the same price. For the calculations here a narrow definition applies: an agent is one language-model-backed use case on one channel.
An agent answering customer enquiries on WhatsApp is one agent. The same use case additionally over email is a second. An agent that answers enquiries and drafts quotes is two use cases. This way of counting sounds pedantic, but it is the only reason fixed prices are possible in this field at all: it makes the scope verifiable before anyone signs.
2. Block 1: The build — and what actually makes it expensive
The most common error in cost estimation is believing the price depends on how "clever" the agent needs to be. It does not. You buy the model intelligence off the shelf anyway — it is equally available to everyone from OpenAI, Anthropic or Google. What makes the build expensive is the environment the agent has to work in.
1. The number of integrations
Every system the agent reads from or writes to is separate work: authentication, data model, error cases, permission checks. An agent that only queries a knowledge base is a fraction of the effort of one that writes into an ERP. The integration is almost always more expensive than the agent itself.
2. The state of your data
The biggest single item nobody sees in a quote. If the information is structured and current, the knowledge base is built in days. If it lives in 400 PDFs across three revisions with contradictory price lists, data preparation becomes the actual project — and the agent the small remainder of it.
3. Decision depth
An agent that hands out information is harmless. An agent that triggers something — an order, a credit note, a confirmed appointment — needs guardrails, escalation rules, an audit trail and a defined abort path. That is the jump at which projects typically move up a price tier.
4. The number of decision-makers on your side
Not a technical factor, but the most reliable time sink. If nobody can state bindingly what a correct answer is, no test case exists — and without test cases every acceptance review becomes a matter of taste. Projects rarely fail on the model and often fail here.
The price tiers at Pragma-Code
So the order of magnitude does not stay abstract, here are the actual fixed prices I build for. All three are fixed prices with scope defined in writing beforehand — listed on the pricing page, not day rates.
Process check
Analysis before anything is built: which process is worth it at all, where the data quality is sufficient and where it is not.
€690About one week. The result is a basis for a decision — including the decision not to proceed.
AI sprint
One scoped use case is built and put into production. The normal case for a first agent.
€2,90014 days, fixed price. Scope and assumptions are agreed in writing up front.
Automation Scale
Several connected processes, deeper system integration, multiple channels.
from €5,9006–8 weeks. Priced by number of integrations, not by hours of effort.
Expert tip: do not skip the process check
€690 sounds like an item you can save if the direction is clear anyway. In practice it is the cheapest place in the entire project to say no. An agent that is never built because the process is too rare or the data does not hold up has cost €690 instead of €2,900 plus twelve months of operations.
3. Block 2: Consumption — the invoice that is not yours
Every answer from an LLM is billed per token: by the amount of text going in and the amount coming out. This is the item that typically does not appear in a provider's quote at all, because the provider does not control it — it arises directly between you and the model vendor.
Three properties make this block hard to plan, and you should know them before committing to a budget:
The context grows with it
It is not only the question that costs, but everything the agent reads to answer it — conversation history, documents, system instructions. An agent with a long memory can cost a multiple per request of what the question itself suggests.
Agents work in loops
An agent that calls tools often performs several model calls for one user question: reason, look up, reason again, answer. The bill scales with intermediate steps, not with questions.
Prices move — in both directions
Model prices have historically fallen, but new model generations launch more expensively, and switching to a stronger model can multiply the bill overnight. A calculation resting on today's price sheet from one vendor has a limited shelf life.
That is why one simple rule applies to this block with me: token and API costs are passed through at cost, with a cap agreed in advance. No markup, no margin on someone else's consumption — in exchange, a limit I monitor and flag before it is breached. Anyone selling you consumption as a flat fee is either pricing in a thick risk premium or will want to renegotiate the flat fee after six months.
4. Block 3: Operations — the item almost every quote leaves out
This is where an automation project and an AI project genuinely differ, and it is almost systematically omitted from quotes.
A workflow stops when something goes wrong. An AI agent simply keeps answering — even after a fallback kicked in, a model changed or a prompt quietly lost its effect.
A conventional n8n workflow that loses an interface throws an error. You see it in monitoring, someone fixes it, done. An agent in the same situation does something else: it composes a plausible answer from whatever is still available to it. From the outside this looks like normal operation. The metrics are green, response times are fine, the error rate is zero — and the content is nevertheless wrong.
I know this not from a customer incident but from my own system: in Pragma-Code's AI visibility monitor an automatic fallback silently removed Google Search grounding after a rate limit. The system kept running, reported no error and kept delivering answers — just without the source binding that was the entire point. It surfaced during a content spot check, not in monitoring.
What operations concretely means
-
Monitor availability and errors
The base layer: is the agent running, is the interface responding, are the limits holding. Necessary, but as described not sufficient.
-
A monthly quality sample against fixed test cases
The actual core. At handover we write down together what a correct answer is — with an expected result per case. From then on that set is the yardstick measured against every month. It is the only way drift becomes visible at all.
-
Track model changes and deprecations
Models get deprecated and successors behave differently. Noticing only when the vendor switches something off means an outage instead of a planned migration.
-
Cost watch
Check consumption against the agreed cap and raise it before the cap is breached, not afterwards.
I offer this as a separate, monthly cancellable product line in three tiers: Agent Operations from €390 ("Watch"), €690 ("Operations", including the quality sample) and €1,190 per month ("Operations & Evidence", additionally with a documented model and version state for AI Act evidence). Explicitly without an SLA, without an uptime guarantee and without 24/7 on-call — response times are working-day based, and I would rather say so up front than in an incident.
5. The three most expensive assumptions
Comparison: expectation vs. actual cost structure
- A single payment: the agent is bought and then it is there, like a website.
- Priced by intelligence: a "smarter" agent costs more to develop.
- Maintenance optional: as long as it runs, nobody needs to look.
- Pilots scale linearly: what worked for ten requests works the same for a thousand.
- Three blocks: build once, consumption and operations continuously across the whole lifetime.
- Priced by integrations: the intelligence is bought in, the integration is the work.
- Maintenance is quality assurance: without a sample nobody notices content drifting.
- Consumption scales more than linearly: more requests mean more intermediate steps and more context.
6. Worked example: twelve months, openly calculated
What follows is a worked example with disclosed assumptions, not a customer evaluation. I currently have no customer agent in live operation and therefore claim no empirical figures. What is shown here are my fixed prices plus a clearly labelled assumption for consumption.
Assumed case: one agent, one channel — customer enquiries on WhatsApp are answered and handed to a human where needed. One knowledge base, no write access to systems.
Checking up front whether the process occurs often enough and the information holds up.
Building and productionising the use case. Fixed price, 14 days.
Monitoring plus the monthly quality sample against the agreed test cases. Cancellable monthly.
The one item I cannot quote as a fixed price. It depends on request volume, context length and model choice, and is therefore capped in advance rather than estimated.
What follows from this: in this example the build accounts for €3,590, operations over twelve months for €8,280. The item usually missing from quotes is therefore the larger of the two — and consumption comes on top. This is precisely why "what does the agent cost?" cannot be answered without a time frame.
7. When an agent is not worth it
Naming the cases where the answer is "do not build it" is part of the cost question. In my experience there are four of them:
Too rare
A process occurring ten times a month does not justify ongoing operations. A checklist is cheaper here than an agent.
No reliable source
If nobody can say which of the three price lists applies, the agent will not resolve that uncertainty — it will distribute it.
Solvable deterministically
Where fixed rules exist, no language model is needed. A rule-based solution is cheaper, faster and auditable — which is why I offer it as its own service.
Errors are expensive
Where a wrong answer immediately costs money or liability, a human must stay in the loop — which often reduces the saving so far that the effort no longer carries itself.
Quick check: is your budget complete?
Conclusion
"What does an AI agent cost?" is a question to which a single number is almost always a dishonest answer. It becomes reliable only once split into three blocks: the build is plannable and, for a scoped use case at a fixed €2,900, the smallest item. Consumption is usage-based, belongs to the model vendor and can only be capped, not negotiated away. And operations is the block missing from quotes that nevertheless exceeds the build over twelve months.
Anyone who lays those three figures side by side can compare quotes properly for the first time — and, in case of doubt, makes the cheapest decision of all: not building an agent that does not carry itself.
Have a vision?
Let's check together how we can make your idea take flight.
Book your free strategy call nowExtended Specialized Glossary
AI Automation
The use of AI models inside business processes to take over tasks that were previously done manually.
Agentic Workflow
A process in which an AI agent does not merely answer but calls tools and decides intermediate steps on its own.
Agentic ROI
Assessing the economics of an AI agent across build, consumption and operations rather than by project price alone.
LLM
Large Language Model — the model that produces an agent's answers and whose use is billed per token.
