New here? Start this series at Day 31: Why agents need outcomes, boundaries, and stop conditions
- Day 31: Why agents need outcomes, boundaries, and stop conditions
- Day 32: Why agent behavior is a loop, not a single prompt
- Day 33: Why planning reduces wasted AI actions
- Day 34: Why tool access is where AI becomes operational risk
- Day 35: Why agent memory is not one database
- Day 36: Why reflection should change the next action
After the mission comes the debrief. Not to feel good about the flight: to change something before the next one.
There is a test for whether your agent's reflection step is real: diff the behaviour. Run the task, let it reflect, run it again. If run two is identical to run one, you paid for a paragraph.
Plausible self-critique is nearly free
LLMs are extremely good at producing sentences that sound like learning. "I should have been more thorough." "I should have verified the data before proceeding." These read as insight and change nothing, because they are not connected to anything the next run will encounter.
Real reflection has three stages, and most implementations build only the first:
- Review: compare the outcome against the goal and name the specific step that failed. Not "be more careful"; "the address was not validated before the shipping call."
- Revise: convert that finding into a concrete change: an updated procedure, a modified plan template, an added precondition.
- Persist: store the change where the next run will actually hit it. A lesson living in a transcript nobody re-reads is a lesson unlearned.
Stage three is where this connects to procedural memory from yesterday. Reflection without a persistence path is a diary. Persistence without review is thrashing.
Measure it like a system property
Do not assess reflection by reading outputs. Track error rate on repeated task types over time.
If the line is flat, the debrief room is theatre, and you are paying for it on every run, in latency and tokens. That is worth knowing, because the instinct when an agent underperforms is to add more reflection, which makes a non-functioning loop more expensive rather than more effective.
Where it earns its place
Add it where mistakes are expensive or hard to detect. Skip it on simple, verifiable, low-stakes tasks. There, extra reasoning is pure latency, and the agent will happily generate a thoughtful critique of a task that was already correct.
And cap the loop. Revise-critique-revise with no budget does not converge on quality; it converges on your rate limit.
Reflection should change the next action. If you cannot point to what changed, you have added commentary to your trace and cost to your bill.
Do your agents learn anything between runs, or does every session start from zero?
More on these topics
Comparison · · 1 min read
LangGraph vs the OpenAI Agents SDK
Two ways to write the same supervisor. Compared on control flow, tracing, provider coupling, testing and what each makes hard.
Checklist · · 24 checks
Working with Claude, practices that hold up
Prompting, agents and tools, Claude Code, evaluation and safety. The habits that make Claude-based systems reliable, as a checklist you can run against your own setup.
Architecture pattern · · 1 min read
Pattern: the outbox for agent actions
Agents that write to systems of record need the same transactional outbox that event-driven services use. This entry covers the shape and the trade-offs.
Discussion