🔁 Repeating isn't improving: what's missing from a weak loop
🧠 Imagine it this way: going to the gym every single day without logging any weights, reps, or measurements isn’t training—it’s just showing up. Without a benchmark saved from one session to the next, you don’t know whether you’ve made progress or just gone in circles.
A real improvement loop isn't "taking another look from time to time" — it's a cycle with focus (one small area at a time), criterion saved from one cycle to the next, test that confirms whether the change worked and a record of what was learned. Remove any one of these four pieces, and what remains is repetition, not improvement.
✗ Weak loop (avoid)
"Review my app every day." It sounds disciplined, but it doesn’t say what to review, what criteria to use, what to do if you find something, or where to save what you discover. Without those answers, the agent repeats the same generic scan every day — or worse, uses different criteria each time because none were saved.
Caption: on the left, "review" just revolves around itself, with no criterion or record; on the right, choose → test → record ends with a memory that also feeds the next cycle.
✓ What the strong loop guarantees
- ✓Choose one small area per cycle, not “the entire app.”
- ✓Uses a criterion saved from one cycle to the next — it doesn't reinvent the yardstick each time.
- ✓Only apply the change if it's safe and reversible.
- ✓Run a real test before accepting that it "improved."
- ✓Ask a verifier to try to find an error.
- ✓Records the lesson in something that survives the end of the cycle.
✗ What the weak loop has
- ✗"Review from time to time" without saying what to review.
- ✗No criteria saved—each cycle reinvents what “good” means.
- ✗Applies a change without checking whether it’s reversible.
- ✗Accepts "seems better" without any testing.
- ✗Only the opinion of the person who made the change, without a second check.
- ✗No record—the next session starts from scratch.
In one sentence: a real loop has a focus, criteria, tests, and a record—without all four, it’s just repetition that looks disciplined.
🛠️ The 7-step loop — copy-run prompt
🧠 Imagine it this way: it’s an F1 team’s pit-stop checklist—every stop follows the same steps, in the same order, and ends with a note about what to adjust next time. No one improvises the sequence at each stop.
Tip 11 of the guide gives you the concrete recipe for turning “review from time to time” into a real cycle: 7 fixed steps, always in the same order, ending by updating the project memory (tip 12, topic 4 below).
Goal: give the agent a fixed routine for continuous verification — one that reads the saved criterion before acting and records the lesson learned afterward, instead of reevaluating everything from scratch each cycle.
A cada ciclo: 1. escolha uma área pequena do sistema; 2. analise com base nos critérios já salvos em memória; 3. proponha uma melhoria; 4. implemente somente se for segura e reversível; 5. rode teste; 6. peça ao verificador para tentar encontrar erro; 7. registre a lição aprendida.
How to check: run a complete cycle from start to finish and confirm at the end that there is (a) a record of a criterion that was actually consulted in step 2 and (b) a new line recorded in step 7. If step 7 left no trace anywhere, the next cycle will start from scratch — the loop didn’t really close.
Caption: the 7 steps rotate in a circle, always in the same order; the dashed cyan arrows show the link to memory—"analyze" reads the saved criterion, "record" saves the lesson learned, closing the loop for the next rotation.
Cross-reference with track 1 · official source
"Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification."
Steps 5 and 6 of this loop (run a test + ask the verifier to find errors) echo exactly the technique from module 1.4 of track 1, which is backed by Anthropic’s official documentation. There, the focus is on how to delegate this check technically (a fresh-context subagent); here, it’s the practical rhythm of when to trigger that check within a continuous improvement cycle.
→ Go deeper in module 1.4 — Let it act + prove it’s doneIn one sentence: 7 fixed steps, always in the same order—the criterion goes in at step 2, the lesson comes out recorded at step 7.
🗂️ The problem with relying only on chat history
🧠 Imagine it this way: a company where all important knowledge lives only in one person’s head, or only in a chat nobody saves. The day that person leaves—or the chat resets—the company loses everything it learned, even after months of learning.
For long-running, continuous work — a product that evolves over months, a brand running campaigns every week — the history of a single conversation isn’t reliable memory. A new session, overflowing context, or a cleared chat: any of these can erase decisions and lessons that took real time to learn.
Week 1 — decision made
You and the agent decide, in a long conversation, that campaign X works better with an informal tone.
Week 3 — new session
New context, different chat. The agent no longer has access to that decision—it lived only in the old conversation history.
Week 3 — mistake repeated
The agent suggests a formal tone again for the same campaign because it doesn’t know that this has already been tested and rejected.
Result
Time wasted relearning something that already had an answer—and no one notices until they compare it with what was decided weeks ago.
⚠️ The compounded cost
Every decision that exists only in chat is a decision that will have to be revisited from scratch in the next long session. That doesn’t scale: the longer the project lasts, the more costly it becomes to rebuild context whenever the memory doesn’t survive the end of the conversation.
In one sentence: chat history is fragile by nature—real project memory needs to live outside the conversation.
📋 What to put in external memory
🧠 Imagine it this way: it’s a project’s operations manual—it doesn’t store every conversation that’s ever happened; it stores only what any new person (or new agent) would need to know to avoid repeating the same mistakes and decisions.
Tip 12 of the guide lists what an external memory for ongoing work should contain—it’s not raw history, but a distillation of what changes the next decision. Each item below is something you can check to see whether it’s already recorded in your project today.
Target audience
Who the project serves, and what that person already knows or wants.
Communication tone
How the project communicates, formally or informally, and why.
Offers
What is currently being sold/offered.
Campaigns that worked
What has already been tested and worked—and what didn’t.
Technical rules
Constraints, standards, and integrations that must not be broken.
Strategic decisions
What has already been decided and doesn’t need to be reopened every time.
Recurring mistakes
What has failed more than once and how to avoid it happening again.
Work processes
How things are done here, step by step.
Validated prompts
What has worked well and can be reused.
Quality standards
What separates “acceptable” from “truly ready” in this project.
In one sentence: good external memory doesn’t store the entire conversation—it stores only what changes the next decision.
🔗 The loop that reads and writes to memory every cycle
🧠 Imagine it this way: an experienced professional doesn’t have to relearn the job every Monday—they consult their own notes before making decisions and write down what they learned before they leave. That’s exactly what brings the two tips together.
On its own, the 7-step loop (tip 11) is already better than "reviewing every now and then." But it only becomes a real work system when steps 2 and 7 point to a real place: step 2 reads the external memory (tip 12) before analyzing, and step 7 writes to it after learning something. Without that link, the loop resets the criteria with each cycle — exactly the problem in topic 3.
🔗 Where the loop meets memory
- •Step 2 — analyze based on the criteria already saved: 📖 reads the target audience, technical rules, quality standards, and decisions already made.
- •Step 6 — ask the verifier to try to find an error: 📖 reads the recurring errors already recorded, so you don't repeat the same mistake.
- •Step 7 — record the lesson learned: ✍️ record a new entry (decision/lesson, why it matters, where to apply it, what to avoid, date).
Combined example—reviewing a product’s onboarding
- Choose a small area: just the onboarding welcome screen.
- 📖 reads in memory: communication tone + quality standard already validated for this screen.
- Suggests: replace a long paragraph with 3 bullets, following the saved tone.
- Implement it—it’s reversible (just undo the commit).
- Run the test: 5 real users complete onboarding; measure the time to the first click.
- A verifier (another agent/person) tries to find a problem — checks whether any bullet cut information that would change the user's decision.
- ✍️ record in memory: “Short bullets reduced time to the first click by 20%—apply that to the rest of onboarding. Date: today.”
In one sentence: the loop without memory restarts every time; the loop that reads and writes to memory accumulates — each cycle starts smarter than the last.
⚠️ Common mistakes with these 2 tips — quick checklist
🧠 Imagine it this way: a calendar nobody updates is worse than having no calendar at all—because everyone trusts it, assuming it’s accurate. Out-of-date external memory carries the same risk: it looks like a source of truth, but it lies.
✓ Do
- ✓Keep memory short and distilled — only what changes the next decision.
- ✓Update the existing note instead of duplicating new information.
- ✓Always define a small area for each loop cycle.
- ✓Confirm an actual test before accepting “it improved.”
- ✓Let the verifier be someone or something separate from whoever implemented the work.
- ✓Review the memory from time to time to remove what has become obsolete.
✗ Avoid
- ✗Letting memory become a chat history pasted into a file (junk, not memory).
- ✗Duplicating the same decision in three different files that diverge over time.
- ✗Run the loop on an area too large to fit in a single cycle.
- ✗Applying a change “because it seems better” without running a test.
- ✗Letting the same agent that implemented the work validate it.
- ✗Never revisit the memory—it ages too.
In one sentence: a loop without memory is deaf; memory without a loop is dead—the two tips only work when used together in full.
🧾 Module Summary
Next module:
2.7 — Bonus: the master prompt.