What agents should never do alone.

The question we hear most from operations leads is not “can the agent do this?”. It is “what stops it doing something stupid?”. The honest answer is not a better prompt. It is a short list of rules, written by the people who own the risk, that the agent cannot talk its way around.

Writing those rules is less work than it sounds. Almost everything that should stay with a person falls into three kinds of decision.

Three kinds of decisions

Money. Refunds, credits, discounts, prices, payments. Anything that moves money in or out of the business, or changes what a customer pays.

Promises. A delivery date, a replacement, an exception to the policy, anything that commits the company to a customer or a supplier. A wrong answer is fixable. A wrong promise has to be honoured or broken.

Anything you can’t undo. Deleting records, sending to your whole customer base, cancelling or changing an order that is already moving. If the mistake cannot be reversed by clicking something, a person decides.

Everything else, like reading, classifying, drafting, looking up, summarising and routing, is usually safe for an agent to do alone, provided it is visible afterwards.

Draft, then apply

The most useful distinction in approval rules is between preparing an action and executing it. An agent can do all the work of a refund: find the order, check the policy, calculate the amount, write the reply. Then it stops, and a person applies it with one tap.

This keeps most of the time saving and almost none of the risk. The person is not doing the work. They are checking a finished proposal, with the order, the policy and the amount on one screen.

Over time, some drafts earn the right to apply themselves. When a person has approved the same kind of action enough times without changes, you can move it below the threshold. That is a decision for the team that owns it, not for the agent.

Thresholds, not feelings

“Ask me when it’s important” is not a rule. An agent cannot know what feels important to you. A rule needs a number, a category or a list:

• A number. Refunds up to a limit are applied; above it, they go to the ops lead.
• A category. Any change to a contract goes to legal, whatever the value.
• A list. New suppliers, key accounts and anything to the press always go to a person.

Every rule names who decides and where they are asked: in Slack, Teams or email, wherever that person already works. A rule that sends approvals to a dashboard nobody opens is a rule that stops the business.

A worked example

This is the shape of a rule set for an online store’s support and commerce agents. The limits are yours to set; the structure is what matters.

Start with the right-hand column. The right-hand column is the list of things your team has decided to keep. Everything to its left is work they no longer have to do.

If you can’t undo it, a person does it.

The veto that isn’t a model

Some rules are too important to leave to a language model, even one that is being checked. Margin is the clearest case.

In the marketplace system we built, no agent ever writes a price. Agents can propose a discount or a clearance offer, but every proposal passes through a margin guardrail first. The guardrail is plain code, not a model. It calculates the floor for that product after returns, fees and shipping, and anything below it is vetoed. There is nothing to persuade and no prompt to get wrong.

That is the pattern we use wherever a rule can be expressed as arithmetic or a lookup. The model proposes, deterministic code checks, and a person approves what the rules say a person approves. Each layer does the thing it is good at, and none of them is asked to be the last line of defence alone.