How Much Agency Does a Returns Bot Earn?

A retailer comes to us with a familiar ask: customers should be able to open a chat, say "I want to return my order," and have the whole thing handled — look up the order, check whether it's eligible, generate a shipping label, and issue the refund. The word in the brief is agent. The instinct in the room is a chatbot with the run of the tools, reasoning its way through each case.

The Principle of Least Agency says don't start there. Start at the bottom of the spectrum and make each feature earn its way up. So instead of designing one autonomous system, we break the flow into its actual requirements and ask, of each one, the only question that matters: what here forces more agency?

01Break the flow into requirements

"Handle a return" is not one task — it's seven, and they don't sit at the same place on the spectrum. Laid out plainly:

1. Understand what the customer wants. Free-text, messy, often more than one intent per message.
2. Look up the order. Take an order number (or find it from the account) and fetch its record.
3. Check return eligibility. Apply the written policy: within the window, eligible category, acceptable condition.
4. Answer policy questions. "How long do refunds take?" "Can I exchange instead?" — grounded in the help centre.
5. Generate the return label. Create an RMA and a prepaid shipping label.
6. Issue the refund. Move money back to the customer's card.
7. Handle exceptions. Out-of-policy pleas, damaged goods, "this isn't what I ordered," angry escalations.

Now score each one against the criteria that actually move a task along the spectrum: does it take open-ended input? does it require genuine judgment a rule can't encode? is it reversible if it goes wrong — or is it a one-way door? The checkboxes fall out of the requirements, and the earned level falls out of the checkboxes.

02Read the checkboxes

The pattern is hard to miss once it's on the page. Five of the seven requirements have no judgment box checked at all. Looking up an order, checking it against a written policy, cutting a label — these are deterministic every time, and being right the same way every time is the whole point. They are rules. Dressing them up as agent behaviour would only add cost and a way to be wrong.

Two requirements do earn a model. Understanding a free-text request and answering policy questions both check open-ended input — you cannot enumerate everything a customer might type. That earns a language model: one to read intent, one to answer from the help centre with retrieval. But notice what they don't check. Neither makes an irreversible decision. The model interprets and drafts; it doesn't act. That caps them at Assisted, not an autonomous agent.

03Where the human gate goes

Refunds are the high-stakes, irreversible step, so that is where control stays. But "a human approves every refund" would defeat the point of automating at all. The answer is a deterministic gate, not a smarter model:

• Inside policy, under a threshold — order found, within the window, eligible category, amount below a set limit — the refund is auto-approved by a rule. No model judgment touches the money.
• Anything else — over the threshold, out of policy, a flagged account, a damage claim — routes to an agent (the human kind) with the full context and a drafted recommendation waiting.

That is Least Agency in one design decision: the model never decides to move money. It reads, it explains, it prepares. A rule releases the reversible refunds; a person owns the rest. The bias and variance of a model stay well clear of the irreversible act.

04What we actually built

Add the earned levels back up and the "autonomous returns agent" resolves into something calmer and cheaper:

• A thin language layer — one model to classify intent, one retrieval-grounded responder for policy questions. This is the only place non-determinism lives, and it never acts on its own.
• A deterministic core — order lookup, eligibility, RMA and label generation, and the refund threshold rule. Testable, auditable, effectively free to run, and identical every time.
• One human gate — on out-of-policy and above-threshold refunds and on genuine exceptions, with the model drafting the recommendation so the human moves fast.

On the spectrum, the whole system tops out at Orchestrated: a fixed workflow that occasionally lets a constrained model read or draft, with a human on the one-way door. No planner improvising across tools. No multi-agent swarm. And it handles the overwhelming majority of returns end-to-end without a person — because those returns were always deterministic. We didn't make the system less capable. We stopped paying for capability the requirements never asked for.

The brief said "build an agent." The requirements said "build five rules, two assistants, and one gate." We shipped what the requirements said.

05The scorecard, to borrow

You can run this on any workflow before you write a line of it. For each requirement, tick the boxes and read the level off the pattern:

1. List the real sub-tasks. "Handle a return" hides seven. Break the brief until each item does one thing.
2. Tick four boxes. Open-ended input? Needs judgment a rule can't encode? Reversible if wrong? Should a human gate it?
3. No judgment box ticked → it's a rule. Keep it deterministic and move on. Most of the system lives here.
4. Judgment ticked, but nothing irreversible → Assisted. Let the model read, draft, and suggest. Don't let it act.
5. Irreversible or high-stakes ticked → put a gate on it. A rule or a human owns that step, whatever the rest earned.

The autonomous system you didn't build is the one that would have surprised you in production. Read the checkboxes first, and let the requirements — not the brief's vocabulary — decide the flame.