What is Guard Condition?
Also called precondition check, action guard.
A guard condition is a check evaluated before an agent action is allowed to proceed, blocking it when the check fails. Guards are enforced by the runtime rather than by the model, which makes them effective against reasoning errors, ambiguous instructions, and injected instructions alike.
Guards address a structural gap: an agent's decision to act comes from a probabilistic process, so no amount of instruction guarantees the action is safe. Placing a deterministic check between the decision and the effect means the unsafe action is refused regardless of how the agent arrived at it, which is what distinguishes a guard from a warning in a prompt.
Typical guards check identity and permission, argument shape and range, resource ownership, rate and volume, and whether a required approval exists. Volume guards catch a distinct failure class, since deleting one record and deleting fifty thousand differ only in a parameter but not in the code path that executes them.
A refused action must be returned to the agent as a clear observation rather than swallowed. The agent needs to know that the guard fired and why, so it can choose a different route or escalate. Silent refusal produces the worst outcome, an agent that believes it acted and reports success while nothing happened.
Guards are most valuable exactly where an agent is most autonomous. In a supervised flow a person is the guard, so an unusual action is caught by review. In an unattended run there is nobody watching, and the guard is the only thing standing between a misread instruction and a real, irreversible effect on production data.
Key points
- Deterministic check evaluated before an action executes
- Effective regardless of why the agent chose the action
- Common checks: permission, arguments, ownership, volume, approval
- Refusals must be returned to the agent, never silent
- Most important in unattended, high autonomy runs
In practice
A cleanup agent calls a delete tool with a filter matching 4,000 records. A volume guard permits at most 50 deletions per call, so the runtime blocks the call and returns an error explaining the limit and the matched count. The agent narrows its filter, and a genuinely overbroad query that a person would have caught in review is stopped in an unattended run.