> ## Content Index > Fetch the complete content index at: https://playbook.alwaysrunning.ai/llms.txt > Use this file to discover other available public pages before exploring further. # Give AI a review loop, not just a task - URL: https://playbook.alwaysrunning.ai/ai-review-loop-plan-act-inspect-adjust/ - Published: 2026-09-07T23:00:00.000Z - Updated: 2026-09-07T23:00:01.000Z - Description: Build a plan, act, inspect and adjust loop. Two fictional handover tests show how evidence should change the next action, with clear stopping rules. - Author: Ben Bradshaw **A useful AI review loop has four steps: plan a bounded action, act, inspect the evidence and decide what to adjust.** Repeating a task is not enough. The next iteration should reflect what the previous one taught you, and someone must be able to stop the process when it stops helping. This is a management discipline as much as a technical pattern. If the goal is unclear or the review is superficial, a loop can repeat the same mistake very efficiently. A founder needs a way to see what changed, why it changed and whether the result is moving towards the intended outcome. ## Make the review part of the work A common brief stops at the output: draft the summary, classify the request or prepare the plan. A stronger brief includes the check that follows it. What evidence will be inspected? What counts as a useful result? Which finding should change the next action? Anthropic's guidance on [building effective agents](https://www.anthropic.com/engineering/building-effective-agents?ref=playbook.alwaysrunning.ai) stresses feedback from the working environment, human checkpoints and stopping conditions. Those design ideas support a practical business rule: the workflow needs evidence of progress, not just a convincing account of its own activity. ## Two illustrative iterations *The following example and all its numbers are fictional. They demonstrate a review method, not a measured customer outcome or a Walter capability.* Imagine a service team testing AI-prepared internal handover summaries. The outcome is that the next person can identify the customer's issue, the current owner and the next agreed action. AI prepares drafts only; a team lead approves the handover. ### Iteration one: discover the missing distinction The team tries five fictional conversations. Three drafts include an issue, owner and next action. Two name someone who was mentioned in the conversation but never accepted responsibility. The review records more than “three out of five passed”. It identifies the failure: the workflow confuses a person being mentioned with a person owning the next step. The team changes the instruction to require explicit ownership evidence. If that evidence is absent, the draft must say “owner unconfirmed”. ### Iteration two: test the changed rule The team keeps those five cases and adds two new fictional conversations with ambiguous ownership. It reruns the draft process. In this illustration, the revised version correctly marks the ambiguous cases as unconfirmed. That is useful evidence about one rule. It does not prove the workflow is generally accurate or ready for unattended use. The team checks whether the new rule also caused confirmed owners to be omitted. It then decides whether to run a limited trial with authorised real inputs and human review. ## A review log you can reuse | Record | What to write | | ---------------- | --------------------------------------------------------------------------------------- | | Goal | The business outcome and the part this iteration will test. | | Plan | The bounded action, source inputs and expected result. | | Actual evidence | What happened, with the relevant output and source attached. | | Failure category | For example: missing input, incorrect inference, unclear permission or unusable format. | | Change | The one rule, input or process step being revised. | | Next test | How to check the improvement and any side effects. | | Decision owner | The person who can continue, narrow, escalate or stop the work. | Changing one important variable at a time often makes a small test easier to interpret. If you replace the inputs, rewrite the brief and change the scoring simultaneously, be cautious about claiming which change helped. ## Define the stopping conditions first A loop needs limits on both effort and authority. You might allow two revision attempts before a human review, or stop immediately when a required source is unavailable. These are design choices for the task, not universal settings. Also define what the workflow must not do to make the test pass. It should not silently weaken the acceptance criteria, discard difficult cases or change an unverified item to complete. Preserve the original check and make proposed changes to that check explicit. ## Keep the founder's decision visible The review is where judgement enters the loop. An output can be technically correct but operationally unhelpful. A draft might satisfy the fields while overwhelming the person who needs to act on it. Ask the intended user what they can now do, what remains unclear and what would make the next version useful. Your next AI brief can be short: “Prepare one version, show the evidence against these checks, and propose the smallest change for the next attempt.” That gives you a loop you can inspect before asking it to run further. --- **Explore Always Running:** visit [AlwaysRunning.ai](https://alwaysrunning.ai/?ref=playbook.alwaysrunning.ai) to learn more.