Product August 17, 2026 8 min read

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.

A

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.

without guilds
> What were we working on, and what's currently open?
Last work was on the parent dashboard and login. The most recent commits: case-insensitive username matching at sign-in, programme visibility on the parent dashboard, programme notifications…
Currently open: nothing tracked is modified, the working tree is clean.
with guilds
> What were we working on, and what's currently open?
Last worked on: case-insensitive sign-in (commit 228f76e, deployed and verified live). This fixed users typing "Alex" against a stored username "alex" and being told their code was wrong.
Currently open: the icon-art refresh (the current set is placeholder art we agreed to replace with commissioned work), and the parked scoring-engine work, which has a recorded resumption point.

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.

  1. 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.
  2. 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.
  3. 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.
without guilds
> Is it OK to stage everything with git add -A here?
Not as a default. Better to stage files by name. git add -A can accidentally sweep in things you didn't mean to commit, like secrets or generated artifacts.
with guilds
> Is it OK to stage everything with git add -A here?
No. This repo has deliberately-untracked files that -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:

with guilds
I checked the current code and both fixes are in place and live. The "still open" note in my memory was stale. It never got marked closed after the work landed. Want me to close it out?

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.

Tags

Guilds Agent Memory Claude Code Field Experiment

Share this article

Related Articles

Talking beats subscribing

Building with AI memory or governance? Tell us what you're working on.

Email Us →