Self-Critique
The cheapest way to improve a piece of work is to read it again before handing it over. Self-critique is an agent doing exactly that: having produced a draft, a plan or an answer, it is prompted to examine its own output against the goal and name what is wrong with it, in writing, before anything is finalised.
How the step is structured
The critique is a separate model call with a different job from the one that produced the draft. It receives the original goal, the output, and an instruction to find faults — missing requirements, unsupported claims, steps that do not follow. Its result is prose, not a score, and that prose becomes part of the next prompt. Keeping the roles apart matters: asked to produce and judge in one breath, a model defends its draft; asked only to criticise, it finds real problems. Feeding in a rubric, failing test output or a tool result gives the critique something external to measure against.
Why it matters, and its two honest limits
Self-critique is the mechanism behind reflection loops and the Reflexion architecture, and it is what lets an agent catch its own error before the error is acted on — before the file is written or the message sent. The limits are real. A model is poor at spotting a factual error it was confident enough to make, so critique without external grounding polishes style while leaving the mistake intact. And critique is not free: every round costs a call and context, so an unbounded critique-and-revise cycle will consume a token budget without ever converging. A step limit on the number of rounds is part of the pattern, not an afterthought.
Self-critique is a step in which an agent examines its own output against the goal and writes down what is wrong with it, before that output is finalised or acted on. The critique is a separate call with a fault-finding brief, and its text feeds the revision. It matters because it catches errors inside the loop rather than after an action is taken — though without external grounding it polishes style more reliably than it corrects facts.
Good writers reread their own drafts before sending them, and they usually find something to fix. Self-critique is software given the same habit. After the program produces an answer or a plan, it is asked a second question: what is wrong with this? It writes down the faults it can see, then uses that list to produce a better version.
This matters most when the program is about to actually do something — send a message, change a file. Catching the mistake while it is still a draft is far cheaper than catching it afterwards. The honest limit is that a program is poor at spotting errors it was confident about in the first place.