Ask what an AI agent costs to build and you will find published ranges. They are wide enough to be useless, and the reason is not evasiveness — it is that “an AI agent” describes both a script that reads a mailbox and drafts replies, and a system that spans six platforms, writes to your ledger, and has to be right every time. Those are not the same purchase and no single range covers both honestly.
So the useful question is not what it costs. It is what determines which end of the range you are at, because once you can answer that about your own case, a quote stops being a number you either accept or don't and becomes something you can interrogate.
Scope: one job, or a system?
The largest single factor, and the easiest to test. Can you name the trigger and the finish line in one sentence each? “When an email arrives from a customer, draft a reply and put it in drafts” is one job. It has a clear start, a clear end, and a human between it and any consequence.
“Handle customer enquiries” is not one job. It is a category, and quoting it requires guessing which jobs are in it. A quote against a category is a quote against an assumption, and the difference between your assumption and the builder's is the change order.
The practical move is to cut the first agent down until it passes the one-sentence test, even when the ambition is larger. The second one is dramatically cheaper than the first, because by then the plumbing exists and both sides know what the real requirements were.
Integrations: count the pairs, not the systems
Every system the agent touches brings three things with it: an authentication model, rate limits, and its own way of failing. None of those are shared between vendors, so each connection is largely its own piece of work.
But the count that actually drives effort is not the number of systems — it is the number of places where two systems have to agree about something. Two systems that both hold a customer record must agree on which one is authoritative and what happens when they diverge. That agreement is a decision someone has to make, encode, and handle the failure of, and it exists once per pair, not once per system. This is why adding the fourth integration to a project rarely costs what the first one did.
Read or write? The multiplier nobody puts in the quote
An agent that only reads — summarizes, drafts, retrieves, flags — is a fundamentally cheaper thing to build than one that acts, and the gap is much larger than the code difference suggests.
The moment an agent writes to a system of record, sends something to a customer, moves money, or changes an entitlement, an entire category of work becomes mandatory rather than optional: what it is allowed to do unsupervised, what needs approval, how an action is reversed, and what the audit trail looks like afterwards. That work is not glamorous and it is not skippable, and its absence is the single most common reason a demo that worked never reaches production.
Between the two there is a middle position worth knowing about, because it is often the right first build: the agent does the whole job and stops one step short, leaving a human to press send. It captures most of the time saving at a fraction of the cost and risk, and it produces the thing you need before you automate the last step anyway — a record of how often the agent was right.
The condition of your data
This is where the surprises live, and they are surprises specifically because nobody looks before quoting. The agent has to reach the data, understand its shape, and be given the same data twice without producing two different answers. When records are duplicated or a field means different things in two systems, that work lands inside the agent project regardless of who was supposed to own it.
It is worth scoping the data question separately and first. Not because it is somebody else's problem, but because it is the one item most likely to be misjudged by both sides, and it prices very differently once someone has actually looked.
The line item that is almost never quoted: knowing whether it works
A demo is judged by watching it succeed. Production is judged by whether you would notice it failing.
Those need different things. Noticing failure means a set of cases with known-correct answers, run repeatedly, with a threshold that is agreed rather than felt — and someone looking at the result. Building that is real work, it is usually the difference between a build that survives contact with reality and one that quietly degrades, and it appears in remarkably few quotes.
The question to put to any quote: how will we know, in month four, whether this is still working as well as it did in week one? If the answer is that someone would probably notice, the quote is for a demo. If the answer names a set of test cases and who reviews them, the quote is for a system, and it should cost more.
Running it is a separate number, and it is the only one that grows
Build cost is one-time. Run cost is per use, and it scales with exactly the thing you are hoping for — adoption. An agent whose per-task cost is negligible in testing is a line item at real volume, and the arithmetic is worth doing before rather than after.
That arithmetic is published and it is not difficult: the model vendors list their rates, and the calculation is unit cost times tasks per month. We have worked through it against current published rates, including how much the answer moves depending on which model does which part of the job. The short version: model choice is a bigger lever on run cost than on quality for most business tasks, and the two decisions are worth making separately.
“Is it free to build an AI agent?”
Genuinely yes, for a version of it. The tooling is largely free or nearly so, the tutorials work, and somebody technical in your organization can have something demonstrable running in an afternoon. That is a real fact and it is worth using — an afternoon prototype answers the “is this even plausible” question for almost nothing.
What is not free is the distance between that and something the business can rely on: the failure paths, the permissions, the evaluation, the handling of the case nobody anticipated, and somebody accountable when it breaks. That distance is the entire cost, and it is invisible from inside the afternoon.
How to compare two quotes that differ by a factor of five
They usually differ because they are quoting different things. Six questions will show you which:
- Which systems does this touch, and does it write to any of them?
- What is it allowed to do without a human, and who decided that?
- What happens when a system it depends on is down or slow?
- How is a wrong action undone?
- What is the evaluation set, and who reviews it after launch?
- Who owns the code and the accounts at the end?
The cheaper quote is not necessarily wrong. It may be quoting the read-only version, or the one-job version, and that may be exactly what you should buy first. But you should know that is what you are comparing.
Where we sit on this
We do not publish a rate card, and that is a deliberate position rather than a coyness — the number moves with all of the above, and with which engineers the work actually needs. A published band would be either wrong or so wide it told you nothing, which is the problem this whole post is about.
What we can say plainly is what is not in it: no per-seat license, no resale margin, no software sold through us. The model and platform accounts stay in your name and you pay those vendors directly, so the run cost above never routes through us and you can change your mind about any of it without asking. That is the same footing as the rest of the AI integration work, and the AI agent development page sets out how the scoping and quoting actually run.
Related reading: Custom AI or off the shelf? — the decision that comes before this one, and often removes it. And what API integration costs you after it ships, on the half of the bill that arrives after the build is signed off.