Guards
Guards are live breakers that monitor an agent during execution. While gates check after a step finishes, guards watch in real-time and kill the agent immediately if a condition is met.Declaring guards
Available guards
max_turns
Kills the agent if it exceeds a number of cognitive turns (think → act → observe cycles).max_budget
Kills the agent if the step cost exceeds a dollar amount. More reactive thanmax_budget at the workflow level (which checks after each step completes). This guard checks during execution by tracking token costs from the agent stream.
no_write
Kills the agent if it writes files outside.gump/out/. Used to enforce that planning and review agents don’t modify code.
output: plan, output: artifact, and output: review. You can override it with guard: { no_write: false } if you have a planning agent that legitimately needs to create files.
What happens when a guard triggers
- The agent is killed immediately
- The worktree is reset to the pre-step state (mutations undone)
- Partial metrics are collected (tokens spent, cost so far, turns completed)
- The
{error}variable is injected with the guard’s reason on_failureapplies — same as a gate failure (retry, escalate, or fatal)
guard_triggered event is emitted in the ledger with the guard name, reason, and partial metrics.
Guards are reactive, not preventive
Guards react to agent behavior by parsing the NDJSON stream. There’s a small delay between the agent acting and the guard detecting it. File writes are caught and reverted via worktree reset. Network calls or other side effects outside the worktree cannot be undone.Guards vs Gates
| Gates | Guards | |
|---|---|---|
| When | After the step finishes | During execution |
| What | Compile, test, lint, schema | Turn count, cost, file writes |
| Mechanism | Shell commands, file checks | Stream parsing, process kill |
| On failure | Same on_failure flow | Same on_failure flow |
| LLM involved | Never | Never |