Agent, Workflow, or Single Call? How Much Autonomy to Give the Model

Autonomy is a budget you spend, not a feature you add. Give the model the least autonomy that solves the problem.

This post is the decision companion to Tool Calling & Agentic Workflows, which teaches how to build the agent loop itself. Read that one to build; read this one to decide whether to build, and how much autonomy to grant. It also builds on RAG vs Fine-Tuning vs Prompt Engineering (choosing the right technique), Guardrails, Approvals & Audit (approvals before side effects), and Evals & Tracing (measuring instead of guessing).

1. Autonomy, in plain language

Autonomy means: how many decisions the system makes on its own before a human sees them. A system with no autonomy makes no decisions — it follows a script you wrote. A system with high autonomy makes dozens of small decisions you never see: which tool to call, what the tool output means, whether it is done. Everything in this post is about choosing that number deliberately, instead of letting it default to “as much as possible.”

“Agent” gets used for everything from a single chatbot reply to a team of models running a department. That vagueness is the trap: if you cannot name which level of autonomy you mean, you cannot reason about its cost or its failure modes. Here are the four levels, in order of increasing autonomy.

The key insight is what actually changes as you move right: decision rights move from you to the model. At the left end, every decision is yours and the model is a calculator. At the right end, the model makes dozens of small decisions you never see. Each transfer buys flexibility and sells debuggability. When something goes wrong at the left end, you read the prompt. When something goes wrong at the right end, you reconstruct a trajectory.

2. Four architectures, one picture

Beginners need to see where the model, the application code, the tools, and the human approvals sit. Here is the same dispute handled four ways, as architecture:

• Single call: documents go in, a draft comes out. Nothing else runs. The human is the entire quality system.
• Workflow: application code controls the order. Each step is known in advance, and a failure stops at a step you can name.
• Agent loop: the model chooses the next permitted step, and code enforces the limits — budgets, allowed tools, and approval gates. The loop is the model’s; the guardrails are yours.
• Multi-agent: multiple model-driven roles coordinate under an orchestrator. The handoffs between roles are the new failure surface.

3. The worked example: calculating the $440 discrepancy

Take one concrete case and run it through all four levels. A supplier invoice claims 400 units delivered at $12.50 each. The receiving log shows 380 units, and the contract price changed to $12.00 last month. Work the arithmetic exactly, because this post teaches readers to use AI systems for invoice reconciliation — and the worked example must be right.

One valid breakdown of that $440:

• 20 undelivered units × $12.50 = $250
• 380 received units × $0.50 overcharge = $190
• $250 + $190 = $440

One more distinction matters before anything is finalized: a proposed discrepancy is not an approved credit. The $440 is what the arithmetic says. Before it becomes money, three things must be verified: the contract amendment’s effective date (was $12.00 actually in effect for this delivery?), the receiving evidence (is the 380 count confirmed, or is it itself disputed?), and existing credits (has part of this already been credited?). The approved credit may be less than $440 — and any system that skips those checks is not resolving disputes, it is manufacturing them.

4. One dispute, four approaches

Notice that the outcome is the same in all four rows: a resolved or escalated dispute with evidence. What differs is who owned the path, how much it cost, and how hard it is to explain afterward. That is the whole decision in one table.

5. Why deterministic code still matters

Here is the principle beginners most often miss: an AI agent does not need to perform every step itself. Even in an agentic architecture, the steps that must be exact, permissioned, or financially binding should stay in deterministic, auditable systems. The model reasons where reasoning helps; code decides where correctness matters.

Read that table as an architecture rule: the model should touch the steps where judgment is the bottleneck, and stay away from the steps where exactness is the requirement. An agent that computes money in prose is a bug waiting for an auditor. An agent that drafts the explanation of a discrepancy computed by code is a genuinely useful colleague.

6. Memory: three separate concepts

People choose agents for flexibility and then discover the real architectural question was memory. But memory is not one thing, and it is not a property of the architecture — it is an application design decision. A deterministic workflow can store past dispute history. An agent can be stateless between runs. A single LLM call can receive previously retrieved history as context. Teach three separate concepts:

• Context is information supplied to the model for the current call: the invoice, the log, the contract excerpt, and any history you choose to include. Every level has it. It is also the most expensive memory, because it is re-read (and re-paid for) on every call.
• Durable state is records, checkpoints, and outcomes stored by the application: past disputes, their resolutions, and what was approved. Any architecture can keep it; the question is what you store and who can change it.
• Retrievable knowledge is policies, contracts, and historical records fetched when needed. This is where RAG Systems End-to-End earns its keep — an agent that cannot retrieve the current contract price will confidently resolve disputes against last year’s price.

Whatever you store, stored facts need four disciplines:

• Provenance: where did this fact come from — a verified contract, or a supplier email?
• Access controls: who can read it, and who can write or change it?
• Retention rules: how long does it live, and when is it deleted?
• Freshness checks: is it still true? A policy remembered from last quarter, applied with full confidence today, is the stale-memory failure. A supplier claim stored as fact and reused in later runs is the poisoned-memory failure — untrusted content treated as authority. See Guardrails, Approvals & Audit.

