Reflection: improving the first draft

Reflection resembles a writer and editor.

What you will learn

  • Explain: a workflow has explicit structure
  • Apply the idea in an example: Reflection: improving the first draft
  • Recognize limitations and verify the exercise outcome

Reflection resembles a writer and editor. The generator drafts, the reviewer checks criteria, and feedback can trigger revision.

These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.

How it works, step by step

Role instructions

Generator: answer in at most three sentences using the policy. Reviewer: check deadline, conditions and language; specify what must change. Preserve correct claims. “Make it better” is not actionable feedback. Use Sequential when you only need a fixed transformation without feedback.

Detailed lab

A revision with explicit criteria

Give both agents the same policy. The generator writes; the reviewer checks deadline, conditions and language. Useful feedback says “You omitted original packaging” rather than “the answer is bad”. The generator preserves correct facts and repairs the omission.

An illustrative run is: “Returns within 14 days” → criticism of omitted conditions → “Returns within 14 days of receipt if unused and in original packaging”. Inspect drafts and criticism in Playground. Compare whether revision added value.

Iteration limits prevent endless editing, but reaching the limit does not mean every criterion passed. Keep an independent evaluation rather than trusting the reviewer’s own verdict.

The visual map

Reflection: improving the first draft Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Reaching the iteration limit ends execution; it does not certify approval. Connections: User request → Generator: draft and revise; Generator: draft and revise → Current draft; Current draft → Reviewer: evaluate the draft; Reviewer: evaluate the draft → Approved or limit reached?; Result to verify → Human verification; Instructions and context → Generator: draft and revise; Evaluation criteria → Reviewer: evaluate the draft; Step and iteration limits → Approved or limit reached?; Approved or limit reached? → Result to verify (Yes); Approved or limit reached? → Actionable feedback (No); Actionable feedback → Generator: draft and revise (Revise). W03 · Relationship map Reflection: improving the first draft Input User request Data Instructions and context Data Evaluation criteria AI model / agent Generator: draft and revise Data Current draft AI model / agent Reviewer: evaluate the draft Data Actionable feedback Decision / control Approved or limit reached? Decision / control Step and iteration limits Output Result to verify Decision / control Human verification Yes No Revise Main flow Data and context Feedback and return

Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Reaching the iteration limit ends execution; it does not certify approval. On smaller screens, scroll horizontally to follow the entire diagram.

A complete example

The generator writes “The policy presupposes eligibility”. The reviewer asks for plain language, the exact deadline and unused condition. The revision says “You can request a return within 14 days if unused”.

generator: LunaWriter
reviewer: LunaReviewer
max_iterations: 2

Try it yourself

  1. Assign generator and reviewer roles; start with two iterations and explicit criteria.
  2. Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
  3. Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
  4. Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
  5. Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.

An explained solution

The revision is clearer and preserves facts. The reviewer compares against evidence, not just style preferences. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.

When it helps and what can go wrong

Two models can repeat the same error; add external evidence. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.

Check your understanding

Is multi-agent an eighth template?

No. It is an architectural category that can use several existing templates.

Can a prompt replace access control?

No. An instruction is not an authorization boundary.

What outcome should this exercise produce?

The revision is clearer and preserves facts. The reviewer compares against evidence, not just style preferences.

Words to remember

  • Nod: A stage in an execution graph.
  • Few-shot: Solved examples supplied in context.
  • Regresie / Regression: A change that breaks a previously correct case.

Sources and your next step

To prepare: W02 — ReAct: decide, act, observe