The idea
Every useful autonomous system eventually wants to do something that cannot be undone. Push code. Send an email. Write to a patient record. Charge a card. Delete a file. The model proposing the action can be brilliant and still be wrong, and the cost of wrong is paid once, in the real world.
A prompt that says “be careful” does not change that. A gate does. A gate is a point in the system where an action is held, shown exactly as it will happen, and released only by a person or by a policy the agent cannot edit.
“Anything you actually require must be enforced somewhere the agent’s reasoning cannot reach.”
Five systems, one shape
1. An internal agent harness
Coding agents doing production engineering work. A single policy file is compiled into the permission settings, tool gates and pre-execution hooks of two different agent runtimes. A drift checker spawns the live tool servers and flags any write-shaped tool that is not explicitly denied. The agent may edit code in scope. It may not commit, push, open a pull request or ship a release. Those stay with me.
2. A personal agent harness
chi-harness runs agents across my own tools. Reads flow freely. Writes to systems I own flow. Deletions and anything that leaves the system, such as email, invoices or payments, pause for approval. The approval screen shows the exact tool call, never a summary, because a summary is the model’s opinion of what it is about to do. Once a session reads untrusted content, it can no longer send anything out at all.
3. An AI scribe
In a side project of mine, a scribe drafts documents from a captured conversation. Every field it fills is cited back to the source. Nothing is written to the record until a person confirms and signs. The gate is the product feature, not a setting.
4. An app that agents can use
ChiOS, the app I run my life on, gives agents 200 tools, granted per module and per verb. Its own agent works at an autonomy level I choose. Some actions wait for me at every level: moving money, sending an invoice, deleting, and sharing or sending anything outside the app. That list is written in code, where no prompt can reach it.
5. A desktop file search
Searchlight answers natural-language questions about files using a local model. It is read-only by default. Trashing a file needs a confirm token minted in the interface, so no model output can delete anything on its own.
What the gates have in common
- The gate is law. The prompt is a suggestion. Rules the agent must follow live in code, hooks and permissions, outside its reasoning.
- Show the exact action. Approve the literal tool call, the literal diff, the literal record. Never a paraphrase.
- Choose the failure mode by attendance. An agent with a person watching can stop and ask. An agent running overnight must fail closed, because a question with nobody to answer it is a hang.
- Allow-lists beat deny-lists. When the world changes, a stale allow-list breaks your workflow loudly. A stale deny-list breaks your security silently.
- Precision matters more than recall. A gate that fires on everything gets switched off, and then it protects nothing.
- The gate protects itself. An agent can propose a change to its own policy. It cannot apply one.
“If you replaced the model and the runtime tomorrow morning, what would you want to keep? Everything you would keep is the harness.”
Why it matters now
Models change every quarter. The layer around them does not have to. The tools an agent may call, the actions it must never take alone, the evidence it has to produce before anyone believes it: that layer is where reliability comes from, and it compounds.
This thread goes back further than AI. On a factory floor I learned that the hardest part of automation is knowing what is safe to remove. Gates are the same lesson, applied to software that can act on its own.