Agents Get Expensive the Third Time They Redo the Same Job

AI agents do not become expensive only because usage is metered. They become expensive when the same job loops: reread the context, check the work, miss the acceptance test, ask a human, rerun, and still need cleanup. The operator answer is not to buy a bigger agent promise; it is to install a narrow workflow with a cost ceiling and a clear handoff.

The real agent KPI is cost per completed task. Not cost per message. Not cost per run. Not how impressive the demo looked. Completed work is the only unit that matters.

The real KPI is cost per completed task

Cost per completed task measures the full operating cost of getting one usable output through review and into the next step. It includes the agent run, repeated attempts, human review, rework, failed runs, and escalation.

This matters because an agent can look cheap at the single-run level and expensive at the workflow level. A draft that takes little effort to generate but needs three reruns, two clarifying messages, and a manager rewrite is not cheap. It is a disguised coordination cost.

Use this operating formula:

Cost per completed task = (agent run cost + human review cost + rework cost + failed-run cost) / accepted outputs

The exact cost inputs will vary by company. Some teams can use billing exports. Others will begin with rough estimates for review time, reruns, and rework. Precision is useful later. Visibility is useful now.

For example, imagine an agent that prepares a customer complaint summary. The first draft is not the task. The completed task is a reviewed packet that includes the customer issue, relevant account context, policy references, recommended response options, and a clear human approval point. If the agent produces a polished paragraph but misses the policy reference, the task is incomplete.

The practical takeaway: stop evaluating agents by output quality alone. Evaluate them by accepted output per operating cost.

Why agent demos hide the loop tax

A demo usually shows the happy path. Production work exposes the loop tax.

The loop tax appears when the agent repeats expensive steps because the workflow was not designed tightly enough. It reads too much context. It checks vague criteria. It takes action before the human has approved the risk. It cannot tell when to stop. Each loop looks harmless in isolation. Together, they turn a small automation into a noisy process that nobody trusts.

The common loops are easy to spot:

• Context loops: the agent keeps rereading long documents because the input was never packaged into a usable context pack.
• Decision loops: the agent cannot choose the next step because the trigger and allowed actions are vague.
• Quality loops: the output fails review because the acceptance test was not written before the run.
• Escalation loops: the agent keeps trying to solve a task that should have been handed to a human.
• Trust loops: the human reviewer checks everything from scratch because the output does not show its sources, assumptions, or limits.

That last loop is the quiet killer. If the reviewer has to reconstruct the entire job to trust the output, the agent did not save operational effort. It moved the work to verification.

Impressive is easy. Reliable is the work.

If you want agent economics to improve, design the loop before you design the agent. This is basic Business Systems & Operations: define the handoff, the pass condition, and the stop condition before you add automation.

The useful middle ground is a narrow, metered workflow

The best starting point is not a broad AI employee. It is also not random prompting by whoever has a task. The useful middle is a narrow workflow that can be measured.

A metered agent workflow has five parts:

1. Trigger: the exact condition that starts the run.
2. Context pack: the minimum set of documents, fields, examples, and rules needed to complete the task.
3. Acceptance test: the checklist the output must pass before it is considered complete.
4. Escalation rule: the condition that forces human review or stops the run.
5. Cost ceiling: the maximum allowed attempts, tool calls, retrieval steps, or estimated spend before the run stops.

This structure keeps the agent from behaving like an open-ended intern with infinite patience and no budget. The agent gets a defined job, a defined input, a defined finish line, and a defined point where it must stop.

For sensitive or high-impact work, keep one boundary firm: the agent drafts and organizes only. It does not send, file, submit, pay, sign, or make the final decision. That boundary is not a weakness. It is what makes the workflow safe enough to test around messy documents, customer issues, money, legal exposure, or health-related information.

Before private data enters any AI workflow, check permissions, remove unnecessary sensitive fields, limit access, and follow company policy. Do not upload confidential customer records, contracts, inboxes, or internal files by default. High-risk outputs need human approval.

The Agent Cost Ledger and Runbook

The Agent Cost Ledger and Runbook is for founders, operators, consultants, agency owners, and technical teams who want to know whether an agent is earning its place in the workflow.

Use it when you are testing a new agent, repairing an expensive one, or deciding whether to scale a workflow beyond a few users. The output should be a repeatable runbook, a ledger of completed and failed runs, and a decision on whether to keep, constrain, redesign, or retire the workflow.

Required inputs

• The recurring task the agent is meant to complete.
• The workflow trigger.
• The context pack contents.
• The acceptance test.
• The escalation rule.
• The cost ceiling.
• A way to record run cost, review effort, reruns, failure modes, and accepted outputs.

Ledger template

Agent Cost Ledger

Task name:
Workflow owner:
Review owner:
Date range:
Trigger:
Context pack version:
Acceptance test version:
Cost ceiling:

Run record fields:
- Run ID
- Date
- Trigger source
- Input size or document count
- AI tool or model used
- Estimated run cost or billing reference
- Number of attempts
- Human review required: yes/no
- Review notes
- Output accepted: yes/no
- Failure mode
- Escalated: yes/no
- Final handoff destination
- Rework required: none/minor/major

Summary fields:
- Total runs
- Accepted outputs
- Failed outputs
- Escalations
- Repeated failure modes
- Average attempts per accepted output
- Cost per completed task
- Decision: keep, constrain, redesign, or retire

