How I Claude

If you've spent much time coding with Claude Code or Codex, you've probably had a moment when you found yourself uttering a few choice words at your terminal. Maybe your agent just made the same mistake for the fifth time. Maybe it ignored a decision you'd already discussed with it. Or maybe it confidently implemented something that you explicitly told it not to do two sessions ago. #$@&!

The agent isn't doing anything wrong. Every new session starts with a fresh context window. Whatever it learned yesterday is largely gone today.

I got tired of repeating myself, so I built a memory system for my coding agents. It's made a substantial difference in how I work.

The architecture is simple: two loops operating around one shareable memory:

The first loop is the coding session itself.

Every session, across every project, starts by loading a small status file (under 25 lines) along with the debriefs from recent sessions. The status file tells the agent where things stand, what's next, and what it needs to watch out for. Beyond that, agents have access to a shared collection of Markdown files in the repository containing project rules, architectural decisions, patterns, and procedures. Every decision has a place, and changes to these shared documents go through a human-reviewed pull request.

There's another layer, too: a searchable archive of every coding session transcript, retained locally for 365 days. Any agent can search those conversations to find out what happened, what was tried, and why a particular decision was made.

In one instance, an agent found a decision I'd made a month earlier about which pages were allowed to trust a particular login token. It recognized that a shortcut it was considering would violate that decision and abandoned the approach without me having to say a word.

At the end of each session, the agent writes a short debrief (40 lines maximum) covering what it did, what it decided, what's next, and anything the next session should know. No secrets, no copied conversation history, just the information someone picking up the work needs. That's the first loop. Each session reads the accumulated memory, does its work, and leaves something useful behind for the next one.

The second loop is what I call the gardener.

Once a week, on Monday morning, a separate scheduled agent reviews everything that's changed: merged pull requests, issues, session debriefs, and decisions made during the previous week. It looks for outdated documentation, conflicting decisions, things that should be promoted into shared memory, and information that no longer belongs there.

It then opens a single documentation-only pull request with its proposed changes. If there's nothing that needs my attention, it merges automatically. If it has a question or needs a decision, it waits for me.

The important distinction is that the gardener works independently of the coding sessions. The agents doing the actual development aren't responsible for maintaining the memory they're using. That job belongs to a separate process that can look across all the sessions and keep everything consistent.

I recently watched an Anthropic presentation on context engineering that described a very similar approach. It was reassuring to see that I'd arrived at much the same architecture independently. The speaker discussed the problems that emerge when multiple agents share a common body of knowledge: conflicting edits, outdated information, and agents that are too focused on their immediate tasks to maintain their own memory.

I'd run into all three.

One week I found two agents on separate branches independently rewriting the same status file. Each thought its version was current. The solution was to establish a single writer for every shared file. Individual sessions can leave debriefs, but they never directly modify shared documentation. Those changes go through the gardener and a pull request.

Anthropic calls its background memory-maintenance process dreaming. I understand the analogy, but I've always preferred gardener.

Dreaming suggests something happening inside the mind, where memories are consolidated and connections are made. What my process does feels a little more practical: it prunes, organizes, reconciles, and occasionally pulls out something that's been growing in the wrong direction.

The results are in the accompanying graphic.

I still review the work. I still test every preview. But increasingly, my role is to provide direction rather than repeatedly correct mistakes or reconstruct context. My first messages in a session are shorter, and I'm spending more time telling the agent what I want it to accomplish than explaining what I expect it to already know.

The session context harness currently consists of 11 skills, 5 agent prompts, 3 hooks, 41 decision entries, and 79 session debriefs. It isn't complicated, but it's made a meaningful difference in how effectively I work with agents on projects.

I'm curious how other people are approaching this. Anthropic calls it dreaming. I've been calling mine the gardener. What do you think describes this process better?

I prefer the gardener. There's something oddly satisfying about building a system that gets a little better every week, even on days I don't open a session.

And if you are interested in Clauding the way I do, with memory, here is a prompt I am providing with instructions on how to implement memory for your own projects: https://github.com/Atreyu8/agent-session-memory