Approval is an interface, not an interruption.

Every agent system eventually reaches the same moment. The model has reasoned its way to an action that matters — sending a message, spending money, changing a production system, deleting something that cannot come back — and the question is no longer can it do this but should it do this now, on whose authority.

Most agent demos skip that moment. Most production systems handle it badly. We think it is the most important interface in the whole stack, and we design it that way.

The two failure modes

There are two common ways to get approval wrong, and they fail in opposite directions.

The first is the confirm-everything agent. Every file read, every search, every draft triggers a prompt. It feels safe. In practice it trains the person on the other side to click "yes" without reading, which means the one prompt that actually matters gets the same reflexive click as the forty that did not. Volume destroys signal.

The second is the trust-the-model agent. Approvals exist, but they are a single global toggle, or they are enforced by a line in the system prompt asking the model to "check with the user first." That is not a control. A model that is confidently wrong, or that has read a document instructing it to act, will route straight past an instruction it was merely asked to follow.

Both failures come from the same mistake: treating approval as an interruption to the real work rather than as part of the work.

Approval belongs to the action, not the agent

The first design decision is where the gate lives. We put it on the action, not on the agent or the conversation.

Reading a file, searching, drafting, running a build in a sandbox — these are reversible, and they stay inside the boundary of the system. They should flow without friction. Sending an email, posting to a channel, pushing to a production branch, purchasing, deleting or sharing anything outside the boundary — these are irreversible or externally visible. They pass through a gate every time, regardless of how confident the model is or how routine the request looks.

That classification is declared alongside the tool itself, not inferred at runtime from the model's own description of what it is about to do. The harness enforces it. The model can ask for an action; it cannot grant itself one.

A good approval request is a complete diff

The second decision is what the human actually sees. A prompt that says "The agent wants to send an email. Allow?" is asking for blind trust with extra steps.

A useful approval request is a complete, concrete proposal:

• Exactly what will happen. The recipient, the subject, the full body. The branch, the files, the diff. The amount and the payee.
• Why the agent thinks it should happen. The request or context that led here, in a sentence.
• What is reversible. Whether this can be undone, and how.
• Where the content came from. If any part of the action was shaped by external content — a web page, an inbound email, a document — that provenance is visible.

The goal is that a person can make a real decision in a few seconds, because everything they need is on one card. If the request cannot be summarized that way, the agent has not finished its work yet.

Do all the reversible work first

This leads to a pattern we use everywhere: the agent does every reversible step before it asks.

It drafts the message instead of asking whether it may write one. It builds and tests the change on a branch instead of asking whether it may start. It prepares the purchase, compares the options, and stops at checkout. By the time a human is asked anything, the only remaining question is the irreversible one — and the answer is a single decision, not a conversation.

This is also where approval stops feeling like friction. The agent is not waiting on a person to make progress; it has made all the progress it safely can and is handing over a finished proposal.

Untrusted content never grants permission

Agents read the world, and the world contains instructions. A support ticket, a scraped page, or a forwarded email can all contain text that looks like a command. Our rule is simple: content the agent reads is data, never authority.

If an inbound document asks the agent to forward a file, reset a password, or contact someone, that request is surfaced to the human as a finding — not executed. Permission comes from the person the agent works for, explicitly, for a specific action. A task description, a memory note, or a convincing paragraph in a PDF is not permission.

Declines are final

A declined approval is an answer, not an obstacle. The agent does not retry the same action through a different tool, rephrase it to look smaller, or split it into pieces that each slip under the threshold. It reports what it wanted to do, why it stopped, and what it would need to proceed.

This matters more than it sounds. The value of a gate is entirely in its reliability. A gate that a sufficiently persistent agent can route around is not a gate.

Why this survives the next model

We treat model providers as interchangeable. The model behind a workflow will change — often — and every change shifts behavior in ways no one fully predicts. Governance that lives inside a prompt changes with it.

Governance that lives in the harness does not. The action classification, the approval surface, the provenance rules, and the audit trail are properties of the operating layer, not of any particular model. Swap the model and the gates hold, because they were never the model's to hold.

That is the broader point. Capability is getting cheaper every quarter. What stays scarce is the confidence to let a system act — and that confidence is built at the approval gate, one well-designed decision at a time.