The question that decides whether an agent is safe to deploy is not "how good is the model". It is "what is it allowed to do when it is wrong, and who finds out".
Guardrails get discussed as though they were a safety feature bolted on at the end, next to logging and rate limits. In practice they are the specification. An agent is defined by the set of actions it may take without asking, and every other design decision follows from where that line sits.
Start from actions, not from prompts
A great deal of guardrail effort goes into constraining what the model says. That matters, but it is the smaller half. What matters more is what the system does with the output.
Enumerate every action the agent can take against your systems: read a record, draft a message, send a message, update a field, issue a credit, close a ticket, escalate. For each one, decide whether it happens automatically, happens after a human confirms, or is not available to the agent at all. That table is the guardrail specification, and it should exist before anyone writes a prompt.
The useful discipline here is that the table forces the ambiguous cases into the open. "Update a field" is fine for a status flag and not fine for a payment amount, and noticing that during design costs an afternoon.
Three lines worth drawing
Reversibility
Anything the organization can undo within minutes is a candidate for autonomy. Anything that leaves the building — an email to a customer, a payment, a public post — should default to confirmation, at least until the system has a track record you can point at.
Blast radius
One record is different from a thousand. An agent permitted to update a record should not be implicitly permitted to update every record matching a filter. Bulk actions deserve their own row in the table, usually with a cap, because the failure mode is not "it made a mistake" but "it made the same mistake four thousand times before anyone looked".
Confidence
Uncertainty should route to a person rather than to a best guess. This only works if the escalation path is genuinely available — an agent that escalates into an unmonitored queue has not escalated, it has stalled, and stalled work is often worse than a wrong answer because nobody is watching for it.
The rule that matters
Anything outside the guardrails escalates to a person instead of guessing. Where that line sits is a business decision, made before deployment, not a technical default.
What has to be logged
Log the decision, not just the outcome. When something goes wrong three weeks later, "the agent closed the ticket" is not enough to act on. What you need is what it read, what it concluded, which rule allowed the action, and what it would have done differently with one more piece of context.
The practical test is whether someone who was not there can reconstruct the reasoning from the log alone. If reconstructing it requires re-running the agent, the log is insufficient — and re-running against changed data will not reproduce the original decision anyway.
Escalations deserve the same treatment. An escalation rate that quietly climbs from two percent to twenty is the earliest signal that something upstream has changed, and it is only visible if escalations are recorded as events rather than handled as exceptions.
Guardrails are not a substitute for evaluation
A well-drawn boundary limits the damage a wrong answer can do. It does not tell you how often the answer is wrong. Those are separate instruments and teams routinely conflate them.
Evaluation needs a set of cases with known-good outcomes, run on every meaningful change, with a threshold agreed in advance. Without it you have a system that is safe and possibly useless, and no way to tell which. With both, you can widen the guardrails deliberately over time, because you have evidence rather than a feeling that it seems to be going well.
Widening the boundary later
The line should move. A sensible first deployment is more conservative than the steady state, and staying conservative forever wastes most of the value.
Move it on evidence: a named action, a stated error rate over a stated period, and a person who agrees to own the consequence. Do not move it because the agent has "been fine". Fine is not a measurement, and the absence of reported problems in a system nobody is monitoring is not the same as the absence of problems.
Who owns the boundary
A guardrail table written only by engineers describes what is technically safe. It does not describe what the business is willing to be wrong about, and those differ more than people expect.
The line between propose and act is a commercial decision with a named owner — usually whoever answers for the outcome when it goes wrong. Getting that person into the design conversation early is the difference between a boundary that survives contact with production and one that gets widened under delivery pressure by whoever happens to be on call.
It is also worth writing down what the agent is explicitly not permitted to do, even where nobody has asked for it. An empty prohibition list tends to mean the question was never asked, and the answer gets improvised later by someone with less context and a deadline.
Where Focus20 fits
We design the guardrail table with your team before the build starts, because it determines the architecture rather than decorating it. Evaluations and observability ship with the first version, and the escalation design is agreed with whoever will actually be on the receiving end of it.