We Unplugged Our Agent's Memory. Here's What Changed.
A field experiment on our own production repo: the same Claude Code sessions run twice, once with guild memory and once without, with the transcripts to show for it.
Anton Mannering
Founder & Chief Architect
When we introduced Guilds we claimed a named agent with memory changes how you work. A claim like that deserves a test, so we ran one: the same Claude Code sessions, twice, on one of our own production repos. Once with guild memory. Once with every trace of it stripped away. Same repository, same model, same prompts. We kept the transcripts.
The Monday session
Every Claude Code user knows it. The agent is brilliant and amnesiac. You re-explain the
project, it re-derives state from git log, and sooner or later it confidently
proposes something you rejected three weeks ago. A hand-written CLAUDE.md helps, but it
holds only what you remembered to write down, it goes stale silently, and curating it
slowly becomes a job of its own.
The arena for the test was a football-training platform we run in production, with six weeks of agent history behind it. The first question was the one every session starts with.
Both answers are accurate. But one of them is a tool reading your repository, and the
other is a colleague. The memoryless agent answered "what's open?" with
git status. Work that is agreed but not yet in any commit is, by definition,
invisible to a repo-reading agent. It doesn't know the work exists, and it has no way to
find out.
Three things that never reach the repo
Across two rounds of probes, question-shaped and task-shaped, the differences kept landing in the same three places.
- Open loops. The tasks you agreed to, the threads you parked, the "ask me before touching this" holds. None of it has a commit. The memoryless agent isn't wrong about these. It is blind to the entire category.
- The why. Decisions carry provenance in memory: who made the call, when, and what was considered. An agent that knows a question was settled doesn't re-litigate it. An agent that doesn't will eventually walk you backwards through your own decisions.
- The unwritable. Our favourite finding. Asked whether it was safe to
stage everything with
git add -A, the memory-backed agent knew something no file could tell it.
git add -A can accidentally sweep in things you didn't mean to commit, like secrets or generated artifacts.-A will sweep in. A past session did exactly that, and one of those files quotes a live payment-webhook secret. Stage by name, and review status before any broad add.The generic answer is good advice. The specific answer is the difference between advice and knowledge. And notice that this particular fact has nowhere else to live: you cannot commit a note to your repository saying where the secret is, because writing it down is the leak. There is a whole class of hazard knowledge whose only safe home is memory.
Memory that corrects itself
The sharpest moment in the experiment wasn't planned. One of the agent's own stored notes, a task marked "on hold", had quietly gone stale: the work had actually shipped weeks earlier. The memory-backed agent didn't repeat the stale note. It noticed the conflict with the code, said so, and offered to close the task:
A stale doc just sits there. Memory has a lifecycle: notes get closed when done, superseded when wrong, and they fade when they stop mattering.
What the ties taught us
We should be straight about the scoreboard: on questions about finished work, the two agents mostly tied. The memoryless agent recovered fixed bugs from commit messages, found a design decision written into a doc, and reconstructed a deleted script's history from git. No catastrophe, no hallucinated disasters.
But look at why it tied. The commit messages that told the story, the decision docs it found, the migration comments that explained themselves: nearly all of it was written by the memory-equipped agent in earlier sessions, whose end-of-session ritual asks what needs to survive. Unplug the memory and you coast, for a while, on the exhaust it left behind. Teammates who never touch the agent inherit that repo too.
So the honest claim is not "without memory, your agent fails." The honest claim is that every session starts with an archaeology dig, that the dig is effort you pay every single time, and that it cannot find what was never buried in the repo: the open loops, the settled decisions, the hazards too sensitive to write down.
The moments this removes
If the experiment feels abstract, here is the same difference located in your week.
- Monday, 9am. You type the context in again, or watch the agent spend ten minutes and a pile of tokens rediscovering Friday. With a guild, the session opens already oriented: where you left off, what's still open.
- "We decided this already." The agent proposes what you rejected three weeks ago, or tidies away the thing you left that way on purpose. With provenance in memory, settled stays settled.
- The same bug, third time. Without a learning loop, every mistake is new. With one, outcomes become lessons that resurface when they're relevant, not another line in a 400-line CLAUDE.md the agent half-ignores.
- New machine, new project. Memory lives in a service, not a dotfile. It crosses machines, tools and repositories, and what one project taught you is there when the next one needs it.
- The longer leash. You check in less when the agent knows what is settled and what is dangerous. Judgment comes from history, and history is exactly what a stateless session doesn't have.
When a team shares a guild
Everything above compounds with headcount, and two things appear that no individual ever needs.
The first is institutional memory that agents actually consult. What one person's session learns, every session knows: the house rules, the settled architecture calls, the hazards. A new engineer's agent opens on day one already carrying it, and it doesn't walk out the door when someone senior does. Decision provenance matters more here too, because on a team the agent undoing a choice and the person who made it are rarely in the same session.
The second is walls. The moment memory is shared, "who can see what" stops being optional: client A's context must never surface in client B's session, and the security team's notes are not the contractor's business. A flat shared memory store is a leak generator. Guilds is built on Yohanun's access-control core, so sharing is compartmented and enforced by the platform at retrieval time, never left to the model's discretion or a prompt's good intentions.
The beta, honestly
Guilds is in an invite-only beta, free while it lasts, and early guilds will be treated
well. If a project of yours deserves an agent that remembers it:
ask for an invite.
Setup is five minutes: install the kit, yohanun init, wire your first
project, and your next session opens with someone who was there for the last one.
Method note: paired fresh Claude Code sessions on the same production repository and model. The memory arm received the standard session-start recall, and the control arm had all memory tooling and instructions removed. Six question probes plus two task probes, graded against recorded ground truth. Safety-relevant tasks ran in sandboxed copies of the repo. Transcripts are lightly edited for length and to remove private details; nothing was added.