Agent Reflection · Comparison
The guardrail passed it. It still broke your brand rules.
Guardrails stop output that is unsafe or malformed. Agent Reflection checks whether output that is safe is also right for your company. Here is what each does and how they fit together.
What guardrails do well.
Guardrails sit in the path of a request and enforce hard limits: keep personal data from leaving, refuse an injected instruction, make a response match a schema, keep a topic off the table. They are quick and predictable, and they can stop an output instead of only describing it. Keep them.
Agent Reflection is not a safety layer. It is not built to replace a guardrail for personal data, injected instructions, or output format.
What a guardrail does not judge.
Safe is not the same as good. A support reply can contain no personal data, no toxic language, and a valid format, and still promise a refund date nobody can keep, take the wrong tone, or make a claim legal has not approved. Those standards are judgments, written in documents by the people who own them: brand, support, legal, product.
Guardrails are often configured in code or in a policy file by engineers. Changing what counts as an acceptable promise then means a code change, and the person who owns the promise policy may not be able to read the check.
What Agent Reflection does instead.
Agent Reflection reads the same document the owner wrote. A rule is a Markdown file in plain language, versioned, and open to every agent that connects. A critique returns pass or fail for each rule and quotes the passage that failed.
It does not block anything. The agent decides what to do with the result, and the loop is to revise the quoted passage and run the critique again.
Side by side.
| What you need | Guardrails | Agent Reflection |
|---|---|---|
| Stop an output before it leaves | Yes, the core job | No. A critique returns a result, and the agent revises and runs it again |
| Enforce a schema or format | Yes | Not what it is for |
| Detect personal data or injected instructions | Yes, in many tools | Not built for it. Keep a guardrail for this |
| Judge tone, promises, claims, or brand rules written in plain language | Limited to what can be written as a check | Yes. Each standard is a rule |
| Who edits the standard | Often engineers | Whoever owns it, in a Markdown rule |
| Shows which words broke the standard | Depends on the check | Yes. The failing passage is quoted |
| Keeps versions of the standard | Depends on the tool | Yes. Versions never change |
Guardrail tools differ. The middle column describes the core job of enforcing hard limits. This page describes a category in general, not any one product.
Use both.
Put guardrails where an output must be stopped. Put rules where an output must be good. One order that works: the guardrail enforces the hard limits, the agent calls a critique against the rules your owners wrote, and the agent revises until the result passes or the attempt cap is reached.
Questions.
- Does Agent Reflection replace guardrails?
- No. Keep guardrails for personal data, injected instructions, and format. Agent Reflection checks standards that are judgments, such as tone, promises, and claims.
- Does Agent Reflection block bad output?
- No. It returns a result. The agent reads which rules failed and the passages that broke them, revises, and runs the critique again. Whether anything is blocked is decided by your agent or your workflow.
- Who writes the rules?
- Anyone in your company with an account. Company admins and company users can both write rules and rule sets. Rules are plain-language Markdown, so the person who owns the standard can write it.