The practical rule: persist as little as possible, and version what you persist. If a workflow solves the problem without durable memory, that is not a limitation — it is one fewer failure mode.

7. How each level breaks

8. Choose with an eval, not an opinion

The RAG post’s rule applies here word for word: test, don’t assume. Before granting autonomy, run the same cases through the levels you are choosing between and measure what actually differs. The table below is illustrative — a teaching example showing the shape of such an eval, not measured results. A real pilot needs a held-out case set, ambiguous cases, and refusal/uncertain cases scored explicitly, not just the easy wins.

First, define the metrics so the categories cannot overlap. Every case lands in exactly one of three buckets: correctly resolved without human help, incorrectly resolved, or escalated to a human. The three buckets sum to 30 in every column. “Human interventions” is then derived, not separately counted: escalations plus incorrect resolutions that a human had to fix. The safety rows below are subsets or separate events, and are labeled as such.

Read that table the way a buyer should, not the way a vendor would. The agent correctly resolves the most cases (25) and recovers best from messy documents (9) — and costs roughly four times as much per case, with the worst p95 latency and one unauthorized side-effect attempt that only the approval gate caught. Whether that trade is good depends on what a human hour costs you and what an incorrect resolution costs you. But one thing is not a trade at all: an incorrect resolution is never acceptable simply because human hours are expensive. Financial actions get hard safety gates — verification plus approval, every time — regardless of what the averages say. Some actions are not cost-benefit decisions; they are boundaries.

9. The approval boundary, concretely

“Human in the loop” is too vague for financial work. Here is what the boundary actually looks like. The agent proposes — it never executes:

{
  "invoice_id": "INV-1042",
  "proposed_dispute_amount": 440.00,
  "currency": "USD",
  "reason": "Quantity and contract-price mismatch",
  "action": "DRAFT_DISPUTE",
  "requires_approval": true
}

The full boundary, in order:

1. The agent proposes the action. The proposal above is the most it can do on its own.
2. Application code independently verifies the amount and supporting records. It recomputes the $440 from the invoice, the receiving log, and the current contract — it does not trust the agent’s arithmetic.
3. An authorized reviewer approves the exact proposed action. Not “approve disputes in general” — this invoice, this amount, this action.
4. The system checks that the approved payload has not changed. If anything differs between approval and execution, execution stops.
5. An authorized service executes the approved action once and records the outcome. Once, not retry-until-it-works. The record is what makes the whole thing auditable.

Notice what this protects: the agent’s judgment is used where it helps (interpreting the mess), and it is fenced off from where it harms (moving money). That fence — proposal, independent verification, exact approval, unchanged payload, single audited execution — is the difference between “we have a human in the loop” and “we can prove what happened.”

10. The decision sequence

The old flowchart was too decisive: a task needing tools does not automatically need an agent — a fixed workflow can call APIs, and a single model call can use pre-fetched data. Ask in this order, and stop at the first “yes”:

Two exits deserve emphasis. First, “workflow + human checkpoints” is not a compromise for the timid — it is the right answer for most money-moving work, because it keeps the model’s flexibility inside a path a human can audit. Second, the multi-agent exit requires proof: an eval showing that one agent measurably fails where two succeed. “It feels more scalable” is not proof.

11. When not to build an agent

12. Production details, in one place

If the sequence lands you on the agent loop, these are the non-negotiables — each one links to the lesson that teaches it properly:

• Approvals before side effects. No agent sends, pays, or commits without a human-approved action snapshot. See Guardrails, Approvals & Audit.
• Budgets, timeouts, dry-run. Cap steps and cost per run, bound every tool call, and preview destructive actions before executing them. See Tool Calling & Agentic Workflows.
• Audit everything. Log the trajectory — every tool call, every observation, every decision — or you cannot debug, explain, or defend a single run. See Evals & Tracing.
• Facts come from retrieval, not memory. Contract prices, policies, and supplier histories are reads from a current source, not things the model remembers. See RAG Systems End-to-End and RAG vs Fine-Tuning vs Prompt Engineering.
• Structured output at every boundary. Tool arguments, verdicts, and handoffs are schemas, not prose. See Structured Output: JSON You Can Trust and Calling LLM APIs in Production.
• Version the system, not just the prompt. Tools, prompts, and retrieval sources change independently — record all three per run, or your evals stop being comparable.

13. The principle

Every lesson on this site carries one principle. This one’s is the lede, because it is the whole post in a sentence:

Give the model the least autonomy that solves the problem. Autonomy is not a virtue. It is a budget: you spend it where variation demands it, and you save it everywhere else, because every unit of autonomy you grant is a unit of debuggability you surrender.

Try it yourself

Before reading the worked solution, try this one on your own. A second supplier invoice claims 250 units at $9.80 each. The receiving log shows 240 units, and the contract price is $9.50. Your tasks:

1. Calculate the discrepancy, with the breakdown.
2. Select an architecture from section 1, and justify the choice.
3. Identify the approval boundary: what gets proposed, verified, approved, and executed — and by whom.