An agent I helped ship a while back had an incident on day nine. A customer asked about a discount that didn't exist. The agent, trying to be helpful, invented one — small dollar amount, we honored it, nothing broke. What stayed with me was how cheap the fix was in retrospect: three lines in a spec I hadn't thought to write, along the lines of "never quote a discount that isn't in the current promotions table." Cheap after the fact. Impossible in advance if you'd started the spec with capabilities.
Every agent spec I've written since starts with the nevers. Clients notice, and usually ask why we're opening on the negative. Because the refusals are the part you're actually trusting. What an agent can do is a feature list. What it won't do under pressure, at 2am, when a customer phrases something strangely, is what determines whether you can leave it running.
The four categories of never
Irreversible actions
Money moving, legal or contractual commitment, medical direction, anything you can't take back with an apology. These require a human every time, at every level of confidence, forever — it's not a maturity thing the agent graduates out of. The test I run in the design session is stupidly simple: if this goes wrong, can we undo it by Tuesday? A wrongly drafted email, yes. A wrongly issued refund, a canceled appointment for a patient, a quote that becomes a binding price, no.
Data it must not touch or emit
Which systems it can read, which fields it must never repeat back, what gets stripped before anything is logged. Be concrete rather than gesturing at "sensitive data." Name the fields. I've watched more incidents come from a vague "PII protection" line in a spec than from anywhere else in this list — vague policies get interpreted generously.
Claims it must not make
This is the category that bites SMBs hardest, and it's the one my earlier incident lived in. Guarantees. Prices outside a published range. Delivery dates it can't verify. Anything that sounds like legal, medical, or financial advice. An agent that invents a two-day turnaround because it's trying to be helpful has created an obligation you never agreed to — and the customer heard it from your company.
Volume and rate limits
The unglamorous one that prevents the worst afternoon of your year. A loop misfires and the agent sends four hundred messages to the same list. Caps belong in the configuration, not in the hope that the logic is correct.
Write them in the client's words, then read them aloud
We read the constraints section back in the design session, out loud, and watch faces. Low-tech, and it catches more than any review process I've tried.
"It will never quote a price above the published range without a human" usually gets a nod. It also produces, maybe one time in three, somebody saying "hang on, what about the maintenance contracts, they're priced differently." That sentence is worth the entire meeting. Vagueness in this section is what produces the incident three months later.
The autonomy ladder
"Will this thing go rogue?" is the real question under most AI hesitation, and it deserves a better answer than reassurance. Mine is a ladder with four rungs, and every deployment starts at the bottom.
Rung one is draft-only — the agent proposes, a human sends. Default for at least the first two weeks. Rung two is approve-per-item: it acts once somebody taps approve, fast enough not to be a bottleneck, and you still see everything. Rung three is approve-by-exception — it acts on its own, flagging anything below a confidence threshold or matching an escalation rule. Rung four is autonomous with daily review: it acts, you read the digest.
Two things make this more than a diagram. Promotion is by numbers rather than by feel — moving from rung 2 to rung 3 takes at least 95% approval across at least 50 items with no missed escalations, and that threshold gets written into the configuration before launch. So nobody has to argue about it later, while everyone's pleased with how things are going.
And the rung is a configuration value, not a code change. That matters more than it sounds. Going back down a rung is a switch somebody flips on a Friday afternoon, not a project. If a vendor can't reduce their agent's autonomy without a release, you have no brake.
Every branch ends in one of three places
When we map an agent's workflow, every path from trigger to finish has to land on completed, escalated, or failed safely. No fourth ending. A branch that dead-ends is a bug in the specification, not something to sort out during the build.
Failed safely deserves its own attention. What happens when the CRM is down, the calendar API times out, the document won't parse? The agent needs a defined behavior — usually: tell the human, preserve the input, don't retry blindly. That question gets answered in the spec or it gets answered in production, and production answers it badly.
Why capability-first goes wrong
Specify the capabilities first and you get an agent that demos beautifully with implicit limits — defined entirely by what nobody has happened to ask it yet.
Then a customer asks something adjacent. The agent, built to be helpful, produces a confident answer in the same tone it uses for everything it's good at. Nothing alerts. Nobody reviews it, because reviewing everything was never the plan. You find the boundary by crossing it, in front of a customer.
That was my day nine.
The inversion costs almost nothing to apply. Write the nevers, agree them out loud, put a rung on the ladder, then design capabilities inside that space. An hour extra in a design session, and it's the difference between a system you can leave running and one you have to watch.
The questions this raises next — who reads the escalations the agent produces, and how you'd know if any of it stopped working — are covered in who owns the agent and our definition of done.