Why automation pricing is a different shape than agent pricing
It is worth being precise about the distinction, because the two get bundled together constantly in sales conversations. An AI agent is priced largely by how much judgement it has to exercise — whether it is weighing context, making a call that could go more than one way, and how much testing that call needs before anyone trusts it unattended. Our guide to what a custom AI agent costs walks through that model in detail: judgement, consequence of error, and volume are the drivers, and none of them are cheap to get wrong.
Automation is a different job. It follows a defined path — trigger, steps, conditions, outcome — and runs it the same way every time. There is no model making a judgement call on each case, so there is nothing that scales in cost the way inference does on an agent. What does scale in cost is the number of systems the workflow has to touch and how well those systems cooperate. Get that part right and the rest of the pricing conversation is mostly arithmetic, not guesswork.
That does not mean automation is always the cheaper build in absolute terms — a twelve-system reconciliation process with heavy exception handling can cost more than a narrow, single-purpose agent. It means automation's cost is driven by a smaller, more countable set of variables, which is exactly why it is easier to scope accurately before anyone starts building.
What actually moves an automation quote
Six factors move the number, roughly in the order they matter.
Integration count. Every additional system the automation touches is another authentication method to manage, another data format to translate, and another place two systems can quietly disagree about what "correct" looks like. A build that connects two systems is a contained project. A build that has to keep five systems in sync is a meaningfully bigger one — not because the logic is harder, but because there are more seams that can fail.
Whether each system has a real API. A modern platform with a documented, stable API is the cheap case — the connection is direct and the behavior is predictable. A legacy system without one is not automatically a blocker, but it usually means building a bridge: a scheduled export, a direct database connection, a webhook someone has to keep working. That bridge is its own piece of engineering, and it is one of the biggest reasons two quotes for what sounds like the same automation can land far apart.
Data quality. An automation that reads clean, consistently structured records is fast to build against. One that has to reconcile records that are duplicated, inconsistently labelled, or contradictory across systems needs extra logic just to decide which version of the truth to trust — before it can do the actual job it was built for. Messy data does not make automation impossible. It makes it a bigger project than the one-line description suggests.
Volume. A process run a handful of times a week can tolerate a simpler design, because an occasional edge case is easy for a person to catch and fix by hand. A process run hundreds of times a day needs the edge cases designed for up front, because at that volume they stop being occasional and start being routine — and a small error rate compounds fast when it is multiplied by every case passing through.
Error-handling requirements. What has to happen when a step fails partway through — a system times out, a record does not match, an API returns something unexpected? An automation that can simply flag the failure and wait for a person is cheaper to build than one that has to retry intelligently, roll back partial changes, and escalate differently depending on where in the sequence it broke.
How many exception paths exist. The main path through a workflow is rarely the expensive part. The expensive part is everything that is not the main path — the order that arrives with a missing field, the customer who does not fit the standard category, the approval that needs a different rule because of who is asking. A process with one or two well-understood exceptions is straightforward. A process where the exceptions outnumber the standard cases is a sign the process itself needs simplifying before it gets automated at all, a point the workflow automation page covers from the build side.
The running-cost shape: automation vs. an agent
This is where the two builds diverge the most after launch, not just at scoping. An agent's running cost scales with how much judgement it exercises — every decision typically calls a model, and that cost rises with volume and with how much reasoning each case requires. An automation's running cost is different in shape: it is mostly the cost of the systems it connects to and however it is hosted, not a per-decision charge, because there is no decision being made on each pass through the pipeline. Moving a thousand records through a defined sequence does not carry the same cost curve as a thousand cases each requiring a model to weigh context and choose.
That is the practical version of the point made at the top of this guide: automation is cheaper to run at volume because the logic is fixed rather than inferred fresh each time. It is also why a workflow that looks automatable on paper but actually needs contextual judgement on most cases is often mis-scoped as automation when it should be scoped as an agent, or some blend of both — rules for the parts that are genuinely mechanical, judgement only where it earns its place. Running costs for either shape should be estimated before launch, not discovered afterward; our guide to AI maintenance costs covers what typically moves that figure once a system is live.
The "we already pay for Zapier" question
This comes up on nearly every automation call, and it deserves an honest answer rather than a sales pitch. Tools like Zapier and Make are genuinely good at what they do: connecting a couple of apps around a clear trigger, live in an afternoon, maintained by someone who is not a developer. For a simple, self-contained process, one of them is usually the right answer, and paying for a custom build to replace it would be solving a problem that does not exist yet.
A custom build starts to earn its cost at a specific point, not a vague one. Our comparison of custom automation against Zapier covers this in depth, but the short version is that per-task platforms hit a ceiling in three places: conditional logic that turns unmanageable as branching rules pile up, a pricing model that scales with volume in a way that gets expensive once a process runs constantly, and error handling that is limited to whatever the platform's own interface allows. When a workflow is still simple and low-volume, none of that matters and the off-the-shelf tool wins on cost. When a workflow has real branching, real volume, and a real cost to a silent failure, a custom build usually displaces the subscription-based tool — not because custom is inherently better, but because the ongoing per-task cost and the maintenance burden of an unwieldy setup start to exceed what a scoped, owned system costs to run.
When the process isn't actually documented
Some workflows are already written down: the steps are known, the exceptions are named, and everyone on the team describes the process the same way. Others exist only as tribal knowledge — three people doing it three slightly different ways, with nobody able to say which version is actually correct. The second case costs more before a single piece of the automation gets built, because that discovery work is real: sitting with the people who run the process today, watching it happen rather than being told about it, and reconciling the different versions into one agreed sequence.
That discovery cost is easy to leave out of a rough estimate and expensive to discover halfway through a build, when it turns out the automation was designed against a version of the process that was not quite right. A workflow that is already mapped moves straight into design. A workflow that only exists in someone's head needs that head examined first, and a scope that skips this step is building against a guess.
What makes an automation cheaper or pricier
| Driver | Cheaper | Pricier |
|---|---|---|
| Integration count | One or two systems | Several systems that all need to agree |
| API quality | Modern, documented APIs | Legacy systems with no clean API — a bridge has to be built |
| Data quality | Clean, consistent, structured | Duplicated, inconsistent, contradictory across systems |
| Volume | Low, edge cases are rare | High — edge cases surface constantly |
| Error handling | Flag and wait for a person | Retry logic, rollback, tiered escalation |
| Exception paths | One or two well-understood exceptions | Exceptions that outnumber the standard case |
| Process documentation | Already mapped, agreed by the team | Undocumented, varies by who you ask |
Most real projects land somewhere in the middle of this table, which is exactly why a proper scope looks at your specific mix of these factors rather than quoting off a template.
How to compare automation quotes
Two vendors quoting the same brief can land on very different numbers without either one padding the price — more often, they are quietly scoping different projects. Ask each vendor the same questions and the gap usually shrinks or becomes explicable:
- Exactly how many systems does this price assume, and what happens if another one turns out to be in scope once you look closer?
- Does the price include discovery — mapping the process as it actually runs — or does it assume the workflow is already documented?
- How are exceptions handled, and how many exception paths does the quote account for?
- What is the running cost once this is live, and does it scale with volume the way a subscription tool would?
- Who owns the system afterward, and what does changing a rule cost once it's built?
A vendor who answers all five plainly is pricing a real project against your actual workflow. A vendor who deflects more than one or two is still guessing, whatever number they put on the page.
How Calfy prices automation projects
We do not publish a rate card for automation any more than we do for agents, and for the same reason — the honest number depends on the drivers above, and any figure given before we understand your systems is a guess. What we do instead is scope the workflow properly: count the integrations, check what each system's API actually allows, look at the data, and map the exception paths that matter. You get a clear price and the reasoning behind it before any build work starts. Our pricing page explains exactly what sits inside that number and what gets scoped separately, and the workflow automation page covers the shapes of automation we build most often.