What Can an Agent Do Without Oversight

The "classify by risk" framework sounds like a method. In practice nobody in the room can apply it to a real case until it has already gone wrong.

Carlos Andrés Ramírez · 2026-08-23

Every governance framework says the same thing: classify by risk level, and whatever counts as low risk gets decided by the agent alone. It sounds like a method. Put a real case in front of any committee, a refund that doesn't fit any category, an exception nobody planned for, and nobody can say, right there, in that moment, whether it was low risk or high.

The word "risk" isn't the problem. The problem is that nobody has brought it down to something you can check against an actual case without a half hour debate. And until that translation exists, the criterion doesn't live in a document. It lives in whoever happens to be on call that day, and it changes depending on who that is.

The result is two different organisations living inside the same company. One where the agent decides too much, because nobody dared rein it in on time, and the first incident forces a sudden pullback, usually of more autonomy than it ever should have had. And one where the agent decides nothing alone, because every doubt gets escalated, and the project meant to save time adds a queue instead.

The symptom

The cutoff doesn't exist until it's needed.

It shows up before anything serious happens. An agent that processes refunds is cleared for "low amounts", and nobody has written the number down. Someone sets it in a meeting, from memory, and it never gets revisited even as the business changes size. Reversibility, whether the decision can be undone without harm, doesn't even come up: everyone assumes anything low value an agent does is reversible, and it isn't always.

• The autonomy limit is a number someone remembers, not one written anywhere that can be audited.
• Nobody separates a reversible decision from one that isn't; only the amount gets checked, and a low amount can still be irreversible.
• The perimeter widens in practice before it does on paper: someone stretches it "just this once", and that once becomes the norm.
• The first sign an agent stepped outside its perimeter is a customer complaint, not an internal alert.
• Every team running a different agent has its own unwritten rule, so the same question gets answered differently depending on who you ask.

The problem underneath

The cutoff isn't risk. It's three variables, and none of them is a gut feeling.

Risk is a word that works on a slide and does nothing for a decision at three in the afternoon. What actually decides a case is three things you can check and measure: how much money the decision moves, whether it can be undone without harm once it's made, and how many people it affects if it goes wrong. An agent approving a low value, reversible refund that affects one person doesn't need the same cutoff as one cancelling a contract. Same "low risk" on the slide, completely different cutoff in reality.

A committee that says "we classify by risk" and can't apply it to a real case in under a minute doesn't have a criterion. It has a word it uses to feel comfortable.

BECOME

What has to be written

Four pieces, before an agent gets any autonomy.

Cutoff

An explicit number or rule per variable: a maximum amount, what counts as reversible in that process, how many people a single decision can affect. Not a risk level with a name. Three figures.

Authority to expand

Who can move the perimeter, and with what evidence. If anyone can stretch it "just this once" without leaving a trace, the written perimeter is worth nothing.

Detection

How you know the agent stepped outside its perimeter without waiting for the customer complaint. An alert when it approaches the limit, not a report read after the incident.

Review

How often the cutoff gets checked against real operating data, not against a sense that "it's going fine". The business changes size, and the number set at the start stops working.

None of the four needs more model or more engineering. It needs someone with authority over the process to sit down and write them before the agent makes its first decision, not after the first one that went wrong.

Take the process where you already have an agent running and ask whoever operates it, without looking at the code: what happens if a case comes in tomorrow at twice the amount you're letting it clear alone? If the answer is "I don't know" or "the team would catch it", that's the gap. And it isn't the model's fault.

Let's define your agent's cutoff