Most context stacks capture identity. Very few capture learning.

A few weeks ago, I wrote about building a personal and business constitution: the stable context that helps Claude understand who you are, how you work, what you value, and how you make decisions. Creating these files keeps you from having to re-explain yourself every time you open a new chat.

But using my own stack, I noticed the blind spot. It knew my voice, my preferences, my business context, and the principles I tend to follow. It described who I was the day I wrote it. What it had not yet accumulated was the understanding that came from actually doing the work. Reading Karpathy’s LLM wiki and seeing the projects that spun out of it, clarified the problem for me. A useful system cannot only preserve context; it has to keep learning from the work it is helping you do. Mine was already good at reflecting my preferences as they changed, but it was not learning from my business decisions, client patterns, or project outcomes.

Every project I completed, every client interaction, every piece of feedback that shifted my thinking, none of that made it back into the system. The stack stayed static while my actual understanding of my work kept moving.

This is the next layer: turning experience into usable judgment.

What makes a context stack get more useful over time is capturing what your work keeps teaching you. Three categories of information are worth saving, and they show up in every business regardless of what you do.

1) What you shipped and how it landed. Every meaningful piece of work leaves behind useful information: the proposal that won, the recommendation that got rejected, the presentation that changed the room, and the presentation that quietly died in the room. The useful version goes past “it went well” or “they pushed back” and names the specific thing that changed the outcome. The level of specificity is what to keep, because it is what Claude can actually use the next time you are building something similar.

The best way to capture this is not to ask Claude for a meeting summary. A summary tells you what was said. What you need is a short post-meeting debrief that helps you interpret what happened. Give Claude the transcript, notes, deck, or even a messy voice memo if you have it, then have it interview you while the meeting is still fresh: what shifted, what surprised you, where people pushed back, what assumption turned out to be incomplete, and what should be remembered next time. The transcript provides the system with evidence, while the debrief gives it judgment.

2) What feedback reveals about your assumptions. This requires sitting with the premise you were working from that turned out to be incomplete. You assumed the audience had more context than they did. You assumed the decision-maker cared about efficiency when they actually cared about optics. You assumed a two-week turnaround was reasonable for a client who needs three rounds of legal review. These are some of the most valuable observations in your business, and they rarely make it into any system. They sit in your memory, available when you happen to think of them and invisible when you do not.

3) Patterns across projects. This may take the longest to build, but that is where the real value starts to build. When you capture enough individual signals, you start to see the shape of things: this type of client always needs more implementation detail than the brief asks for, this kind of stakeholder presentation works better when you lead with the risk picture before the opportunity, these projects run long when the scope conversation happens after kickoff instead of before it. Ten data points from real work become a pattern you can act on.

The capture mechanism is almost embarrassingly simple. After any significant piece of work, a project milestone, a client deliverable, a presentation, a pitch, you spend ten minutes in a structured conversation with Claude.

I use the same basic sequence each time. I give Claude whatever record exists: the transcript, meeting notes, deck, proposal, or a messy voice memo. Then I have it interview me using that material while the meeting is still fresh. What was the outcome? What changed in the room? What assumption turned out to be wrong or incomplete? What evidence from the conversation supports that? What would I do differently? What is worth remembering about this client, stakeholder, or project type?

Claude writes a short, structured summary that keeps two things distinct:  what happened and what I think it meant. What happened, what it likely meant, what evidence supports that reading, and what should be carried forward. That summary goes into a dedicated section of my context, a file that builds across projects instead of resetting.

Over time, that file becomes the thing that changes your next project before it starts. Claude reads what you have captured from the last three similar engagements and reminds you of the patterns before you build the next proposal. It pulls the notes from every board interaction you have logged before you prep for the next presentation. The context is still yours. You direct it, correct it, and decide what belongs. But now it is drawing from your actual experience rather than a static description you wrote once.

This works differently depending on your role, but the basic practice is the same.

The setup is a short conversation with Claude to establish the structure of your learning file: what categories make sense for your work, what the ten-minute debrief format looks like, and where the file lives in your project. If you have already built a context stack, this plugs directly into it. The learning file sits alongside your business constitution and project files and gets referenced the same way. It is the one file in your context that should grow with every project.

This is also why I would keep this layer portable (in files you can see, edit, and move). The notes you capture here are more than preferences. They are your working judgment: what clients care about, where projects break, which assumptions keep failing, and what real engagements are teaching you. That is too valuable to leave scattered across chats or buried inside one platform’s memory system.

If you want the debrief skill I use for the ten-minute capture session, reply, and I’ll send it.

— Lauren Eve Cantor

thanks for reading!

if someone sent this to you or you haven’t done so yet, please sign up so you never miss an issue.

I’ve also started publishing more frequently on LinkedIn, and you can follow me here

if you’d like to chat further about opportunities or interest in AI, or this newsletter, please feel free to reply.

banner images created with Midjourney.