input_guard sits at the front
of the turn, before compaction and before the agent node; output_guard sits at
the end, after the final assistant message and before it reaches you. Both are
governed by the agent’s guardrails_policy.yaml: when the policy disables a
guard, the node is not in the graph at all, so there is no per-turn cost. When a
guard blocks, the graph routes straight to END with a refusal message; on the
input side this means no LLM call is made at all. Guardrails are per agent,
like every other policy, so the researcher can run lighter checks than the
default Generalist, and the safe flavour can force them on for its members
through the flavour policy overlay.
This page is in progress. It will cover the
guardrails_policy.yaml schema, the
available backends (including the local Llama Guard models pre-cached by
python -m app.cli.startup), the evaluator and its verdicts, and how to check a
policy from the command line with python -m app.cli.guard_check.Architecture
Where the guard nodes sit in the agent loop.
Permissions
The other gate: per tool call, not per turn.
Flavours
The
safe flavour forces guardrails on.