Open your last AI conversation. Somewhere in it, a correction may have changed what happened next. If you save the whole conversation, will the next task find that correction and know when it applies?
I keep the full record, but I do not let every line become an instruction. A log tells you what happened. Memory should help you decide what to do next.
You can practise that distinction with a conversation you already have. Find one changed decision, check the evidence behind it, and keep a short lesson with its limits. There is no need to build a new automation or invent an experiment.
Saving everything creates a different problem
My hooks capture activity while I work. They leave me a record of actions and outcomes without making me write a diary after each task. But that record also contains old assumptions and temporary fixes. The useful correction can sit beside things that should never guide another decision.
If an AI retrieves the wrong note from that pile, more memory can make the next task worse. It can confidently follow a decision that has been reversed, repeat an experiment that already failed, or treat a temporary workaround as a permanent rule.
That is why I review the record before anything becomes guidance.
I now think about the system in three layers
The first layer is the raw record. This is where the system captures what happened: the work requested, the actions taken, the outcome, and anything worth looking back at later. It does not need to be elegant because it is not meant to guide the next task directly.
I think of raw capture as evidence, not knowledge. It is useful when I need to investigate a decision or understand why something changed, but it is not automatically knowledge.
The second layer is working context. These are the things that should help an AI before it starts: project conventions, known constraints, current decisions, and instructions that still apply. This is the layer that stops every new session from having to rediscover the same basic facts.
The third layer is the durable lesson. It is much smaller than the raw record and more deliberate than working context. **It contains the things that would change the next decision if I encountered a similar situation again.**
That final layer is what I mean by memory. In Obsidian, it can be a short note with a link back to the conversation that supports it.
An existing conversation supplies the worked example
A useful note does not need to preserve an entire conversation. It only needs to preserve the part that would otherwise be lost.
Consider the shared-component example from the reflection-loop discussion. This is an illustrative walkthrough, not a claim about a newly completed project: an AI replaces an upload component, the new version breaks its mobile layout, and restoring the existing responsive wrapper fixes it.
The full record could include changed files, failed attempts, and screenshots of the layout. A first attempt at a lesson might sound like this:
Never replace an existing upload component.
That goes further than the example supports. The replacement did not fail merely because it was new. In this example, it failed because it lost behaviour the old component already handled.
The useful lesson preserves the constraint, not a blanket ban. A better candidate would tell the next session to inspect the responsive wrapper before replacing the component, then check the mobile layout after any change.
Open one of your own completed conversations now. Look for a point where a correction changed what happened next. If you cannot find one, choose another conversation rather than forcing a lesson out of routine work.
Give the AI a focused extraction request: identify the decision that changed, explain what evidence changed it, and propose one lesson. Ask it to name anything that remains untested and to leave the note unsaved.
In the upload example, the changed decision is preserving the wrapper. The evidence would be the layout before and after restoration. Without those checks, the note should say the wrapper is a suspected cause, not an established one.
The transcript can remain available as evidence, but it should not become the thing that guides future work. The next session needs a usable instruction and its reason, with a way to check the source.
I use a small review before something becomes permanent
When a task ends, I try to ask three questions. Did this change a decision? Would I repeat the mistake? Can I explain it briefly?
If the answer is no, the record can stay in the raw layer. Not every task creates a principle that deserves to live forever. A completed task is sometimes just a completed task.
Sometimes there is no lesson yet, only an unanswered question. That can still be useful to save, but it should be saved as an open question, not turned into a rule too early.
This is important because AI systems are very good at turning partial information into something that sounds complete. A short note can feel authoritative simply because it has been written down. The review is where I decide whether it is a fact, a current convention, an open question, or something that no longer matters.
A completed Claude Code review gives a concrete reason for this pause. In a small public-project demonstration, Claude claimed that detecting an unfinished quoted CSV field required a custom parser. A check showed that Python’s existing CSV reader could reject that input with `strict=True`.
Claude then corrected its statement: “No custom parser is needed. My earlier claim was an overreach.” The documented strict parsing option supports that narrower correction.
Saving the first review as knowledge could have sent the next task towards unnecessary code. But “always enable strict parsing” would also go too far: choosing which imperfect files to reject remained a separate decision.
That recorded demonstration used the command-line version of Claude Code. It established a correction within the conversation; it did not test whether a later session would retrieve or apply it.
A useful note keeps its boundaries visible
Return to the illustrative upload example. Once the evidence has been checked, the note could look like this:
**Decision:** Preserve the existing responsive wrapper when changing the upload component.
Reason: In this example, the replacement broke the mobile layout. Restoring the wrapper fixed the checked layout.
Next time: Inspect the wrapper before replacing it. Check the mobile layout after the change.
Applies to: This component and changes that depend on the same wrapper. Other components need their own checks.
Evidence: Attach the relevant conversation excerpt and before-and-after checks. Do not invent a source if none exists.
Open question: Would a redesigned wrapper work equally well? That has not been tested.
This is a proposed note for the example, not a report of something saved into my vault. Its purpose is to show what gets removed from the original conversation, and what must stay.
The list of every command can remain in the raw record. The reason for preserving the wrapper belongs in the lesson, alongside its scope. The unanswered redesign question stays visibly unanswered.
To use this yourself, save the reviewed note in an appropriate project page in Obsidian, or in a plain Markdown file. Keep sensitive details out of shared notes, and link to the supporting evidence rather than copying a whole private conversation.
In the next relevant conversation, explicitly ask the AI to read the note. Ask which part applies to the new task and what it needs to check again before acting.
A saved lesson is only useful if it reaches the next decision. Inspect the result to see whether the relevant check happened. An assistant saying it read the note is not enough.
The important part is still judgment
AI can make the administrative side of reflection much easier. It can capture things I would forget, summarize a long session, group related notes, and remind me that I tried something similar before.
But it cannot fully decide what I should learn from the work.
An AI can tell me that an approach failed three times. It cannot reliably tell me whether the approach was wrong, whether the circumstances have changed, or whether it is worth trying again with a different constraint. That is still a judgment call.
This is the boundary I want to keep. I want AI to help maintain the record, but I do not want it to quietly turn every record into a belief.
The review does not need to become another productivity ritual. It can be a short pause between what happened and what gets carried forward. Without that pause, a system that captures everything eventually cannot tell the difference between experience and learning.
Start with one conversation you already have
You do not need to do this after every small task. A typo fix may leave nothing worth carrying forward, and a decision that is already documented does not need a duplicate lesson.
Use it when forgetting a reason would plausibly change your next choice. That is also when the review earns its time: the note could influence future work, so its claims deserve checking.
Take a finished conversation and paste this:
Review this conversation for one lesson worth carrying into a future task. Identify the decision that changed and the evidence behind it. Propose a short note containing the decision, reason, next-time action, scope, and evidence reference. Separate observed facts from assumptions. Leave unresolved issues as open questions. Do not invent a lesson if nothing reusable emerged, and do not save anything yet.
Read the proposal against the actual conversation. Remove unsupported claims, then decide whether to keep it, narrow it, or leave it in the raw record.
What would you want your next AI conversation to do differently because of this one?
The split between a log and a decision input is still unfinished in the standards layer. NIST SP 800-92 Rev. 1, the Cybersecurity Log Management Planning Guide by Karen Scarfone and Murugiah Souppaya, appeared as an initial public draft on 11 October 2023, its comment period closed on 29 November 2023, and the document history lists no final version since. Its definition of log management covers generating, transmitting, storing, accessing and disposing of log data, so disposal is part of the job rather than cleanup afterwards. That is the same boundary drawn here between a record and an instruction.