Decision support
Is building an AI agent cheaper than hiring someone?
Sometimes. The comparison most teams run — token cost against salary — leaves out the three lines that decide it.
The question
We could hire someone to do this, or build an agent. Which is cheaper?
The short answer
The comparison usually presented is monthly token cost against monthly salary, and agents win it enormously — which is why it is the wrong comparison. Three lines are missing. Build cost: getting an agent from demo to trustworthy is typically six to twelve weeks of engineering, not a weekend, and that is capital spent before any saving starts. Eval maintenance: an agent needs a test suite that is extended every time the surface grows and re-run on every model change, which is ongoing engineering forever, not a one-off. And the failure tail: a person who is unsure asks; an agent that is unsure proceeds confidently, so you are also buying the cost of the mistakes and the review capacity to catch them. Include those and agents still often win — but on tasks that are high-volume and narrow, not on tasks that are varied and judgement-heavy.
Written for
- Founders weighing an agent against a headcount
- Leaders asked to justify an automation budget
- Anyone who has been shown a payback calculation that felt too good
Why the answer is that
Start with what an agent is genuinely good at, because that determines whether the business case exists at all. Agents win decisively where the task is high-volume, well-specified, and the same shape every time: extract these fields, classify this ticket, answer from this document set, generate this report. They lose where the work is varied, requires chasing someone for missing context, or carries accountability that has to sit with a person. Most roles are a mixture, which is why “replace a headcount” is usually the wrong framing and “remove the eighty percent of this role that is repetitive” is the right one.
Then be honest about build cost, because this is where published payback calculations quietly cheat. A prototype takes days. An agent you would let touch customer data unsupervised takes six to twelve weeks: the eval suite, the tool-argument validation, the tracing, the bounded loops, the approval gates, the rollback path. Front-load that and a five-thousand-a-month saving against a forty-thousand build is a payback of eight months, not eight days.
The line that surprises people most is eval maintenance. A hired person absorbs change themselves — a new product, a new edge case, a new policy, and they adapt. An agent does not: someone extends the test suite, someone re-runs it when the provider updates the model, someone investigates when a pass rate moves. Budget a meaningful ongoing fraction of an engineer for as long as the agent runs. That cost never converges to zero, and leaving it out is the single most common error in these business cases.
And the failure tail, which is the difference between the two options that matters most. A junior employee who does not understand a request asks a question. An agent proceeds, fluently and wrongly, at volume. So the real comparison is not agent-cost against salary; it is agent-cost plus review capacity plus the expected cost of errors, against salary. On a narrow high-volume task that sum is still usually much smaller. On a judgement-heavy task it frequently is not, and the honest recommendation is to hire.
The lines that are usually missing
The first two rows are the comparison people run. The rest is what changes the answer.
| Cost line | Agent | Employee |
|---|---|---|
| Ongoing run cost | Tokens, infra — often modest | Salary plus employment costs |
| Throughput | Effectively unlimited, parallel | Fixed hours, one thing at a time |
| Build cost before any saving | 6–12 weeks of engineering | Recruitment plus onboarding |
| Eval suite maintenance — usually omitted | Ongoing, forever, per model change | None — they adapt themselves |
| Cost of being wrong — usually omitted | Confident errors at volume | Asks a question instead |
| Review capacity — usually omitted | Someone checks the risky outputs | Normal management |
| Handles novel situations | Poorly, and without saying so | Well, and flags them |
| Accountability | Sits with whoever deployed it | Sits with the person |
| Scales down | Instantly | Slowly and painfully |
A quick sanity check on any payback claim: ask what happens in month thirteen when the provider deprecates the model version. If the plan has no answer, the eval-maintenance line is missing and the payback figure is optimistic.
A realistic first-deployment timeline
What “how long does implementation take” actually looks like for one narrow, well-chosen task. Multiply for anything broader.
| Phase | Duration | What exists at the end |
|---|---|---|
| Pick the task and define done | 3–5 days | A written specification of correct output, and how you will measure it |
| Prototype | 1 week | It works on happy-path examples. Do not let anyone see this yet |
| Eval suite on real traffic | 1–2 weeks | A pass rate you trust, and a list of what actually fails |
| Close the gaps the evals found | 2–3 weeks | Validation, bounded loops, cost ceiling, tracing |
| Shadow mode | 1–2 weeks | It runs on live traffic, takes no action, and you compare against humans |
| Gated rollout | 1–2 weeks | Live on a slice, with approval gates and a rollback path |
Six to twelve weeks, and shadow mode is the phase teams skip. It is also the cheapest insurance available: it tells you the real error rate before a single customer is affected.
Get the answer for your own system in four minutes
The free scorecard produces a score out of 100, a breakdown across reliability, cost and observability, and your gaps ranked by production risk with a fix and effort estimate for each. It prints to a PDF you can take into a planning meeting — which is usually more persuasive than an argument.
Run the scorecardIf you are the engineer who found this page: Written to be forwarded. If you are the engineer who found this, send the relevant one up — it is framed for the person who has to approve the work.
If you decide to do the work
The engagements this decision leads to, each with the full method and effort estimates — whether your team runs it or I do.
Questions
Is an AI agent cheaper than hiring someone?
On a high-volume, well-specified, repetitive task, usually yes and often by a lot. On varied, judgement-heavy work with real accountability, frequently no.
The comparison that makes agents look free — monthly token cost against monthly salary — omits build cost, ongoing eval maintenance, and the cost of confident errors plus the review capacity to catch them. Include those three and the picture is still often favourable, but on a much narrower set of tasks.
How long does it take to implement an AI agent?
Six to twelve weeks for one narrow task, from specification to a gated production rollout.
A prototype takes days, which is what creates the expectation problem. The remaining time is the eval suite, tool-argument validation, tracing, bounded loops, approval gates, and shadow mode — running on live traffic while taking no action so you can measure the real error rate before a customer is affected.
What ongoing cost does an AI agent have besides tokens?
Eval maintenance, and it never goes to zero. Every time the agent’s surface grows the test suite is extended; every time the provider updates the model it is re-run; every time a pass rate moves someone investigates.
Budget a meaningful ongoing fraction of an engineer for the life of the agent. A hired person absorbs change themselves — an agent does not, and that difference is the most commonly omitted line in these business cases.
Should we replace a role with an agent or automate part of it?
Automate part of it. “Replace a headcount” is almost always the wrong framing because most roles mix repetitive work with judgement, chasing people for context, and accountability that has to sit with a person.
The framing that works is removing the repetitive majority of a role, keeping the person for the rest. That is also a far easier project to scope, to evaluate, and to reverse if it does not work.
Want a second opinion on the decision?
Describe your situation and I will tell you what I would do — including when that is "nothing" or "handle it internally". No charge for that, and it is genuinely how a lot of these conversations end.
Other decisions
- What an agent audit should cover
- Questions to ask before launch
- Build or buy: observability
- Metrics worth reporting upward
- Do you need outside help?
- Can an agent touch our internal data?
- Is an agent different from a chatbot?
- Governance, audit logs and compliance
- Do we need our own model?
- Where to put a human in the loop
- Working with the systems you already have