3 min read
Why nobody quotes this from a one-liner
"We want an AI agent that answers customer questions" describes anything from a week of work to most of a year. The words are identical; the systems are not. What separates them is rarely the model — it is everything around the model.
A useful quote comes from pinning down five variables. If a supplier gives you a price before asking about these, they are either guessing or quoting for something simpler than what you asked for.
1. How many systems it has to touch
An agent that only reads is cheap. An agent that acts — books, refunds, updates a record, sends a message — costs more per integration, and the cost is dominated by the worst-documented system in the list, not the average one.
The question to answer up front: what is the complete list of systems this thing reads from and writes to, and does each one have an API you can actually get credentials for? A single legacy system with no API can cost more than the rest of the build combined, because the work becomes scraping, scheduled exports or file parsing with all the retry and reconciliation logic that implies.
2. Whether answers have to be grounded
There is a large gap between an agent that answers from a model's general knowledge and one that answers from your documents and can show where each answer came from. The second needs a retrieval layer: ingestion, chunking, an index that stays current as documents change, and citations that survive a sceptical reader.
That layer is usually the single biggest line item on a knowledge-facing agent, and it is also the one clients most often assume is free because the demo looked convincing.
3. What happens when it is wrong
Every agent is sometimes wrong. The cost question is what the system does about it.
The cheapest answer is nothing — the model responds and the user judges. The expensive answer is a graded one: confidence scoring on each output, a threshold below which a human reviews before anything is committed, and a fallback that degrades usefully rather than silently.
On the document-extraction work we do, per-field confidence scoring with a review dashboard is the difference between a tool people trust and a tool people quietly stop using. It is also a meaningful share of the build.
4. Whether decisions can be left to the model
Some decisions must not be probabilistic. Pricing, eligibility, scheduling against real availability, anything with a policy or a legal consequence — these belong in deterministic rules the model calls, not in the model itself.
When we built an inbound voice agent for appointment booking, the booking decisions ran through a rules engine covering business hours, staff schedules and buffers, precisely so the agent could not double-book or break policy however it phrased things. That rules engine is real engineering work and it is not optional; it is what makes the system safe to put in front of customers.
5. Who operates it after handover
A prototype ends when the demo works. A production system ends when someone else can run it: deployment that is reproducible, logging that shows what the agent did and why, monitoring that alerts before a user complains, and documentation written for whoever inherits it.
If a quote does not include this, it is a quote for a prototype. That may be exactly what you want for a first test — but the two should not be compared on price as though they were the same thing.
What to ask before accepting any number
Bring these to any supplier, including us. The answers will tell you more than the quote will.
- What is the full list of systems this reads from and writes to, and which have usable APIs?
- Are answers grounded in our own content, and can the system cite its source?
- What happens when the model is unsure — does anything stop a wrong answer reaching a customer?
- Which decisions are handled by deterministic rules rather than the model?
- What is measured, against whose test cases, and what accuracy is considered acceptable?
- At handover, what exactly do we own, and can our team deploy a change without you?