Start from the action, not the model
Guardrail discussions often begin with model behaviour: hallucinations, jailbreaks, bias. Those matter, but a more useful starting point is the list of actions an agent can take. A model that says something wrong in a draft is an annoyance. A model that sends the wrong payment is an incident.
Sort every action into three tiers
Before writing any code, we put each action an agent could take into one of three tiers.
- Autonomous: read-only lookups and small, reversible changes such as tagging a ticket
- Approval required: anything customer-facing, financial or hard to undo
- Never automated: legal commitments, personnel decisions and anything outside the agent's role
Put the tiers in configuration
The tiers belong in configuration, not in the prompt. The agent should be technically unable to call an action outside its tier without the approval step, whatever the model decides it wants to do.
Allowlists beat blocklists
It's tempting to write a list of things the agent must not do. That list is never complete. Give the agent an explicit allowlist of tools and parameters instead, and treat everything else as blocked by default.
Make approvals fast
Approval steps fail when they're slow. If a reviewer has to open three systems to check a proposal, they'll start approving without looking. Show the proposed action, the evidence behind it and the expected effect on one screen.
Review the tiers every month
As evaluation data builds up, some approval-tier actions prove reliable enough to run on their own. Others show problems nobody expected. A short monthly review keeps the guardrails matched to what the agent actually does.