Runbook template

Agent Runbook

1. Purpose
What task does this agent complete?
What business decision or handoff does the output support?

2. Trigger
Start the agent only when this condition is true:

3. Allowed inputs
The agent may read:
The agent may not read:
Sensitive fields to remove or mask:

4. Context pack
Include only:
- Required document or record types
- Relevant policy, rule, or instruction files
- Examples of accepted outputs
- Output template

Do not include:
- Full inboxes unless required
- Unrelated customer records
- Private files that are not needed for the task

5. Agent task
The agent must:
- Organize the input
- Extract relevant facts
- Draft the output packet
- Identify missing information
- Point to source material where possible

The agent must not:
- Send messages
- Submit forms
- Approve payments
- Sign documents
- Make final decisions on high-risk cases

6. Acceptance test
The output is accepted only if it includes:
- Required sections
- Source references or traceable evidence
- Stated assumptions
- Missing information list
- Clear recommendation or next-step options
- Human approval point

7. Escalation rule
Stop and escalate when:
- Required information is missing
- The source material conflicts
- The output affects money, legal exposure, health, safety, or customer trust
- The agent exceeds the cost ceiling
- The same acceptance test fails repeatedly

8. Cost ceiling
Maximum attempts per task:
Maximum tool calls or retrieval steps:
Maximum estimated cost per completed output:
Stop condition if ceiling is reached:

9. Handoff
The final output goes to:
Human reviewer checks:
Approved output moves to:
Rejected output returns to:

10. Ledger update
After each run, record:
- Accepted or rejected
- Failure mode
- Human review notes
- Cost estimate
- Rework required
- Change needed in trigger, context pack, acceptance test, or escalation rule

Quality check

The runbook is ready only if a new team member can run the workflow without asking what counts as done. If the reviewer still says, I need to check everything manually because I do not know what the agent used, the context pack or acceptance test is weak.

Common failure to avoid

Do not let the ledger become a finance-only document. Cost is not just billing. A cheap run that creates review anxiety is expensive. Track failure modes and human handoffs with the same seriousness as usage cost.

A mini-walkthrough: from open-ended agent to metered process

Take a practical example: an agent that prepares a refund review packet for a customer support manager.

The vague version sounds like this: Review this customer issue and tell us what to do. That prompt invites loops. The agent may ask for missing policy context, summarize the wrong messages, ignore order history, or recommend an action it is not authorized to make.

The metered version looks different:

• Trigger: a refund request is flagged for manager review.
• Context pack: the customer message, order summary, refund policy, prior support notes for that case, and the output template. Unrelated account data is excluded.
• Agent task: create a review packet, not a final decision.
• Acceptance test: the packet includes the customer claim, order facts, relevant policy reference, missing information, recommended options, and approval checkbox for the manager.
• Escalation rule: escalate if the policy conflicts with the customer history, the order facts are incomplete, or the case involves a sensitive complaint.
• Cost ceiling: stop after the allowed number of attempts or retrieval steps defined by the owner.
• Output: a reviewable packet that a manager can approve, edit, or reject.

This is where the agent starts to become a system. The work is assisted by AI, but the reliability comes from the surrounding operating design. This is the difference between experimenting with tools and installing AI in Practice.

What to do when the agent keeps failing

Do not respond to repeated failure by giving the agent a broader instruction. Broad instructions usually make loop cost worse.

Fix the smallest broken part of the system. If outputs miss key facts, repair the context pack. If reviewers disagree on quality, rewrite the acceptance test. If the agent keeps attempting risky tasks, tighten the escalation rule. If cost is rising without better accepted outputs, lower the ceiling and reduce the task scope.

Use this decision rule:

• Keep the agent when accepted outputs are consistent, review effort is predictable, and failures are easy to classify.
• Constrain the agent when it completes part of the job but fails near a risky decision point.
• Redesign the workflow when the same failure repeats after the context pack and acceptance test have been clarified.
• Retire the agent when human review remains as heavy as doing the task manually, or when the risk of a wrong output is not acceptable.

A founder may object that this makes agents less autonomous. That is true at first. It is also the point. Autonomy should be earned by stable completion records, not granted because the software can take actions. Let the ledger prove where the agent can safely handle more of the workflow.

How to install this in one week

Do not start with the most dramatic use case. Start with a recurring task where the output can be reviewed before it affects a customer, a payment, or a formal decision.

1. Choose one task: pick a workflow that happens often enough to measure but is narrow enough to define.
2. Write the trigger: make the start condition observable, not subjective.
3. Build the context pack: include only the documents and fields required for the task.
4. Write the acceptance test first: define what a pass looks like before the first run.
5. Set the escalation rule: decide what the agent must not handle alone.
6. Set the cost ceiling: cap attempts, retrieval steps, or spend based on your own tolerance.
7. Run in draft-only mode: the agent prepares outputs but does not send, submit, approve, or execute.
8. Log every run: record accepted outputs, failures, reruns, review notes, and handoffs.
9. Review the ledger: decide whether to keep, constrain, redesign, or retire the workflow.

This is also where a planned prompt library can help once the operating pattern is stable.

The next step is simple: pick one agent or AI-assisted task currently running on trust, create the ledger before the next run, and measure completed work instead of activity. If the agent cannot pass a narrow runbook, it is not ready for a wider role.

Where does your business actually stand?

Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment.