AI agents, automation, or another hire
Three ways to absorb more work, and they are not interchangeable. Picking the wrong one is expensive in a way that takes about six months to become obvious.
In short
Match the option to the shape of the task, not to the budget. Deterministic automation for high volume rule based work where a wrong answer is expensive. An AI agent for work that involves language and messy inputs and where a review step is acceptable. A person for work that needs accountability, relationships, or a decision somebody has to own. Most teams reach for an agent when they needed a rule, and for a hire when they needed to fix a handoff.
The three options, plainly
Deterministic automation
Fixed rules. Same input, same output, every time. Boring and reliable. If a task can be fully described in rules, this is almost always the cheapest answer and it does not drift.
An AI agent
Handles language, unstructured input, and cases the rules never anticipated. It works probabilistically, so it needs a check on the output anywhere being wrong carries a cost.
Another person
Carries accountability, relationships, and judgement that has consequences. It is also the only option that can be held responsible for a decision.
The hybrid that usually wins
A rule based pipeline with a model doing the one messy step in the middle and a person on exceptions. Most systems that actually work look like this rather than like any pure option.
Doing nothing, on purpose
Sometimes the volume does not justify any of the three. Naming that is a decision rather than a failure, and it keeps the budget for the thing that does justify it.
Fixing the handoff first
A large share of work that looks like a staffing problem is a queue problem. Removing one approval can free more capacity than any of the three options, at no build cost.
Why the wrong choice takes six months to show
The failure mode is rarely dramatic. An agent gets pointed at a task that had a perfectly good rule, and for a while it works. Then an input shifts, the output is plausible but wrong, and because it is plausible nobody catches it for a quarter.
The reverse happens just as often. A team writes a rigid automation for work that genuinely varies, then spends a year bolting exceptions onto it, until the exception handling is larger than the original rule and nobody is willing to touch it.
Hiring has its own version. The role gets created to absorb a queue rather than to own an outcome. The new person is busy from week one, which makes the hire look justified, and the underlying handoff problem is now permanently staffed.
None of these are technology mistakes. They are diagnosis mistakes, made before any tool was chosen. They are cheap to avoid and expensive to unwind, which is the worst combination to get wrong.
The order that works is the same every time. Measure what the task actually costs across a month. Try to describe the rule, and notice how hard that turns out to be. Then pick the option that matches what you found, rather than the one you were already leaning towards.
The tools change constantly. What the task needs does not. That is why this page is written around the shape of the work rather than around any particular product, and why the questions above will still be the right questions next year.
Which one fits
The choice is settled by seven signals in the work itself. Read across the row that matches your situation. Where the rows disagree, the cost of a wrong answer wins the argument.
| Signal in the work | Deterministic automation | AI agent | Another person |
|---|---|---|---|
| Input format | Structured and predictable: forms, fields, records. | Messy: email, documents, chat, voice, mixed formats. | Ambiguous, where resolving the ambiguity is the actual job. |
| Volume | High and repeating. The build pays back on repetition. | Medium to high, where writing a rule for every case is impractical. | Low volume and high value, or genuinely varied every time. |
| Cost of a wrong answer | Can be high. It will not improvise. | Should be low, or survivable with a review step before the consequence. | High and consequential, where somebody has to be answerable. |
| How it fails | Loudly. It stops, and you find out. | Quietly. It produces something plausible and wrong. | Visibly, and usually for a reason you can address. |
| Time to working | Days to weeks, once the process is written down. | Days to weeks, plus the evaluation set you have to build first. | Weeks to months including hiring, notice, and ramp. |
| What it asks of you | A process described clearly enough to encode. | Examples of good and bad output, and somewhere a person can review. | Management, context, and work that is worth their time. |
| Where it degrades | When the process changes and nobody updates the rules. | When real inputs drift away from the examples it was set up on. | When the role turns into a queue instead of a job. |
Nothing in this table is about capability. All three options can do most of these tasks. The question is which one keeps working after the person who set it up has moved on to something else.
Five questions that settle it
Run these in order. Most decisions are made by the first or the fourth, and teams that answer all five rarely pick the wrong option.
- Can you write the rule down in one sentence?If you can, and the sentence contains no "it depends", use deterministic automation. An AI agent on a task with a clean rule is a slower, more expensive, less predictable version of an if statement.
- What happens when it gets one wrong?Follow the worst realistic error all the way to its end. If it lands on a refund, a compliance exposure, or a lost client, either put a person on the output or keep a model off that step entirely.
- How many times a month does it run?Below roughly ten, the build usually costs more than the task ever will. That threshold moves if the task sits on the critical path, but volume is the first filter and it removes most candidates.
- Is the work heavy, or is the work waiting?Waiting is a queue problem, and neither a tool nor a hire fixes it. If a task takes four minutes and clears in four days, look at approvals before you look at software.
- Who owns the output once it runs itself?Every automated or agent run process still needs a named person who notices when it stops. Systems without an owner degrade quietly, and that is how a working automation turns into a hidden liability.
Questions we get
Are AI agents replacing rule based automation?
No. They cover a different part of the map. Rule based automation is not going anywhere for structured, high stakes work, because determinism is a feature there rather than a limitation.
What has changed is the boundary. Work that used to need a person because it involved reading and interpreting is now often within reach of a model, and that boundary keeps moving.
How do we tell whether a task is genuinely rule based?
Write it out as if-then statements and see how far you get. If you finish and no "usually", "normally" or "it depends" survived the exercise, it is rule based.
If the exercise is difficult, that difficulty is the finding. Most of the time the task is not complicated, it just was never described, and different people have been doing it differently for years.
What does an AI agent need to work reliably?
Three things: a narrow scope, a set of examples showing what good and bad output look like, and a place where a person can see what it produced.
Teams usually build the first and skip the other two, which is why the pilot works in a demo and drifts in production.
Should we hire someone to run our automations?
Somebody has to own them, but that is rarely a full role at the start. Attach ownership to an existing person who has the time to notice failures, and revisit once the surface is genuinely large.
The signal that it has become a real role is when nobody can say offhand what would break if a given workflow stopped.
Is it cheaper to automate or to hire?
The comparison most teams make is a one off build against a salary, which flatters automation. A fair comparison includes maintenance, the cost of a wrong output, and the cost of the process changing underneath it.
Get the first number from the task cost calculator on this site, then add the other three. The answer often stays the same, but it stops being a guess.
Can we use all three at once?
Most systems that work are all three. Rules handle the predictable path, a model handles the one messy step, a person handles exceptions and owns the outcome.
Designing it that way from the start is much easier than retrofitting a review step onto something already running unattended.
What is the most common mistake?
Automating a process that was never working. Software does not fix a broken process, it makes the same mistake faster, more often, and with fewer people watching it happen.
Fix it by hand first, write down what you did, and only then encode it.
Where should a team start?
One week of measurement. A rough tally of recurring tasks and how long each one takes, kept by the people who do them.
Sort by hours per month, take the top item that a clear rule fully describes, and work on that one. The task everybody complains about is usually the wrong place to begin.
More in the guides and every answer in one place.