Almost nobody publishes pricing for an AI agent platform, and there is a legitimate reason behind that: the cost depends on variables that only appear once somebody looks at the real process. The side effect, though, is that the buyer arrives at the first meeting with no reference at all, and leaves it not knowing whether the proposal is expensive.
This text quotes no figures, for the same reason we distrust those who do: the price of a model, a license and an engineering hour changes in weeks, and a loose number becomes the wrong argument for a long time. What it does deliver is the structure of the calculation. With it you can evaluate any proposal, including ours.
The seven components of the bill
The cost of an agent in production is not one line, it is seven. Proposals that present fewer than that are not cheaper: they are pushing the rest past the signature.
1. Model consumption
The only item that scales with usage, and the only one most people estimate. It is billed per token, at a different price for what goes in and what comes out, and what goes in usually dominates the bill in an enterprise agent: every call carries instructions, history and the context retrieved from the knowledge base. Three decisions actually move that number: picking a model per task instead of using the most expensive one for everything, taking advantage of caching for what repeats, and cutting context that does not change the answer.
2. Platform and runtime
Where the agent runs, who holds the memory, who executes the scheduling, who sustains the vector database. It can be a platform license or your own infrastructure plus the team that maintains it. Both options cost money, and the second tends to cost more than the first month's spreadsheet shows, because its cost is people.
3. Deployment
The engineering work between the decision and the first agent running with a real user. Mapping the process, designing it, building it, testing with real data and tuning until the accuracy rate is acceptable. It is the largest line of the first year in most cases, and the one that varies most depending on whether the process is documented or not.
4. Integration with what already exists
The ERP, the CRM, the undocumented legacy system, the official messaging channel. A ready connector reduces this to configuration. A legacy system with no API becomes a project of its own, and this is where schedules blow up: not because of the agent, but because of access to the data it needs.
5. Operating it after go-live
The forgotten line. An agent in production is not software that gets finished: the process changes, the catalog changes, the commercial policy changes, and the quality of the answer falls with them if nobody follows along. Somebody has to watch the metrics, review the cases that came out wrong and tune. Without that line in the budget, the project degrades quietly until somebody says AI did not work.
6. Governance and compliance
An audit trail, access control, handling of personal data, human approval where the risk demands it. In a regulated sector this is not optional and it is not cheap to improvise later. Building it alongside costs a fraction of building it under audit.
7. The cost of carrying on as you are
The item that almost never makes it onto the spreadsheet and the only one that is already being paid today. Hours spent on repetitive work, a contact that goes cold because the answer was slow, rework, overtime. Without that line, any proposal looks expensive, because it is being compared to zero instead of being compared to what you spend now.
The calculation almost everyone gets wrong
The most expensive trap is in none of those seven items. It is in estimating production using the pilot's numbers.
A pilot runs at low volume, down the happy path, with the team paying attention and whoever built it close by. Production runs on the odd case, the customer who writes everything in capitals, the system that went down, the end-of-month peak. The difference between the two is not one of scale, it is one of nature, and it shows up in four places:
- The volume of context per call grows once the agent starts dealing with real history instead of a test conversation.
- Exception cases consume more steps, more calls and more tokens than the main path, and they are the bulk of what is left for the agent to resolve.
- Reprocessing appears: the attempt that failed, the repeated call, the fallback to another model.
- Human supervision becomes a fixed line, because in production somebody has to look at what the agent decided.
A practical rule when reading a proposal: ask for the cost of reaching the first agent in production to be separated from the cost of sustaining the next twelve months. A proposal that presents both together as a single number is hiding which of the two is the problem.
Is building it with the in-house team cheaper?
Sometimes it is, and it is worth saying when. If your team already has a senior engineer available, the case is one of a kind, the process is documented and nobody is waiting on a deadline, building directly on the framework is a defensible and cheaper decision.
The comparison becomes dishonest when the calculation puts a platform license against two salaries and stops there. What usually goes missing from the "build" column:
- The time until the first agent is in production, and what the operation keeps spending during that period.
- The operations layer (observability, audit trail, access control, cost control) that the platform brings ready and that the team would have to write before any audit.
- The dependency on whoever built it. A framework chosen by one person becomes a risk when that person leaves.
- The second agent. The first one justifies the effort of building everything from scratch; the fifth is what reveals whether you accidentally built a platform.
How to build the business case before asking for a proposal
Arriving at the first meeting with these four numbers changes the conversation, because they are the baseline any proposal is measured against.
- Volume. How many times a month the process happens. Not the estimate, the number from the system.
- Time per occurrence. How much person-time each one consumes today, start to finish, including waiting and rework.
- The current success rate. How much of what comes in reaches the intended outcome. It is the denominator that turns an improvement into money.
- What the delay costs. The contact that goes cold, the missed deadline, the penalty, the overtime. It is the line that separates savings from revenue, and revenue is what gets projects approved.
With those four, calculating the return stops depending on the vendor's promise. You start asking how much of line 2 the agent removes and how much of line 3 it improves, and the proposal becomes a verifiable calculation instead of an expectation.
What happened in real operations
Three of our cases, with the numbers the clients themselves measured. They are here because they illustrate the three shapes a return usually takes: conversion, recovered revenue and avoided cost.
- Osten Group: a 30% rise in contact-to-visit conversion, with pre-sales going from 7 people to 2.
- PX Ativos Judiciais: first-contact conversion from 4% to 10%, roughly R$ 1.5 million converted over the year without growing the team.
- Vero: R$ 2 million saved on overtime.
None of those numbers was a projection in a proposal. All of them appeared afterwards, measured in the operation, which is the only way the calculation is worth anything.
The shortest path to a number of your own
No price list answers what your case costs, because the variation between a documented process and a process that only exists in three people's heads is larger than the variation between vendors. In the free assessment we look at the process you have today, measure the four lines above with your data, and tell you plainly whether the case calls for an agent or whether the tool you already use solves it.
