What actually drives the cost of an AI agent

Published 4 August 2026 · Relayworks AI

The cost of an AI agent is decided by architecture, not by which model you pick. Build cost is dominated by integration and evaluation, not prompting. Running cost is dominated by how many steps you send to a model at all. Both are design decisions made in the first two weeks — and both are usually made badly.

Budgeting for AI work is difficult because the industry talks about the wrong variables. Here is what actually moves the number, in the proportions we see across real builds.

Where build effort actually goes

The distribution surprises people: the model work is the small part.

Two consequences follow. First, a project's cost is set mostly by how many systems it must touch and how well those systems behave — not by ambition in the model layer. Second, anyone quoting you a build without having looked at your integration surface is guessing.

What moves a build from cheap to expensive

Notably absent: model choice. It rarely moves a build materially, and treating it as the main variable is usually a sign the harder questions have not been asked yet.

Running cost is an architecture decision

This is the line everyone asks about and the one most often modelled wrongly, because people multiply their total step count by a large model's price.

Take a support agent handling 5,000 conversations a month, each averaging six turns — naively 30,000 model calls. But most of those steps are deterministic: looking up an order, checking a status, formatting a reply from a template. They do not need a model at all.

Same behaviour, same quality, roughly one-seventh the cost. This is why we treat cost as an architectural concern rather than a procurement one — and why "which model is cheapest" is usually the wrong question.

The lines beyond inference

Inference is rarely the largest running cost. The full picture:

• Infrastructure — compute, database, queue, vector store, logging. Steady and predictable.
• Third-party APIs — messaging, telephony, OCR, search. Frequently larger than inference, and frequently forgotten.
• Monitoring and evaluation — tracing tooling and scheduled evaluation runs.
• Operations — someone monitoring quality, migrating models and responding to incidents.

The costs nobody budgets for

• Model migrations. New models ship constantly. Each needs testing and usually a prompt revision. Budget two or three a year — they normally improve quality and reduce cost, so this is worth spending.
• Evaluation set maintenance. Your test cases go stale as the business changes. A few hours a month.
• Edge-case handling after launch. Real users find inputs nobody imagined. Reserve 15–20% of the build effort for the first three months post-launch.
• Internal change management. Never on the invoice, and the most common reason a working system fails to deliver its return. If nobody's job changes, nothing was saved.

How to think about the return

The honest calculation is not "AI cost versus salary". It is:

(hours removed × loaded hourly cost) + (value of work now possible) − (build amortised) − (running cost) − (cost of errors that get through)

That last term is the one that gets omitted, and it is why guardrails and evaluation are not optional extras. A system that is 95% accurate on a workflow where an error is expensive to remediate has a very different economic profile from one that is 95% accurate on a workflow where an error costs a polite apology.

When not to build

If the process runs fewer than a few hundred times a month, or is genuinely different every time, or has no measurable cost attached to it — the payback is unlikely to justify the build. A rules engine, a better form, or fixing the upstream process is frequently the cheaper answer, and we say so.

Our two-week diagnostic exists precisely to produce this arithmetic with your numbers rather than ours, before anyone commits to a build.

---

Last updated 4 August 2026. If something here is out of date or wrong, tell us — we will fix it and credit you.