Reflection and Self-Critique Loops

Reflection is an architectural pattern where an agent reviews its own work before producing a final answer or taking another action. The model generates an output, critiques it against criteria, and then revises it.

A reflection loop can be simple:

draft → critique → revise → final

Or it can be embedded inside a larger agent workflow:

plan → execute → draft answer → critique answer → revise → validate → final

Reflection is useful because first drafts are often incomplete. A model may miss a requirement, overlook a contradiction, use unsupported claims, or produce output in the wrong format. A critique step gives the system a chance to catch problems before the user sees them.

What reflection checks

A reflection step can evaluate many dimensions:

• Did the answer follow the user’s instructions?
• Are all required fields present?
• Are claims supported by tool results or provided context?
• Is the format valid?
• Are there safety or policy issues?
• Is the tone appropriate?
• Are assumptions clearly stated?
• Did the agent overstate confidence?

For example, a research agent might draft an answer and then ask a reviewer model:

Review the draft below. Check for unsupported claims, missing citations, stale information, and failure to answer the user's question. Return only a list of issues and suggested fixes.

The output of the reviewer is then used to revise the draft.

Reflection pseudocode

A basic implementation:

def answer_with_reflection(model, user_request, context):
    draft = model.generate(
        system="You are a technical assistant. Draft the best answer you can.",
        user=user_request,
        context=context
    )

    critique = model.generate(
        system="You are a strict reviewer. Find factual, formatting, and instruction-following problems.",
        user=f"User request:\n{user_request}\n\nDraft:\n{draft}"
    )

    final = model.generate(
        system="Revise the draft using the critique. Do not introduce unsupported claims.",
        user=f"Draft:\n{draft}\n\nCritique:\n{critique}"
    )

    return final

This uses the same model for drafting and critique, but production systems may use different models. A cheaper model might draft; a stronger model might review. Or a specialized validator might check structured output.

Reflection is not magic

Reflection can improve results, but it does not guarantee correctness. A model can fail to notice its own errors. It may critique superficial issues while missing deeper ones. It may revise in a way that introduces new problems.

Reflection works best when the critique criteria are explicit. A vague instruction like “make this better” is weaker than:

Check whether:
1. The answer directly addresses the user’s request.
2. Every factual claim is supported by provided context.
3. The output is valid JSON.
4. The response avoids speculation.
5. Any uncertainty is stated clearly.

The more concrete the rubric, the more useful the reflection.

Self-critique versus external critique

In self-critique, the same model or agent reviews its own output. In external critique, a separate reviewer component evaluates the output.

External critique may be stronger when:

• The reviewer uses a different model.
• The reviewer has access to validation tools.
• The reviewer follows a strict rubric.
• The reviewer checks against ground truth.

For example, a coding agent should not only ask the model whether the code is correct. It should run tests, type checks, linters, and security scans. Tool-based validation is often better than purely verbal critique.

Reflection in coding agents

A coding agent can use reflection after making a change:

1. Modify code.
2. Run tests.
3. If tests fail, inspect error.
4. Critique the change: did it address the root cause or only the symptom?
5. Revise code.
6. Run tests again.

The most valuable reflection comes from real feedback. Test results, compiler errors, and logs are stronger evidence than the model’s opinion.

Reflection in structured output

Reflection is also useful for structured output. Suppose an agent must return JSON. A validator can inspect the output and produce an error:

{
  "valid": false,
  "errors": [
    "Missing required field: customer_id",
    "priority must be one of low, medium, high, urgent"
  ]
}

The model can then repair the output. This is a reflection loop grounded in deterministic validation.

When to use reflection

Use reflection when:

• The output is important.
• The task has many requirements.
• The first draft is likely to miss details.
• The answer must follow a strict format.
• The system can validate against a rubric, schema, or tools.

Avoid unnecessary reflection when:

• The task is simple.
• Low latency is critical.
• The output is low-risk.
• A deterministic validator already guarantees correctness.

Reflection adds cost and latency, so use it where quality matters.

Practical takeaway

Reflection is a review loop. It improves agents by adding a second pass: draft, critique, revise. It is most effective when paired with explicit rubrics, tool-based validation, and clear success criteria.

A reflective agent is not automatically reliable. But a well-designed reflection loop can catch common errors, improve format adherence, and make agent behavior more inspectable.