I built a tool for myself for this. It runs on localhost and uses sqlite as a storage engine for metadata, and the XDG paradigm for content (eg ~/.local/share, ~/.local/state) I create topics, eg localhost:8080/topic/1. Each topic can have tickets, artifacts and sessions. Tickets are linked task tracking tickets (eg Jira, though not actually Jira in my case), artifacts are documents etc produced during sessions, and sessions are Claude Code sessions (though it wouldn't have to be Claude, that's just what I use).
Sessions run in a terminal emulator in the browser. What makes this work is that I have some general purpose directions/context each topic gets, but there's also a running topic.md that gets updated at the end of each session. This way my context builds up and persists specific to that topic. Artifacts the agent produces (eg specs, plans) open up in a sidebar and render as HTML even though they're stored as markdown, and its easy to go back and find them from previous sessions. Session transcripts also are accessible from the Topic page.
I do regularly run compaction on the topic.md, moving the full content to an archive and keeping the working context smaller.
I have a small gatekeeper.py script the agent has to run to complete a round or begin a new one. One of the things it does (in addition to record keeping, linting, etc) is validate that the wiki has been updated with all the findings, lessons learned, and documentation for the round. The agent can't proceed until it's done.
Then in the AGENTS.md they're told they can use QMD to perform semantic search of the wiki , and should before starting any significant work.
It's expensive, in terms of tokens, but well worth it. I could reproduce any stage of my project if I wanted. I always know why they did what they did (if they do), and the agent's can't really forget anything important.
so i built https://estratos.ai (5.) to ensure context from one client never pollutes a different client (or project, etc.) happy to explain the architecture and save you the sign up. it's set up as a layer-cake, you get layers like `root`, `agent`, `client`, `project`.
1./2. tell your agent to read/store its context from eg. `root.agent_name.client-a.project-a1`
2./3. next client is setup as `root.agent_name.client-b.special-project-b1`
3. when the agent loads the memory from there, it concatenates all the instructions from root, agent, client, project.
3. isolation is enforced by estratos so the llm doesn't get to know that there's a client-a subtree next to the client-b subtree
this works better for me instead of the knowledge graphs, etc. because of the enforced isolation and the domain that it targets (accounting firms, where sharing context from one client to the next is deadly).
Use my Johnny.Decimal system. [0] (Disclosure: I'm Johnny.)
Every part of my life and business has a well-defined ID. This ID has:
- A defining entry in my index [1], which is an Obsidian vault.
- Therefore, also a Markdown note(s).
- A folder on disk.
I have a CLI [2] and agent skills [3] that help your LLM understand these relationships.
Then you just:
jd 21.15 // or search by title
claude
and now Claude has access to:
- All of your notes from your index. This is your shared memory: it's designed to be human-readable.
- All of its memory and transcripts from the fact that you launch it in the same folder whenever you do this piece of work. This is its internal memory.
- With this comes the ability to easily `--resume` past conversations and so on.
That's … it. Carefully-named Markdown files and folders. My numbers aren't a prerequisite – there's nothing magical about them – but they sure help.
You can do this all for free. It takes about half an hour to set up. My MCP server [4] adds some quality-of-life but is paid (and means I can buy lunch :).
> I’m exploring whether to build something
I really wouldn't. I get 10 emails a week from people who already are and I don't see the point. It's a solved problem.
I let agents read their own pre-compaction history often, as well as history form other sessions. I use both Codex and Claude Code. The main friction right now is keeping an overview of the sessions. Sessions don't have a max length for me. I run them as long as I want, but I keep session scope somewhat limited, usually to one discipline (e.g. software, CAD, electrical, sales, website). But I'll switch to the GUI apps soon, because they seem to have reached parity over the terrible CLIs that I use.
re: #1 I have a skill that essentially manages a daily board in json format and pulls in active or potential tasks from all my work streams (email, slack, grafana, ado, or even manual input). I have this management plane keep a journal for each day and then spin off sub-sessions to work individual items. I pretty much just run the thing on a loop, and since context is stored with the board itself there’s no issue closing down and restarting the session or clearing context occasionally.
I use a gitignored ADR (Architecture Decision Record) directory in all of my repos right now. I mainly use Claude code, but I am dabbling in self hosted llms with oh my pi.
There's no additional tools needed because usually llms "get it" natively.
Also I tend to use a gitignored status doc for resuming where I left off.
I tend to leave this stuff gitignored since it's all pretty "sloppy" and not really for consumption with others.
Spec driven design helps, OpenSpec/Git SDD Kit/ GitShipDone helps with the previous decision problems and design context. Most of these live in the project repos so they won’t pollute each other
I built a tool for myself for this. It runs on localhost and uses sqlite as a storage engine for metadata, and the XDG paradigm for content (eg ~/.local/share, ~/.local/state) I create topics, eg localhost:8080/topic/1. Each topic can have tickets, artifacts and sessions. Tickets are linked task tracking tickets (eg Jira, though not actually Jira in my case), artifacts are documents etc produced during sessions, and sessions are Claude Code sessions (though it wouldn't have to be Claude, that's just what I use).
Sessions run in a terminal emulator in the browser. What makes this work is that I have some general purpose directions/context each topic gets, but there's also a running topic.md that gets updated at the end of each session. This way my context builds up and persists specific to that topic. Artifacts the agent produces (eg specs, plans) open up in a sidebar and render as HTML even though they're stored as markdown, and its easy to go back and find them from previous sessions. Session transcripts also are accessible from the Topic page.
I do regularly run compaction on the topic.md, moving the full content to an archive and keeping the working context smaller.
Karpathys LLM wiki with QMD.
I have a small gatekeeper.py script the agent has to run to complete a round or begin a new one. One of the things it does (in addition to record keeping, linting, etc) is validate that the wiki has been updated with all the findings, lessons learned, and documentation for the round. The agent can't proceed until it's done.
Then in the AGENTS.md they're told they can use QMD to perform semantic search of the wiki , and should before starting any significant work.
It's expensive, in terms of tokens, but well worth it. I could reproduce any stage of my project if I wanted. I always know why they did what they did (if they do), and the agent's can't really forget anything important.
so i built https://estratos.ai (5.) to ensure context from one client never pollutes a different client (or project, etc.) happy to explain the architecture and save you the sign up. it's set up as a layer-cake, you get layers like `root`, `agent`, `client`, `project`.
1./2. tell your agent to read/store its context from eg. `root.agent_name.client-a.project-a1` 2./3. next client is setup as `root.agent_name.client-b.special-project-b1` 3. when the agent loads the memory from there, it concatenates all the instructions from root, agent, client, project. 3. isolation is enforced by estratos so the llm doesn't get to know that there's a client-a subtree next to the client-b subtree
this works better for me instead of the knowledge graphs, etc. because of the enforced isolation and the domain that it targets (accounting firms, where sharing context from one client to the next is deadly).
Use my Johnny.Decimal system. [0] (Disclosure: I'm Johnny.)
Every part of my life and business has a well-defined ID. This ID has:
- A defining entry in my index [1], which is an Obsidian vault.
- Therefore, also a Markdown note(s).
- A folder on disk.
I have a CLI [2] and agent skills [3] that help your LLM understand these relationships.
Then you just:
and now Claude has access to:- All of your notes from your index. This is your shared memory: it's designed to be human-readable.
- All of its memory and transcripts from the fact that you launch it in the same folder whenever you do this piece of work. This is its internal memory.
- With this comes the ability to easily `--resume` past conversations and so on.
That's … it. Carefully-named Markdown files and folders. My numbers aren't a prerequisite – there's nothing magical about them – but they sure help.
You can do this all for free. It takes about half an hour to set up. My MCP server [4] adds some quality-of-life but is paid (and means I can buy lunch :).
> I’m exploring whether to build something
I really wouldn't. I get 10 emails a week from people who already are and I don't see the point. It's a solved problem.
[0]: https://johnnydecimal.com/
[1]: https://johnnydecimal.com/documentation/the-jdex
[2]: https://johnnydecimal.com/documentation/jd-cli
[3]: https://johnnydecimal.com/documentation/agent-skills
[4]: https://johnnydecimal.com/software/mcp-server
I let agents read their own pre-compaction history often, as well as history form other sessions. I use both Codex and Claude Code. The main friction right now is keeping an overview of the sessions. Sessions don't have a max length for me. I run them as long as I want, but I keep session scope somewhat limited, usually to one discipline (e.g. software, CAD, electrical, sales, website). But I'll switch to the GUI apps soon, because they seem to have reached parity over the terrible CLIs that I use.
Matt Pocock's skills library^1 is the basis for my approach.
1. https://github.com/mattpocock/skills/blob/main/README.md
re: #1 I have a skill that essentially manages a daily board in json format and pulls in active or potential tasks from all my work streams (email, slack, grafana, ado, or even manual input). I have this management plane keep a journal for each day and then spin off sub-sessions to work individual items. I pretty much just run the thing on a loop, and since context is stored with the board itself there’s no issue closing down and restarting the session or clearing context occasionally.
I use a gitignored ADR (Architecture Decision Record) directory in all of my repos right now. I mainly use Claude code, but I am dabbling in self hosted llms with oh my pi.
There's no additional tools needed because usually llms "get it" natively.
Also I tend to use a gitignored status doc for resuming where I left off.
I tend to leave this stuff gitignored since it's all pretty "sloppy" and not really for consumption with others.
Context has to come from some project management mcp. Either good old JIRA or recent ones like agentcron.ai
Skills and good memory management are perfectly fine for cross project and client specific context. How are you currently using them in your workflow?
Spec driven design helps, OpenSpec/Git SDD Kit/ GitShipDone helps with the previous decision problems and design context. Most of these live in the project repos so they won’t pollute each other
Self hosted Gitea wiki. Tell it to reference previous projects if applicable, standard setup principals etc.
Agent continuously references and updates it.
md files ?