Agents propose, deterministic code executes
The rule I run teams by, and how it survived 14,000 real messages before a launch.
The rule
An agent may read, reason, draft and propose. It may not touch a customer, a contract or money. Anything that changes the world is executed by code that a person wrote, tested and can read line by line. The agent's output is an input to that code, never a bypass of it.
This sounds conservative. In practice it is what lets a small team ship agents into a business at all. The language model is the most capable and the least predictable component in the system. You put it where capability matters and predictability does not, and you put deterministic code everywhere else.
How it looked in production
This summer I designed the operations layer of a company that manages hundreds of buildings and thousands of residents. Every request that reaches it, by email or chat, is read by an agent that classifies it, extracts what matters and proposes an action. The action goes through a gate of 24 rules. Some rules are about safety, some about money, some about tone. If the proposal passes, deterministic code carries it out. If it fails, a person sees it with the reasoning attached.
Before launch we replayed 14,000 real messages from the company's history against 124 cases that people had labelled by hand. Not a demo set. The ugly set, with the angry tenant, the ambiguous invoice and the request in two languages. The agent reached 94 to 96 percent action accuracy on those cases, and more important, the gate caught the rest. Nothing executed that a person would not have signed.
What the rule buys you
- A place to put the evaluation set. The gate is testable code. The agent's job is to feed it well.
- A clear answer to "what if the model is wrong". It proposes. Wrong proposals cost a review, not a refund.
- A way to grow trust in steps. Widen what the gate allows as the evidence comes in, one rule at a time.
- A conversation the business can follow. Nobody has to understand the model to understand the rules.
The third clause
I have started writing the rule with a third clause: a person owns the decision. Not a person in the loop for every message, that does not scale. A person who owns the rules, reads the failures, and decides what the system is allowed to do next. In every team I have led that worked, that person was named. In every system I have seen fail, they were not.