Automation costs stay small until they do not. What changes the number is almost never the price per use. It is loops, retries, and doing the same work again.
Work out the cost per candidate
Think in cost per candidate processed, not cost per month. It is the only figure that tells you what happens when your volume triples.
For each candidate, count how many times you call the AI, roughly how much text goes in and comes out, how many times the same person might get processed again, and what your retry setting allows. Multiply by expected volume. Then multiply again to allow for the days when something goes wrong — that last step is the one people leave out, and the one that produces the surprising bill.
| What drives cost | Effect |
|---|---|
| Calls per candidate | Straightforward to work out |
| How much text you send | Straightforward, but larger than people expect for full documents |
| Reprocessing on every change | Multiplies quietly. The most common surprise |
| Retries | Multiplies, and worst exactly when things are already going wrong |
| Agents going round in circles | No limit unless you set one |
Limits and backing off
Every service you connect to limits how often you can call it — the AI provider, the hiring system, the calendar, the email service. Under normal load you will never notice. On the day you process a backlog, you will hit all of them at once.
- When something fails, wait before retrying, and wait longer each time. Always.
- Use a queue with a limit on how many things run at once, rather than firing everything off together.
- Cap how many times each item retries, and send anything that exceeds it somewhere you will look. Items that vanish silently after three failures are the hardest problems to find.
Three ways things run away
- Trying forever. The goal cannot be reached, so it keeps trying differently. Fixed by a maximum number of steps and a maximum cost per run.
- Setting itself off. The automation writes to a field, the write triggers the automation, which runs again. Fixed by excluding your own system account from triggers.
- Spreading out. One event creates work for each candidate, and each of those creates more. Fixed by a limit on items per run.
What actually breaks first
Not the AI. In practice the first things to fail are the connection limits and the queue of things waiting for a human.
That second one is worth planning for. If your check needs a person and volume triples, the automation now produces a backlog of things waiting for approval — and the pressure to approve them in bulk arrives at exactly that moment. Capacity for the human step is part of the design, not an afterthought.
A way to stop it
- One switch that stops everything, known to more than one person, usable without a developer.
- A decision about work already in progress — finish it or abandon it — made in advance and written down.
- Saved versions of your instructions and settings, so going back means picking an earlier version rather than remembering what you changed.
- The ability to run a batch again after a fix, without repeating the actions that already worked.
Decide this before you launch
What is the worst thing this could do to candidates if it ran unattended over a weekend? If the honest answer is "message several hundred people" or "reject a batch", your never-do list is not strict enough.