Why there is no fixed number for this
Search for custom AI agents and you will find agencies willing to quote a number in the first email. Treat that as a warning sign, not a shortcut. An AI agent that reads inbound leads and drafts a reply is a fundamentally different build from one that approves refunds inside a regulated finance workflow, even though both fit the same one-line description on a sales page. The price follows the shape and risk of the work, not the label attached to it.
That is not a dodge — it is the only way to land on an accurate figure. Two businesses can ask for what sounds like the identical agent and need completely different projects underneath. The rest of this guide breaks the cost into its component parts, in roughly the order they move the number, so you can reason about your own project before you pick up the phone.
How many systems it has to integrate with
Integration work is usually the single biggest driver of build cost. An agent that reads from one CRM and writes back into the same CRM is a contained project. An agent that has to reconcile a CRM, a billing platform, a scheduling tool, and an inbox — checking that all four agree before it acts — is a different order of complexity, because every additional system is another place the data can be inconsistent, another authentication method to manage, and another failure mode to handle gracefully.
Modern platforms with clean, documented APIs are the cheap case. Legacy systems without one are not automatically a blocker, but they usually mean building a bridge — a scheduled export, a database connection, a webhook someone has to maintain — and that bridge has its own cost. Before any call, make a short list of every system the workflow touches today. That list, more than anything else, is what an agency is actually pricing.
How much judgement the agent needs
A workflow that follows the same steps every time, with the same inputs producing the same outputs, is cheap to build and cheap to trust. A workflow that has to weigh context and make a genuine call — is this customer a good fit, does this document look right, should this case be escalated — costs more, and not mainly in the writing of the logic. It costs more in the testing.
The more a system decides rather than executes, the more historical cases it needs to be checked against before anyone is comfortable letting it run unattended. A narrow, rules-based task might need a handful of test scenarios. A judgement-heavy one needs a much wider set, covering the edge cases that only show up once you look at real data rather than a tidy example. That testing work rarely shows up in a rough estimate, which is one reason two quotes for what sounds like the same agent can land far apart.
How much volume it has to handle
A tool that processes a handful of cases a week can tolerate a simpler design. Mistakes are rare, and when one happens, a person can absorb it without much disruption. A tool processing hundreds of cases a day is a different engineering problem: edge cases that would show up once a year at low volume start showing up weekly, performance under load starts to matter, and the cost of a small error rate is multiplied by every case that passes through it.
Higher volume also changes what "done" looks like. A low-volume agent can ship with reasonable monitoring. A high-volume one needs monitoring built in from day one, because a silent failure at that scale compounds fast and nobody notices until the backlog is visible.
What happens when it gets something wrong
This is the driver buyers underweight the most. An agent drafting internal notes that a person reviews before anything happens is low stakes — a mistake gets caught before it matters. An agent that can issue a refund, change a patient record, or move money without a human in the loop is high stakes, and the engineering required to make that safe is substantial: stricter access controls, exhaustive logging of every decision and why it was made, explicit approval gates on anything consequential, and review processes that satisfy whoever is accountable if something goes wrong.
Work that sits under a compliance regime — health records, financial transactions, anything with a regulator attached — adds review and documentation overhead that a purely internal, low-consequence tool simply does not need. This is not really about the industry label; it is about what the agent is trusted to do without asking first. A "boring" internal workflow that happens to touch payroll can carry more of this cost than a customer-facing one that only ever drafts text for a person to approve.
The state of your data
An agent is only as good as what it can see. Clean, structured, consistently labelled records are fast to build against. Records that are inconsistent, duplicated across systems that disagree with each other, or missing the fields a decision actually depends on are not — and building on top of messy data without acknowledging it produces an agent that fails quietly, which is worse than one that fails loudly.
If your data needs work before a build can start, that is its own project, with its own cost, and a competent scope will say so rather than folding it silently into the build price. Part of any honest first conversation is checking whether what you have is good enough for what you are asking the agent to do.
How much human review the workflow needs
Two agents that do the same task can cost very different amounts to build depending on how much a human is expected to check. An agent that operates with full autonomy on a low-stakes task needs less guardrail engineering than one that must present its reasoning, surface its confidence, and wait for sign-off before every consequential action — because that hand-off itself has to be designed, tested, and made genuinely usable for the person on the other end of it.
Counterintuitively, more human-in-the-loop review is not always the cheaper option just because it sounds more conservative. A well-designed approval step is real engineering work in its own right, and a workflow that never lets the agent act without a person costs you the ongoing time of that person, every time — which belongs on the other side of the ledger, covered below.
Whether the workflow is already defined or still needs discovery
Some workflows are already documented: the steps are written down, the exceptions are known, and everyone agrees on how the work is actually done. Others exist only as tribal knowledge — three people do it three slightly different ways, and nobody has written down what "correct" looks like. The second kind costs more before a single line of anything gets built, because that discovery work — sitting with the team, watching the work happen, reconciling the different versions of "how we do this" — has to happen first, and it cannot be skipped without the build inheriting the confusion.
A workflow that is already mapped, with clear rules and known exceptions, moves straight to design. A workflow that only exists in someone's head needs that head examined first.
What the build price does not include
The number you get quoted for the build is not the full cost of owning the system. Three components are easy to leave out of a budget and expensive to discover later.
Running costs
Once live, an agent consumes resources every time it runs: model and API usage that scales with volume, hosting for whatever it runs on, and — for a voice agent — telephony minutes on top of everything else. None of this is part of the build price, because none of it is knowable until the system is live and you can see real volume. A narrower agent handling fewer cases keeps this number down; a system built to handle enormous volume from day one carries a running cost to match, whether or not that volume ever arrives.
Maintenance
An AI system is not a one-off purchase. Models get updated, the APIs it connects to change, and your business evolves — new products, new policies, new edge cases the agent has never seen. Someone has to watch what it is doing, catch drift before it becomes a visible problem, and tune it as your workflows shift. Our guide to AI maintenance costs covers what typically drives that ongoing figure up or down, and it is worth reading before you commit to a number for the build alone.
Your own time
The build price covers the agency's work. It does not cover the hours your team spends in discovery sessions, reviewing test results against real cases, and training people to work alongside the agent once it launches. That time is real, it is usually underestimated, and a scope that pretends otherwise is being optimistic on your behalf without asking first.
A framework for deciding whether the build is worth it
Before you price a build, price the problem it would solve. The method is simple enough to run on your own numbers without anyone else's help.
Start with the fully loaded cost of doing it today. Take the hours a person spends on the workflow each week and multiply by their fully loaded hourly cost — salary, benefits, and overhead, not just base pay. That is the size of the problem in money terms, and it is the ceiling on what a build could ever be worth to you.
Estimate the share that is genuinely automatable. Not the share you wish were automatable — the share that follows a repeatable pattern an agent could actually learn from your historical cases. If a workflow takes fifteen hours a week and roughly two-thirds of the cases follow the same shape, that two-thirds is your addressable automation. The remaining third is judgement-heavy or unusual enough that a person will keep doing it regardless of what gets built.
Price the exceptions that remain. That leftover third does not disappear. Multiply it by the same fully loaded cost to see what the workflow still costs you after a successful build — because a good agent removes the repeatable load, not the whole job, and a scope that promises otherwise is overselling.
Compare the gap to what the build and its running cost would take to recover. If the addressable share represents a meaningful, recurring cost and the workflow has enough volume to keep paying that cost month after month, a build is worth investigating properly. If the hours are small, or nearly all of the work is the judgement-heavy exception case, a simpler tool — or no tool — is the honest answer. Our build vs. buy comparison walks through the same question from the angle of custom versus off-the-shelf software, if that is the fork you are weighing.
Why vendor quotes vary so much
Two agencies quoting the same brief can land on very different numbers, and the gap is rarely one of them padding the price. More often, they are quietly pricing different projects. One assumes three systems; the other assumes five once they account for a legacy tool you mentioned in passing. One includes a testing phase against your real historical cases; the other tests against a handful of examples and calls it done. One prices the first three months of running cost into the number; the other hands you a build price and lets the running cost surprise you later.
Questions that make quotes comparable
Ask every vendor the same set of questions and the gap usually shrinks, or at least becomes explicable:
- Exactly which systems does this price assume, and what happens if another one turns out to be in scope?
- How is the agent tested before it goes live, and against whose data — a demo dataset or ours?
- What is included in the build price versus billed separately — data cleanup, added integrations, ongoing running costs?
- Who owns the system once it is built, and what does changing it later cost?
- What happens when the agent hits a case it was not designed for?
A vendor who answers all five clearly and consistently is pricing a real project. A vendor who deflects more than one or two is probably still guessing.
What makes a build cheaper vs. more expensive
| Factor | Cheaper to build | More expensive to build |
|---|---|---|
| Systems touched | One or two, modern APIs | Several, including legacy systems without a clean API |
| Judgement required | Follows the same steps every time | Weighs context and makes contextual calls |
| Volume | Low, edge cases are rare | High, edge cases appear constantly |
| Consequence of error | Low stakes, easily reversed | High stakes — money, health, legal or compliance exposure |
| State of the data | Clean, structured, consistent | Inconsistent, scattered, contradictory across systems |
| Human review needed | Light touch, agent acts mostly alone | Heavy approval gates on consequential actions |
| Workflow definition | Already mapped, exceptions known | Undocumented, varies by person, needs discovery first |
Most real projects sit somewhere in the middle of this table rather than at either end, which is exactly why a proper scope looks at your specific mix of factors instead of applying a flat rate.
How Calfy prices a custom AI agent
We do not publish a rate card, for the same reason this guide has no dollar figures in it: the honest price depends entirely on the seven factors above, and any number given before we understand them is a guess dressed up as a quote. What we do instead is scope the work properly — mapping the workflow, counting the integrations, checking the data, understanding what happens if the agent gets something wrong — and then agree a clear price with you before any build work starts. You see the number, and the reasoning behind it, before you owe us anything. The full sequence is laid out on our process page, and our pricing page explains exactly what is included in that number and what is scoped separately.