Your agent may look cheap at $0.20 per run and still be an expensive workflow.
That happens when it takes four attempts to get a usable result, calls paid tools unnecessarily, sends oversized context on every retry, or produces work a person must largely redo. Looking only at model price, token count, or credits consumed per run hides all of that.
The number that matters is cost per accepted agent outcome: the total amount you spend to produce a result that a human actually approves for its intended use.
This is a practical shift in how you manage agents. Instead of asking, “Which model costs the fewest credits?” ask, “What does one approved lead, accurate extraction, publishable draft, or resolved support case cost us?” Once you can answer that, you can set sensible budgets, identify the real leaks, and reduce spend without blindly reducing quality.
The cheapest run is not always the cheapest result
A single agent task can include more than one model response. It may involve planning calls, tool calls, web or database searches, retries, background jobs, long context windows, and a final human review. Different platforms also bill these parts differently. A credit is not a consistent unit of value across tools.
More importantly, a low-cost run is worthless if the output cannot be used.
Consider two workflows that enrich leads:
- Workflow A costs $0.30 per attempt. It produces an approved record 50% of the time and needs eight minutes of review or correction for every attempt.
- Workflow B costs $0.75 per attempt. It produces an approved record 85% of the time and needs two minutes of review.
Workflow B has the higher sticker price, but it may cost far less for each sales-ready lead once failed attempts and review time are included. The same pattern appears in content, support, research, coding, operations, and document processing.
Do not assume that fewer tokens automatically means lower bills, either. Reducing output, compressing tool results, or selecting a smaller model can help. But it can also create more retries, weaker decisions, or more human cleanup. The bill you want to reduce is the bill for an accepted result.
Start by defining an accepted outcome
You cannot optimize a workflow until you define what success means. “The agent researched leads” is an activity. “Sales approved the enriched lead record as accurate and actionable” is an outcome.
Write one pass/fail rule for each agent task type before you compare models, prompts, or configurations. Keep it specific enough that two reviewers would usually make the same decision.
Examples of usable acceptance rules
- Lead enrichment: Required firmographic fields are correct, the contact fits the target profile, and sales approves the record for outreach.
- Invoice extraction: All required fields are captured correctly and the item is ready for the accounting workflow without manual re-entry.
- Content drafting: An editor can publish after no more than five minutes of changes and no factual or brand-risk issue is found.
- Support triage: The ticket is correctly classified, assigned to the right queue, and includes the information needed for the next person to act.
- Research: The output answers the defined question, contains the requested fields, and passes the review checklist.
Your rule does not need to demand perfection. It needs to reflect the quality level that makes the output economically useful. If a human routinely repairs an agent’s work for 25 minutes, calling that result “accepted” without recording the repair time will make the agent look better than it is.
Count a result as accepted only when it clears the quality bar you would be comfortable handing to the next step in the workflow.
Calculate two numbers, not one
Cost efficiency and return on investment answer different questions. Track both.
1. Fully loaded cost per accepted outcome
Cost per accepted outcome = total workflow cost ÷ number of accepted outcomes
Total workflow cost should include:
- Model charges or agent credits used
- Paid tool, search, database, browser, or API calls
- Agent-platform, hosting, orchestration, or infrastructure charges where applicable
- Every failed attempt and retry
- Human review and remediation time
Include failures in the numerator. Leaving them out rewards unreliable workflows and gives you a false sense of savings.
2. ROI
ROI = (value of accepted outcomes − total program cost) ÷ total program cost
Value should be real, not theoretical. It might be labour time that your team can genuinely redeploy, avoided rework, fewer errors, faster revenue collection, or incremental gross profit. Do not count “hours saved” if nobody can use those hours elsewhere and no measurable benefit follows.
A simple spreadsheet example
Imagine an agent processes 100 invoice tasks in one week. Its model usage costs $110. Tool calls cost $40. Platform and infrastructure costs allocated to this workflow are $20. Review and correction take three total hours, valued at $60 per hour, or $180.
- Total cost: $110 + $40 + $20 + $180 = $350
- Accepted invoices: 72
- Cost per accepted outcome: $350 ÷ 72 = $4.86
If each correctly processed invoice creates $15 of credible value through avoided handling or reduced rework, the accepted outcomes are worth $1,080. The workflow ROI is ($1,080 − $350) ÷ $350, or about 209%.
This example is illustrative. Your own value figure should be conservative. But even a rough calculation is much more useful than comparing token prices in isolation.
Build a one-week agent cost ledger
You do not need a complex finance system to get started. Create a spreadsheet or simple database and log every agent attempt for one high-volume or high-cost workflow over the next seven days.
Use one row per attempt, not one row per final task. That distinction exposes retries and hidden failure loops.
Minimum columns to track
- Task ID
- Task type and workflow version
- Date and owner
- Model or agent configuration used
- Input, cached-input, and output usage where your platform exposes it
- Number of model calls, steps, and tool calls
- Model cost, tool cost, and other direct cost
- Retry count
- Elapsed time
- Final status: accepted, rejected, escalated, or abandoned
- Reviewer minutes and remediation minutes
- Rejection reason or escalation reason
Keep the rejection reasons short and consistent. Good categories include: incorrect output, missing information, unsafe or non-compliant output, tool failure, repeated loop, excessive context, unnecessary escalation, and task not suitable for automation.
If your agent platform provides usage data by project, model, API key, batch status, or cached input, use it. If it does not, log the best available cost estimate and improve your tracking later. Imperfect measurement is still better than optimizing blind.
If you are unsure which workflows deserve this level of tracking, use the AI Automation Opportunity Finder to rank work by value, effort, likely savings, and ROI before expanding an agent programme.
Find the leak before you chase token savings
After a week, sort your ledger by total cost, then review the most expensive rejected and escalated tasks. You are looking for a repeatable failure mode, not one strange run.
Five common credit drains
- Low acceptance: The task is ambiguous, depends on judgement the agent does not have, or has no stable source of truth.
- Retry loops: The agent keeps trying variations of a failed plan instead of stopping and escalating.
- Repeated context: Every run carries instructions, policies, history, or documents that rarely change.
- Expensive tools: Search, browsing, enrichment, or other API calls are used before the agent knows they are necessary.
- Unnecessary escalation: A costly model handles routine work that a smaller model, deterministic rule, or simple form validation could handle.
Be careful with the diagnosis. A long prompt is not automatically a problem if it improves accuracy enough to avoid failures. A premium model is not automatically wasteful if it prevents costly remediation. The ledger gives you a way to test these trade-offs instead of relying on intuition.
Set task budgets and stop rules
Most agent overspend comes from allowing a task to continue after it has stopped being economical. Put hard limits around each task type.
A useful task budget includes four caps:
- Dollar cap: Maximum direct spend for one task.
- Step cap: Maximum number of model calls or agent actions.
- Tool cap: Maximum paid tool calls, ideally with separate limits for the expensive tools.
- Retry cap: Maximum retries before the task stops.
Then define what happens at the cap. The agent should not simply continue. It should stop and do one of three things: escalate to a person, queue the task for a stronger model, or mark it as unable to complete.
For example: “Use the routine model for lead research. Allow two searches and one retry. If required fields are still missing, send the record to a human review queue. Do not use the premium model unless the lead value exceeds the escalation threshold.”
This makes cost a design constraint rather than a surprise at the end of the month. It also avoids relying on an agent to accurately predict its own usage before it begins.
A clear workflow map makes these handoffs easier to design. The SOP-to-Automation Mapper can help you identify which steps should remain deterministic, where the agent is useful, and where a human checkpoint belongs.
Apply savings levers in the right order
Once you have an acceptance rule and guardrails, optimize in this sequence.
1. Remove or redesign poor-fit tasks
If a task has low acceptance and high review effort, do not start by squeezing its token count. Narrow the task, provide a better source of truth, add structured inputs, or remove it from automation. The biggest saving is often not running a weak task at all.
2. Fix the workflow before changing models
Improve tool order, required fields, validation checks, and instructions. Ask the agent to stop when a required condition cannot be verified rather than inventing an answer. A reusable prompt with variables, constraints, and QA checks can reduce avoidable retries; use the Reusable Prompt System Builder to turn a one-off prompt into a more controlled operating system.
3. Route by difficulty
Send routine, well-defined tasks to a smaller or lower-cost model. Escalate only cases that fail validation, contain ambiguity, exceed a value threshold, or require deeper reasoning. Compare the whole route, including the cost of escalation and review. A cheap first pass that sends nearly everything to a premium model is not necessarily a saving.
4. Reduce repeated context with caching or persistent state
If instructions, policies, product information, or reference material repeat across tasks, structure the workflow so stable material remains consistent and reusable. Some platforms offer cached-context pricing, but the actual benefit depends on cache use, storage charges, prompt structure, and how often the material repeats. Measure billed cost and accepted outcomes after the change.
5. Batch non-urgent work
For tasks that do not need an immediate answer, asynchronous batch or flexible processing can reduce inference cost. Examples include overnight enrichment, document classification, content variations, and backlog cleanup. Treat this as a pricing change, not a quality improvement: keep the same acceptance rule and compare results before moving an important workflow.
Run a fair workflow comparison
When you test a new model, prompt, cache setup, or service tier, use the same representative task set and the same acceptance rule. Do not compare last month’s easy tasks with this month’s difficult ones.
For each option, compare:
- Acceptance rate
- Total cost
- Cost per accepted outcome
- Median and worst-case task cost
- Reviewer and remediation minutes
- Latency, if speed matters
- Top rejection reasons
Choose the lowest-cost option that still clears your quality threshold. If it fails the threshold, it is not a cheaper substitute; it is a different and potentially worse workflow.
A 30-day operating cadence
Good agent cost control is a routine, not a one-time audit.
- Week 1: Pick one workflow, define acceptance, and capture every attempt.
- Week 2: Identify the top five rejection reasons and the most expensive failure pattern. Add task budgets and stop rules.
- Week 3: Test one change only: task redesign, routing, prompt structure, caching, or batch processing.
- Week 4: Compare cost per accepted outcome against the original setup. Keep the change only if quality holds and the full cost improves.
Then review the workflow weekly for the top cost drivers and monthly for ROI. Retire or redesign an agent that cannot clear the value threshold after a fair attempt at improvement. Continuing to feed credits into a poor-fit automation is not experimentation; it is unmanaged spend.
Use this closing checklist
- Do we have a clear, pass/fail definition of an accepted outcome?
- Do we count failed attempts, retries, tools, and human correction in the total cost?
- Do we know our cost per accepted outcome, not just cost per run?
- Does each task type have a dollar, step, tool, and retry cap?
- Do we stop or escalate when the budget is reached?
- Are we testing cheaper models and caching against the same quality bar?
- Can we show credible value that exceeds the full workflow cost?
Start with one agent and one week of honest data. You do not need perfect telemetry to uncover the obvious waste. You need a definition of useful work, a record of what every attempt costs, and the willingness to stop paying for outcomes nobody accepts.