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.
Update — September 10, 2026: a running cost that changes without anyone touching the code
The section above argues that the number which grows is the running cost, not the build. Here is that argument arriving as a dated event, from DeepSeek’s own API changelog as we read it on September 10:
“extensive testing shows that V4.1 Flash now outperforms DeepSeek V4 Pro across performance, cost, speed, and total time, so we plan to retire V4 Pro in an orderly manner. After 12:00 Beijing Time on September 14, 2026, and until the future release of V4.1 Pro, all requests to
deepseek-v4-prowill be routed to V4.1 Flash and billed at the V4.1 Flash price.”
Read what that would have done to a running system. The model name would have stayed valid.
The requests would have kept succeeding. Nothing would have errored, nothing would have returned a
404, and no deprecation warning would have fired in your logs. The model behind the name
would have changed, and the line on your invoice with it. Anyone calling
deepseek-v4-pro after September 14 would have been calling something else and paying a
different rate for it — and the only way to find out was to read a changelog you have no
particular reason to be watching. (DeepSeek has since withdrawn this plan; see the
September 12 update below.)
DeepSeek had already done this once, and that one did go ahead: the changelog notes that V4 Flash and V4 Flash Vision Exp “have been retired”, and that for compatibility their model names are “temporarily routed to V4.1 Flash.” So this is a pattern at this vendor, not a one-off.
Note that the reroute is more disruptive than a shutdown would be, not less. A retired endpoint returns an error, someone gets paged, and you fix it that afternoon. A silent reroute produces no signal at all — and anyone benchmarking “Pro” quality against “Pro” invoices would, after the switch, have been measuring Flash against both without knowing their comparison had stopped meaning anything.
Two things this should change in how you run an agent. First, pin model versions explicitly wherever the provider lets you, and treat a bare family name as a variable rather than a constant. Second, put the provider’s changelog on the same review cadence as your own dependencies — because for a system whose behaviour and cost both live at the other end of an API call, that changelog is a dependency, and it is the only place this particular change was announced.
Update — September 12, 2026: two days later, DeepSeek withdrew the plan
When we read DeepSeek’s changelog again on September 12, the retirement paragraph quoted above was gone. The changelog’s September 10 entry, and a footnote on its pricing page, now say:
“In response to user demand, we have decided to continue providing API services for DeepSeek V4 Pro after September 14, 2026, with the billing method remaining unchanged. We will provide further notice should there be any changes.”
So requests to deepseek-v4-pro are not being rerouted to V4.1 Flash on September 14:
DeepSeek says it will keep serving V4 Pro, with the billing method unchanged. The V4 Flash change
described above is unaffected — those models are retired, and their old names still route to
V4.1 Flash.
This does not weaken the argument. It adds a second example. Within two days the same model name had two different futures, and both were announced in DeepSeek’s changelog. A team that moved off V4 Pro to get ahead of the reroute has migrated ahead of a change that has been withdrawn. A team that never saw the first notice lost nothing, but only by luck. Neither outcome was decided by anything inside the team’s own system.
One more habit follows from it: treat a vendor’s announced future change as provisional until its date passes. Plan for it, but read the notice again before you act on it, and once more on the day. The notice you planned around is not always the one in force when the date arrives.
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.