TL;DR
Output guardrails run on the agent's reply after the LLM produces it and before the user sees it, replacing an unacceptable reply with a safe fallback. They range from an LLM-judged toxicity check to cheap deterministic ones like schema validation and length limits. They're the backstop for when a good model still produces a bad reply.
Stop the bad output before it reaches the user
Input guardrails protect the model from the user. Output guardrails protect the user from the model. They run on the agent's reply after the LLM produces it and before it's shown — and if the reply isn't acceptable, they replace it with a safe fallback.
Why would a capable model ever produce a bad reply? Mostly it won't — but "mostly" isn't a safety guarantee. A cleverly-worded prompt can still coax an unwanted response, a tool can return something unexpected that the model repeats, or a formatting contract can quietly break. That's the checkpoint: you run the check on every reply precisely because you can't predict which reply will be the bad one — a guarantee that holds only sometimes isn't a guarantee.
Toxicity — a model call
A toxicity guardrail checks whether the agent's reply is offensive, harassing, or hateful before anyone sees it. "Toxic" isn't a keyword list — it's a judgement — so this one, like topic-scope, uses a real LLM call: a focused classifier that reads the reply and answers TOXIC or CLEAN, blocking the toxic ones. When it fires, the user gets a neutral fallback instead.
Other output checks — deterministic
Toxicity is the one your agent ships with, but output guardrails are a family:
- Schema validation — if your agent must return JSON in a fixed shape, validate it and block (or repair) malformed output.
- Length limits — cap a runaway response before it's sent.
These are deterministic and cheap; reach for them whenever the shape of a good answer is well-defined.
Analogy
Output guardrails are quality control at the end of the assembly line. The line (the model) almost always builds the product right — but "almost always" is exactly why you still inspect every unit before it ships, not just a sample. The one defective unit you don't catch is the one that reaches a customer.
Common mistake
Skipping output guardrails because "the model is well-behaved." Output guardrails exist for the cases the model isn't — the jailbreak that worked, the tool result it parroted, the malformed JSON that breaks your UI. A backstop you only deploy after the first incident isn't a backstop. The point is to catch the bad reply before it's the incident.
Key takeaways
Key takeaways
- Output guardrails check the reply after the LLM and before the user sees it.
- Toxicity is an LLM-judged check; schema validation and length limits are deterministic.
- Run them on every reply because you can't predict which one will be bad.
- They're the backstop for jailbreaks, parroted tool output, and broken formats.
Go deeper: block, repair, or regenerate?
When an output guardrail fires, blocking-to-a-fallback is the simplest response, but not the only one — the right move depends on why it failed:
- Block → safe fallback. Best for safety failures (toxicity): you don't want to show or retry a harmful reply, so you return a neutral message and stop.
- Repair. Best for structural failures (schema, length): if the JSON is malformed or the reply is too long, you can often fix it programmatically — truncate, or coerce to the schema — without another model call.
- Regenerate. Sometimes you re-prompt the model with the failure noted ("your last reply was invalid JSON; return only valid JSON"). Powerful, but it costs another model call and can loop, so cap the retries.
The choice mirrors the input lesson's block/redact/warn question — and both are really one question: given this specific failure, what's the safest useful response? That enforcement decision, and the cost of running these checks at all, is the next lesson.