Where an AI agent's knowledge lives

Tobias Studer · 29 Oct 2026 · 4 min read

Our AI agents worked on my laptop for months before they got a machine of their own. Setting up the machine was the easy part. The harder part was finding out what an agent knows when it starts over somewhere else, and where that knowledge lives.

An agent knows what it can read and nothing else. Where something is missing, it rarely asks. It takes the most plausible answer from what it can read and carries on, and the gap shows up later, as work that looks right. Our agents run on Claude Code, and what they can read lives in three layers: git, memory and the session transcripts. Each one moved to the new machine differently, and one problem with our search indexes went through all three.

1. Skills in git move for free, and the agent improvises where they end

Skills are small instruction files an agent loads when a task needs them. Ours live in git next to the code, and one of them carries a knowledge base for Sitecore problems. Clone the repository on a new machine, and the agent there has all of it. Of the three layers, git is the only one that moved without any work.

On its first day on the new VM, the agent found the Sitecore search indexes empty, a problem we had solved before. The guide for setting up the VM pointed it to the fix in the knowledge base, and the agent followed the steps. Then an error appeared that the knowledge base did not describe. The agent called it "a new variant of a known issue" and improvised. It made a required field in the search schema optional, and the indexes started to fill. That was the wrong fix. The agent had probably rebuilt the indexes before Sitecore saw the new schema, and nothing in the knowledge base said to check that.

The skill moved, and the agent used it. Its improvisation marked the one spot where the skill had nothing to say. We then added the missing check. When an agent improvises, fix the result, then write down the line it was missing, so it will do better next time.

2. Memory is an inbox

Memory notes are short files the agent writes when it learns something. They belong to one Claude Code profile on one machine, and a short list of them loads at the start of every session. For the move, we copied them over as files.

The VM's agent wrote its workaround into memory, into the note that already held the right procedure. From then on, every new session started with the wrong fix. A change to a skill goes through a pull request. A note holds what the agent believed on the day it wrote it, and nobody reviews it.

So I treat memory as an inbox. A note catches a lesson the minute it appears, long before anyone writes a skill. Once the lesson matters beyond one profile, it moves into git, where someone reviews the change and every agent reads it. Our search-index lesson ended up in the knowledge base that way. An inbox only works if someone empties it.

3. Transcripts are the only record of what happened

The session transcripts hold every conversation, every tool call and every result. Git keeps the outcome and memory keeps the lesson. Only the transcripts keep the sequence: what the agent tried, what failed quietly, and how long I was involved. For the search indexes, git shows the corrected knowledge base and memory the corrected note. The transcripts show that the agent had the documented steps in front of it when it chose the workaround.

That difference decides the fix. An agent that never found the knowledge base needs a better pointer to it. An agent that followed the steps past their end needs the missing check, and only the transcript tells the two apart.

A new session doesn't load old transcripts, so the agents never miss them. I do. When an agent's work surprises me, I have another agent read the sessions and reconstruct what happened. Our Sitecore knowledge base started that way, mined from previous sessions. That is why we copied the laptop's transcripts to the VM. Claude Code deletes them after 30 days by default, so check that setting before you need an old session.

Summary

An agent knows only what it can read, and a new machine shows exactly what that is. With our search indexes, the agent improvised where the skill ended and showed us the missing line. Memory caught the workaround within minutes and repeated it, unreviewed. Only the transcript shows why it happened, and the why decides the fix. The lesson is now a step in the knowledge base.

A move helped us see some of our gaps, but you don't need one to find yours. Give a fresh agent a clean clone and a real ticket. Where its work differs from yours, its transcript shows what it could not read, and that is the next line for your skills. The next post, "Running a batch of Jira tickets with AI agents: a board, lanes and a runbook", asks where knowledge lives when a batch of tickets runs for days, and why that batch keeps nothing important in a conversation.

🤖

How this post was written. Everything in this post comes from a real project: our skills, our memory notes and our session history. The writing had help. Claude Code, the same agent the story is about, mined its own session history and memory notes for this post and produced a first version in my style. I reviewed every claim, corrected what was off, and rewrote what did not sound like me. Nothing in this post is invented: the work, the failures and the opinions are my own. The header image is AI-generated.