Load only what is needed
Route to a small relevant tool set instead of sending every schema on every turn.
Guide / AI agent economics
How much does an AI agent cost?
An AI agent does not have one price. Its cost is the sum of every model turn, tool call, memory operation, retry, fallback, validation step and human review required to complete useful work. The right estimate therefore starts with the workflow, not a vendor rate card.
The short answer
Price the completed task, then scale it to monthly demand.
A simple chat request may create one prompt and one response. An agent can create a plan, search several systems, call tools, inspect results, revise its plan, retry failed actions, ask a stronger model for help, validate the final output and wait for a person to approve it. Every step can consume tokens, infrastructure and labour. Two agents using the same headline model can therefore have radically different costs.
A defensible monthly estimate begins with four quantities: completed tasks per month, agent runs per task, model and tool activity per run, and the probability that the run succeeds without escalation. The estimate should then include uncertainty. Average behaviour alone is not enough because long conversations, retry storms and unusual tool paths create a right tail. For budget approval, Class1 treats P90 as a practical conservative view while keeping the estimate maturity visible.
Cost anatomy
The nine components of AI agent cost.
1. Planning callsThe agent may use one or more model calls to interpret the goal, decompose the work and choose tools before any business action occurs.
2. Execution turnsEach step can require another prompt and response. Multi-step work increases cost with the number of turns, not merely the number of user requests.
3. Tool schemasTool names, descriptions and argument schemas are often sent with every relevant model call. A large tool catalogue can become recurring input context.
4. Tool infrastructureSearch, databases, browsers, vector stores, OCR, code execution and third-party APIs may have their own metered or operational costs.
5. Memory and retrievalConversation history, summaries, embeddings and retrieved documents increase input volume and may add separate storage or retrieval charges.
6. RetriesTimeouts, invalid output, unavailable tools and failed actions can repeat part or all of the workflow. Retries multiply completed-task cost.
7. FallbacksA weaker model may escalate to a stronger model, or one provider may fail over to another. The complete route must be estimated.
8. Validation and guardrailsSafety checks, evaluators, policy models and structured-output repair can add model calls even when the final user experience appears to contain one answer.
9. Human reviewWhen a person must inspect, correct or approve the result, labour becomes part of the cost per completed task and may dominate the token bill.
A practical equation
Model the route, success rate and demand separately.
For each agent route, estimate the input and output tokens for every model call, apply the appropriate rate basis, and add tool or infrastructure charges. Multiply that route cost by its probability. Then account for retries and fallbacks. Finally, divide by the probability that the workflow reaches an acceptable completed task. This avoids the common mistake of reporting the cost of an attempt as though every attempt succeeds.
Monthly cost is the resulting cost per completed task multiplied by completed-task demand. Keep demand separate from architecture. Product adoption can grow while the workflow stays efficient, or workflow inflation can increase calls per task even when user count is flat. Separating those effects gives engineering and finance a clearer explanation of variance.
The estimate should not hide unknowns. New agents often lack measured route probabilities, token distributions and success rates. Label those assumptions, assign an early estimate class and plan to calibrate after deployment. A wide but honest range is more useful than a precise number based on invented behaviour.
Three common architectures
Agent design determines the shape of the bill.
Single-agent tool user. One model plans and executes with a small set of tools. This can be efficient when the task is narrow, tool descriptions are concise and the agent has strict turn limits. The main risks are repeated context, broad tool schemas and retries after invalid tool calls.
Router plus specialists. A routing model chooses a specialist model or workflow. This can reduce cost when easy tasks stay on cheaper routes, but the router itself adds a call and misrouting may trigger rework or escalation. Estimate the complete weighted route distribution.
Multi-agent collaboration. Several agents exchange plans, critiques or delegated work. This can improve difficult outcomes, but each hand-off adds context and model turns. The architecture needs explicit stopping rules, bounded delegation and a measurable benefit over a simpler workflow.
Worked estimating framework
Build the estimate before writing a budget number.
01
Define completion
Specify what counts as a successful business outcome, not merely a model response.
02
Map routes
List normal, retry, fallback, escalation and human-review paths.
03
Estimate quantities
Assign calls, tokens, tool use and route probabilities to each path.
04
Apply the rate basis
Use a frozen, dated basis so the approval can be reconstructed later.
05
Simulate uncertainty
Model demand, output, context, retries and fallback frequency as distributions.
06
Approve and calibrate
Review P50, P90 and drivers, then compare the approved estimate with actuals.
Why P90 matters
Agent cost has a tail that averages conceal.
Most successful runs may finish quickly, while a minority loop through several tools, replay a large context and escalate to a stronger model. Those expensive runs can materially affect the monthly bill. The average is still useful, but it does not show the budget exposure created by the tail.
P50 describes the median modelled month. P90 gives a more conservative approval number under the declared assumptions. P95 can support stricter review for high-volume or low-margin products. These percentiles are not promises; they are conditional estimates. The report must show the assumptions and estimate class beside the distribution.
Controls
Reduce agent cost without removing useful capability.
Set explicit limits
Bound planning, reflection, delegation and recovery loops with clear stop conditions.
Escalate deliberately
Use fit-for-purpose models and reserve stronger models for routes that justify them.
Summarize and retrieve
Avoid replaying entire histories when compact state and targeted retrieval are sufficient.
Classify before retrying
Retry only recoverable failures and fix recurring invalid-output or tool-contract problems.
Review by risk
Apply human approval to consequential cases instead of every routine successful task.
FAQ
AI agent cost questions.
Is an agent more expensive than a chatbot?
Usually, because an agent can create multiple model turns, tool calls, retries and validation steps for one user goal. A tightly bounded agent can still be economical when it replaces valuable manual work.
What is the best unit for an agent budget?
Use cost per completed business task and monthly completed-task demand. Also monitor cost per attempt and calls per task so failure and workflow inflation remain visible.
Can I estimate an agent before it has users?
Yes, but the estimate should be an early screening estimate with declared assumptions and a wide uncertainty range. Replace assumptions with measured distributions after deployment.
Should tool costs be included?
Yes. Include metered APIs, search, databases, vector retrieval, browsers, execution environments and operational labour where they are material to completing the task.
Where should the approval happen?
Review architecture cost while the change is still a pull request. The Class1 estimator illustrates how code signals and declared demand become a P90 decision.
Next step
Estimate the route before the agent becomes production spend.
Start with one agent workflow, define a completed task, map the route and identify the retry and fallback tail. Then use the Class1 method to turn the architecture into a reviewable monthly distribution.