Why agent projects vary so widely
Two AI agent projects can differ in cost by ten times while sounding identical in a sales conversation. The variance rarely comes from the language model, which is a metered utility. It comes from everything wrapped around the model: how many systems the agent touches, how much can go wrong, how visible its actions need to be and who supports it at 2am.
Understanding the drivers matters more than obtaining a single number, because the drivers are controllable. Scope decisions made in the first two weeks of an engagement move cost more than any tooling choice.
Workflow complexity
The core driver is the shape of the workflow the agent operates in. A triage agent that reads inbound requests and routes them to named queues has a handful of decision points. An agent that reads requests, looks up records, drafts responses, updates two systems and escalates edge cases has dozens, and each decision point needs definition, testing and an answer to the question of what happens when the agent is unsure.
Exception variety is the hidden multiplier. Workflows with three well-understood exception types cost far less than workflows where every week produces a new edge case, because the second kind needs broader human-review lanes and longer evaluation cycles.
Integration surface
Every system the agent reads from or writes to adds scope: authentication, data mapping, rate limits, failure handling and test environments. Clean, documented APIs keep this predictable. Portals without APIs pull browser automation into the project, and legacy systems can add more integration work than the agent logic itself.
Write access costs more than read access. An agent that drafts for a person to send is a smaller build than an agent that commits changes to a system of record, because writes demand validation, approval gates and rollback paths.
Guardrails and controls
Production agents need scoped tool permissions, approval gates for sensitive actions, structured audit logs and escalation paths that hand unclear work to people with context. Each of these is designed and built, and together they commonly account for a third or more of the engineering effort in an enterprise deployment.
Treating controls as optional extras is how agent projects fail reviews and stall before launch. Pricing them in from the start is cheaper than retrofitting them after a security or compliance objection.
Evaluation and iteration
Unlike deterministic automation, agent behaviour is validated statistically: a test set of real cases, quality thresholds agreed with the business, and iteration until the agent clears them. Building that evaluation harness is part of the initial cost, and running it against every change is part of the ongoing cost.
Model and prompt iteration continues after launch as inputs drift and providers update models. Programs that budget for this iteration keep quality stable; programs that do not are usually back within a quarter asking why accuracy fell.
Support and operations
After go-live, someone monitors runs, reviews exception queues, applies model updates and answers for the agent's output. That support model, whether internal or provided by the delivery partner, is a real recurring cost that belongs in the comparison against the manual work being replaced.
Inference usage is also recurring but is usually the smallest line: for most operational workflows, model spend is far below the cost of the labour the agent displaces, and it scales with volume rather than with ambition.
Keeping the first investment measurable
The reliable way to control agent cost is scope discipline: one workflow, defined exception lanes, the minimum integration surface that produces measurable value, and evaluation criteria agreed before the build starts. That first release proves value and reliability with a bounded budget.
Expansion after a successful first release is cheaper per workflow than the first build, because the control model, integration patterns and evaluation harness already exist and are reused.
