"That's not what I meant" is about as old as written instructions. Around 93 BC a Roman court spent a whole case on a will whose words said one thing while its author plainly meant another. Agents bring that complaint into every job where a person makes a judgment call, and they act in seconds.

Last month I wrote about closing the agentic value gap and promised that data egress would come next. I'm taking approvals first, because agents are already moving into seats people hold today: the clerk who pays invoices, the analyst who clears an alert, the adjuster who settles a claim. Whether that's safe has less to do with how smart the model is than with how well we design the places where a person still says yes. I call that design legible friction. It means adding friction on purpose, which runs against what we usually try to do in any system, so it has to earn its place by teaching the system where it can do without it.

What the person in the seat was really doing

A person in a judgment role does more than decide. They notice when a request doesn't match what the requester meant, they turn away a convincing stranger, and their name is on the result. An agent takes the decision, but none of those three jobs come with it.

The first gets harder, because an agent answers fluently and can make a confident case for the wrong action. The second is new in kind: anything the agent reads while it works — an email, a web page, another agent's output — can carry instructions meant for it. The third doesn't move at all. Nobody can hold an agent responsible, so the responsibility stays with whoever said yes, and that yes has to mean something.

What legible friction means

Unlike the Roman testator, the person who asked an agent is still around, so the two of them can settle intent before anything happens instead of arguing over it afterward. The friction is a stop someone puts on purpose in front of a decision that matters. It's legible when a person can read it in a few seconds and trust what they're agreeing to. That takes five things:

  • It shows the real thing, fully resolved — the actual payee, the amount, the account, the recipient list, the diff — never the agent's description of it.
  • It says in plain words what the yes will do.
  • The yes covers exactly what the person saw. If anything changes afterward, it doesn't run.
  • The agent can't draw the screen or route around it, and no yes means no action.
  • It's rare enough that people still read it.

I learned this the hard way. In July I moved my own signing key onto a YubiKey, and the first approval window asked for my PIN without showing what I was signing. I caught it. The key proved I was present, not that I had read the change and agreed to it. Presence is not consent. The fixed window shows the full task, a checksum of its exact bytes, and one plain sentence about what my signature authorizes, drawn by a program the agent can't touch.

How to apply it

Take one role: an agent doing accounts payable. It reads invoices, matches them to purchase orders, and pays vendors. Most of that work is routine, and some of it is exactly where fraud lives. Legible friction here isn't one checkpoint. It's several kinds of stop, each placed where the consequence calls for it.

Let rules take the clear cases. Matching an invoice to a purchase order and a receipt is a rule, so code should handle it without asking anyone. Google's SRE book has the test for pages, and it fits approvals: "If a page merely merits a robotic response, it shouldn't be a page."

Scale the stop to the consequence. Banks already give people authority limits. Give the agent one too. It can pay a matched invoice under a set amount on its own, and anything above that stops for a person, who sees the exact payment before signing.

Put two people where one person could get fooled. A request to change a vendor's bank account is a well-worn fraud move, and it usually arrives as a convincing email. That change needs a person to verify it outside the email and a second person to approve it, the same maker-checker banks already run. The agent can be the maker, never the checker.

Leave a window to cancel. Payments the agent releases on its own can sit in a short hold before they go out, with a person able to see the queue and pull one back. That stop blocks nothing; it gives a person time to catch a mistake.

Review behind the reversible work. For work that's cheap to undo, the friction can come after: someone reviews a weekly sample of what the agent did.

Plan for the bumps

None of this catches everything. Rules have gaps, people approve things they shouldn't, and an agent working at speed can repeat one mistake many times before anyone looks.

That problem has an old story too. Lucian wrote the first sorcerer's apprentice around AD 150, long before Disney made it famous. The apprentice knows enough to set a pestle hauling water and not enough to stop it, and when he splits it with an axe, he gets two. Every agent in a judgment seat needs a way to halt the whole run, and someone whose job includes pulling it. Unlike the axe, the halt shouldn't make things worse; it should freeze the agent's queue, not leave work half done.

Friction has to pay for itself

Stops have a real cost. I've watched approval fatigue set in, and I've watched noisy alerts train an SRE to tune out their own monitors. A gate that always gets a yes teaches people to stop reading, and then the signature means nothing. Friction that never changes only gets more expensive.

It pays for itself by teaching. Every stop records whether a person and the agent agreed, and that record is worth keeping. In the payables example the loop looks like this:

  • Record every decision. Each stop logs what the person did: approved, rejected, or changed, and exactly what they changed.
  • Review the record on a schedule. Once a week, someone looks at each gate: where people always say yes, where they say no, and where they keep fixing the same field.
  • Turn a predictable yes into a rule. If matched invoices from long-standing vendors in a given range go through untouched for a quarter, and a wrong payment there would be small and recoverable, raise the agent's limit for that case and retire the stop.
  • Fix what the rejections point at. A run of rejections usually means the agent's instructions, its data, or an upstream rule is wrong. Fix that, and keep the stop until the rejections stop.
  • Keep what the edits teach. When a person changes the cost center on every invoice from one vendor, they're writing down what they meant. Make it a rule, and the agent stops guessing.
  • Let the loop run both ways. When the weekly sample finds errors, or a near miss gets through, add a stop or lower the limit.

Model training already works this way. Nobody ships a model on faith. You run it against cases with known right answers, score it, change something, and run the cases again. Those evals are how a model gets better and how anyone can show that it did. What we're doing here is the same discipline, pointed at a business process instead of a model. Every approval, rejection, and edit at a stop is a case where a person wrote down the right answer for this company, and the weekly review is the scoring run.

Three things differ. Training improves the model; here the model stays put and the process learns — its rules, its limits, which cases reach a person. Training evals run before release on picked cases; stops run on real work and hold the action, so they protect while they measure. And an eval asks whether a model is good in general, while a stop asks whether this payment is what this company meant today.

Each of those changes is a decision someone owns and records, the way a bank records a change to anyone's authority limit, and it can be undone if errors come back. It's never a reward for the agent behaving well for a while.

That is the payment for the friction. The stops you add on the first day show you which ones you can retire later, and the total friction goes down while the judgment that's left gets sharper.

Using the legible friction approach, the person doesn't leave the role. They move to the few stops that still need judgment and to the weekly review, and the rest of the role becomes code they can read.

Put a stop in front of anything that can't be taken back. Make it legible: the real thing, in plain words, bound to exactly what the person saw, out of the agent's reach, and rare enough to read. Then let every answer at that stop teach the process, until the only stops left are the ones that truly need a person. That is how an agent earns a judgment seat, and how you avoid hearing "that's not what I meant" after the money has moved.

Next: egress

I promised a post on egress last month, and it's coming next. Egress is data leaving your systems, and it's the one risk a stop can't catch on its own, because it never asks for a yes. An agent that only reads can still send your data out in a single web request, with no send button and no approval screen in the way. The next post is about stopping that leak without cutting the agent off from the information it needs to work.

If your approvals have gone sideways in a way I haven't covered, please, let me know.