Hi Guys,
like many of you I work with AI agents every day and across several clients.
The major time cost for me is to re-explaining context and past decisions, client rules, that we already do. To finish every tools as its own memory.
So I’m curious how you actually handle this:
1. When you start a new session, how do you give context to the agent (context came from chat, mail, ticket ...) ?
2. Do you use more than one agent type (claude, codex ...) ? And if yes, how do you carry context between agents ?
3. If you work for several clients, how do you keep their context separate ?
4. The last time something went wrong ( an agent used a rejected approach, forgot a decision ...), what happened, and how much time did it cost to you ?
5. Did you paid or built a tool that helped you with these problems ? Do you still use it ?
I’m exploring whether to build something, so I’m trying to learn how other people really work.
Thanks for your return.
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
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 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.
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 recently experimented with breaking my life into segments (like the reporting segments of a company) and organizing Dropbox, text journals, and Claude chats in accordance with those segments. What you are describing is far more advanced and I'm intrigued. Checking out the site now.
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.
Re:
by spockz on Monday November 09, 2026 @02:33AM
(#50422279)
I’ve been trying to get something similar to work with local markdowns instead. Getting them to write something is easy. But I cannot reliably trigger them to write when they make “sufficiently important” decisions. There is little self reflection (or actual intelligence).
How do you get them to trigger writing to the log in the right moment and manner?
The karpathy wiki is really just local markdown at its core. The semantic search qmd provides is really the fancy bit.
My system is fairly elaborate, but the simple trick is to build the loop so they have mechanical checks that prevent anything from counting as done until it meets standards. There are many ways to do that. A lot of folks just hook specific tool calls and make it output relèvent instructions.
In my loop I use an Orchestrator and a Builder sub agent. The Orchestrator assigns the Builder work from the spec one phase at a time. The Builder has to build each phase with red then green unit tests as specified by the Orchestrator. The Builder sub agent only knows that one task. It can't consider the task finished until gatekeeper passes.
Gatekeeper is a simple python script that the Orchestrator is allowed to update whenever it sees an anti-pattern. It validates that all the unit tests pass, that it HAS sufficient test coverage, that it lints properly (including custom rules the Orchestrator can add for repeated failure), that the docs exist for that phase and are long enough, and finally does some ast grep searches for common goofs, etc.
Sometimes the builder will have to try many times before it passes, but each time it fails gatekeeper outputs an instruction telling them which rule they violated and the full requirements.
Eventually gatekeeper will pass and the Orchestrator does a final review before assigning the next phase to a new Builder. The most common failure at this point is poor unit tests that don't test for the right thing. The Orchestrator has explicit instructions to check for that and does catch it most of the time.
Re:
by cpinto on Sunday November 08, 2026 @10:36PM
(#50420745)
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).
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.
Re:
by akst on Sunday November 08, 2026 @10:54PM
(#50420885)
When I start a new project, I point to other ones where I'm happy with the quality as exemplars. I think its probably simpler to copy relevant stuff allow older projects go out of date until I start working on them again, then I tell the agent to look at the newer project to update its style.
I have 2-4 on going projects I tend to a bit of that, normally 2 at a time, when I pick up one of the others, I really just do that; point to the older one.
But within projects I don't really try to manage context, more so I just have an issue tracker which I add to keep track of stuff. In 2 of my long running projects I have some bootleg issue tracker built in (along with a screenshot QA tool which sends issues to the tracker) into the UI of the tool.
I guess to extent I can, I try to avoid keeping some preferences in the context like formatting and linting (including directory structure and white listing imports in certain parts). I've been trying to find more ways to automate that way, so I keep my prompts and skills and goals limited to objectives where possible, so preferences like styles and structure are automatically enforced.
When I have multiple agents, I just tell them to maintain write only ledgers to coordinate to avoid overlapping work, but it's easier when your project is broken up into self contained components with communication boundaries (defined in protobuf) like a FE/BE split or seperate service codebases (I reassemble it as a google style modular monolith to avoid running too many processes)
It seems many have built similar tools for solving this.
Mine lets me run Claude and Codex (and pi but then you have to pay API rates) from the same localhosted webserver, and also schedule feature implementations to always hit the weekly usage cap. chats logs in jsonl (used by both) are saved per project in a never-pushed git branch. All agents run in Podman containers.
I am just starting to play with a higher-level agent that just pushes the repo in a direction based on the human answering a thorough list of clarification questions.
These have been really useful
- Encourage short, commit-linked chats, to avoid the expensive cache writes.
- Plot of LOC over time. Use better models until this starts not spiking a ton with every new feature.
- Terminals kinda suck for agentic stuff IMO and we should stop cramming agent loops into them. Minimalism doesn't really help here, it's really nice to have built-in STT, real buttons, easy scrolling, etc etc etc.
- The minimal delta is a commit. Every implementation turn must end with one or multiple, and a clean worktree.
- Crystal clear, extremely granular usage data. This is something Claude Code and Codex will never give you, instead you get dark patterns nudging you to forget about the spend, while changing plan quotas every couple weeks.
Here is a good suggestion: try using OKF (Open Knowledge Format) to store your context. Log every transaction in the OKF format as you process tasks. Even if you change your AI, simply reading the OKF file will do the trick.
As many have said - my strong steer build something[^1].
There are _great_ tools for this, but the biggest part of this is managing your own attention, and mental load. You can craft something that really helps _you_ manage all the spinning plates.
In the case of my harness, I hoover up all the PR state into one place and then have a bunch of rules on how I interact with them (or not). Even down to a "swipe right to merge" card system. Works for me.
My recommendation: A cloudflare PWA fully vibe coded with zerotrust on the front. Don't get too attached, tools are changing fast. Make it work and be prepared to ditch it when something better comes along.
I keep my agents strongly sandboxed from each other using byre[0] (of which I am the author). I then use chezmoi[1] to manage my byre config -- including instructions for every box -- across multiple physical machines: shared instructions, tool preferences, etc
I haven't used an AGENTS or CLAUDE file as much lately. I'm not sure how much more it helps, but generally I try to have one or more project md files. These are curated to whatever I am currently working on. Perhaps references to certain modules, commands, schemas for DB, etc.
This way the agent doesn't get too much context it doesn't necessarily need.
Again, not sure how much more effective or efficient it is but it seems to do better for my needs at least.
I made a database that is based on the old school IBM1401 punchcard system, and set a wake phrase which works in the IDE's MCP so that the state is held with just a couple hundred tokens being used to wake and continue the work!
I use multiple agents, and they all use the same database to maintain continuity. It allows me to use more than one at a time if needed(I do research) or switch between turns depending on the output required. I am using the Gemini's right now, but have used all the LLM's an a few smaller local models.
I keep the clients context separate in different directories is all. My main agent works on all my projects.
Last time something went wrong... agent said task was complete and verified but when I checked it was not "working" as planned. I suggested that there was a possibility of a reason, and my agent fixed it next run. Cost me 7 mins or so. I keep an eye on everything they do so things going wrong are typically easy fixes.
I built it using my agents, and use it all day everyday. :-) The db has some other features I built in like a context odometer and a cabinet if workflows so I dont have to teach it stuff every time.
I feel your pain, and hope you find a solid solution!
Re:
by lp92 on Monday November 09, 2026 @12:54AM
(#50421570)
For the application I'm working on right now, I have tons of documentation. Every feature and even bug fixes have a TDD, FDD, Implementation Plan and/or RCA document in Markdown format. And these are grouped under logical sub folders.
I also maintain a up to date master System Architect and Design document. Oh and a master index document listing every file along with a brief overview of the file.
Currently I’m not collaborating with people a lot, so I use helpful plugins like Kanban to organize tasks.
This helps me stay in the loop about projects and tasks, since Claude can create requirements.
A friend of mine recently built campus [1] and while I personally haven’t gotten to use it, I’m currently trying to rebuild it as an obsidian plugin, which I hope will further help me stay organized.
3. If you have separate clients, I would use a different username/login for each client so session transcripts (like in ~/.claude/... are segregated.
4. The more slack I give to agents, the more likely a session's work will have to be discarded. TPP (and looking at them before implementation starts) help avoid these very-off-course sessions from happening at least in my experience.
5. I've been iterating on coding and reviewing skills, and also just released the local reviewboard/PR tooling I've been using for the past couple of weeks. Everything is open source: fork and tweak to your content.
i find the best way to think about this (and build around it) is to think how we as humans learn by doing: we have an idea of what to do (plan), then do, and then learn from what we did (right or wrong). you can also extend this to the entire team/company through what's usually called "institutional knowledge".
here is how i approach it in practice:
i've seen many try to generalize rules before doing things (design principles, guidelines, architecture,...) but often the best way is to start small, guide the agent step by step and (this is the most important part) at the end ask the agent to summarize what it learned and write it down.
then on the next cycle, ask the agent to read the previous notes and do this again: read, do, write.
i've been doing this for about 14 months now and have ended up with 2 categories of "knowledge": general (runs across multiple projects) and specific (per project).
these are kept in two formats: markdown and "decision records". each decision is a markdown but has meta data around its state: approved, rejected, failed, etc.
this growing body of knowledge works very similar to experience.
one note about agent memory: first i find it opaque, secondly not sharable across team members, and thirdly not very human friendly (basically as the agent does more, you learn less about your own project due to the opacity of the memory).
when i started this system, i used a committed markdown in git, then moved it to an obsidian (with MCP), then to Notion (so it's available team-wide) and finally built a product around it (bench47, if you care to check it out, disclosures, etc)
Re:
by nilleb on Monday November 09, 2026 @01:19AM
(#50421760)
Hi!
5) To solve this problem I wrote Varda (https://github.com/nillebco/varda). I use it all the time.
1) the context is supplied per policy - a certain directory tree or folder has a certain context
2) yes. But I use a certain agent for a certain customer - their rules. It's interesting as a use case, but requires some work because the agents don't have the same formats. If I had to do this I would leverage omnisess - https://GitHub.com/psacc/omnisess
3) each customer has different policies right? So this is a policy in Varda : a certain directory tree is allowed to use only a certain agent.
4) the last time something went wrong it costed me a container with a sample database. Since last Friday we have firecracker escape vulnerabilities so this might be way worse
(Varda was born to track work across projects and enforce agents selection and orchestrate tasks then evolved to include sandboxing leveraging msb and docker)
I hope this helps! And any feedback or pull request about Varda IS very welcome!
1. Just a single sentence idea or even copying the relevant messages from chat or email. If you are using Jira or similar, this is where MCP gets useful.
2. Only Claude at the moment
3. Each has its own repo and own CLAUDE.md/AGENTS.md file. The CLAUDE.md file is just a lookup document.
The detailed project specific markdown are under the rules folder, e.g. "forms-and-dialogs.md", "roles.md", etc. These rules are always updated by the agent for all new features/bug fixes, etc.
I also instruct the agent to always keep detailed markdown in the docs folder, which is subdivided into: idea/plan/review. These get created when new features or other significant updates are implemented.
4. The agent so far has not failed to reference the above files, so it already knows what approach to do when working on a new task.
5. I built my own skills framework for this (inspired by Superpowers) and still using it.
1. Skills and different profiles. I use clai[0] where I run one custom made profile per task.
2. For this I use slivingdoc[1], a MCP server which syncs context as plain text (with s3 as backend, or hosted for free up to 1 GB). So regardless of which agentic harness I use, I bring along the relevant context.
3. I use different slivingdoc spaces per customer
4. I keep sessions short and concise enough that it's not an issue.
5. I built all of my tools from scratch to fit my own workflow. But it's open source, if anyone wants to try it out.
Re:
by cmrx64 on Monday November 09, 2026 @01:30AM
(#50421842)
I use https://github.com/emberian/cv all day every day for slicing and dicing agent transcripts. Streaming/in-place when possible, supports all the harnesses, indexing and search as well with tantivy. Custom pruning and compaction saved 40% of tokens in one recent evaluation of a homelab’s adoption of cv.
I built this that allows you to lock any folder on your machine to a context scope. Then it auto switches to that context scope when you start a session in any folder. It works across Claude, codex, etc.
Tell claude to do 1-5. I have it doing a mysql db on all prompts and it can recall any "type" of conversation. A github repro is hilarious, just prompt it.
Re:
by dools on Monday November 09, 2026 @01:55AM
(#50422003)
When you say "context" do you essentially just mean skills? Like everything that goes to an agent is prompt right? So you want to know how we are managing a library of prompts (which the industry calls skills) so we don't type the same thing over and over?
It's a git backed tool with a custom protocol that can be externally accessed over a Cloudflare tunnel.
You an connect your sm client to any endpoint, and each endpoint runs a server inside a git repo, so you can have as many separate instances per client as you like, just switch your ~/.skillzmouse.json file and it will point to a different server.
It also has a script distribution and patching system. Skills and scripts constitute what I would refer to as my "standard operating procedures" which broadly transcend harness (and I have used this with multiple harnesses).
It "plugs in" by including a header at the top of AGENTS.md that tells the agent how to use it, and the first step is for the agent to load the agents skill, which is a bunch of stuff applicable everywhere, and then that also builds the skills header describing the list of skills, and then skills can refer to libs which are not listed and can be loaded on a case by case basis.
I am not using it with multiple harnesses anymore though because I built a harness, which integrates skillzmouse and has "factory workflows" that are loaded as skillzmouse scripts. My harness can be described as "deterministic control of intelligent agents", ie. the agent can't spawn sub agents, the agents can't talk to each other, and the workflow scripts can build and pass context in a deterministic way between sessions that are created during the execution of a given workflow.
But you could use skillzmouse in any harness. I've used it in pi, Junie and Kimi Code. Junie CLI had problems with compliance.
Re:
by rcarmo on Monday November 09, 2026 @03:11AM
(#50422577)
I have a thing called Memento (https://rcarmo.github.io/projects/memento) that all my agents use to share skills and some cross-project notes, but in general most project-related context lives on SQLite someplace with some FTS. I built a little CRM skill that handles most project interactions just fine, and you can go a long way with well organized Markdown (or a shared Obsidian vault) before you start over-complicating things.
I had a similar issue with having to juggle multiple different projects. I found the key thing is to manage your time better and have an agent per project or sub-project with a manager agent you talk to. I wrote my own system to manage this https://github.com/mhalstrom/maximizepm feel free to try it, take the good parts for your own system or whatever
AGENTs.md
there is a dir local, todo is ..., done is ...
CHANGELOG.
all things happen in each version this repo. if ai slop is inevitable, just let them in one place.
omp session 1(worker):
a work session. read the task md or just direct simple prompt. auto compact context.
omp session 2(planner):
a plan session. only write md to todo.
good code is the best doc for agent.
why need planner: some idea is really not mature to assign to worker. but we can freely talk to planner.
why no more sessions: the cost of communication > the benefit of it.
Thank you guys! This thread gave Google AI Studio some much needed inspiration!
=================================
My prompt describing the problem:
:( Google has become such a scummy business these last years. It's gross.
Back to the other problem: uploading documents and have the agents works with them.
I'm used to ChatGPT and while I hate it doesn't contain documents from other Agents, it does 1 thing very well: I upload a binary with file(s) and ChatGPT's Agent KNOWS about those files and will read the files whenever it is needed. It has a very strong conceptual memory of what data has been given and can be used.
Google AI Studio is a mess though. As I understand yesterday's troubleshooting, each Agent needs to "cat >>" its information and contents in full to the Agent's prompt, otherwise it does not know what to do with those files (let alone analyze and use them).
Your last suggestion was to add, among other things, an index file with both copies of unreachable online sources and copies of the Inspiratie documents.
That is a start but still sounds prohibitively expensive. Is there a way to approach ChatGPT's way of working? We upload files and the agent will start sniffing around in them once it is ready to do so. Do you have any solutions? I also found this page, it might inspire you with new solutions: https://news.ycombinator.com/item?id=50403153https://news.yc... . Also feel free to do your own online research.
Your current solution sounds bizar. Analyse, advise and reply in full :)
=================================
The remaining comments from your Hacker News thread (item?id=50403153) just came through as well—here are the standout patterns from those comments that directly apply to your legal multi-agent workflow:
The "Lookup Table" Pattern ([marvstazar]):
"Each has its own repo and own CLAUDE.md / AGENTS.md file. The AGENTS.md file is just a lookup document. The detailed project-specific markdowns live in subfolders... The agent reads the lookup document first and only pulls the detailed markdown file it needs for the current task."
The "Couple Hundred Tokens to Wake & Continue" Pattern ([MadBrad-Develop]):
"I use multiple agents, and they all use the same database to maintain continuity... the state is held with just a couple hundred tokens being used to wake and continue the work! I keep the context separate in different directories is all."
Write-Only Ledgers & Decision Records ([ksajadi] & [akst]):
"Follow the read, do, write cycle EVERY TIME... kept in two formats: markdown and 'decision records' (approved, rejected, failed). When I have multiple agents, they maintain write-only ledgers with strict communication boundaries."
Summary of What We Can Build for Your Program
Instead of "cat >>"-ing 65 KB–240 KB of your 3,608 files into every prompt:
A ~500-token Lookup Manifest (DOSSIER_LOOKUP_MANIFEST.md) is passed to the Agent at the start of a block (categorizing your uploaded archives into folders + top primary files).
Server-Side Agentic File Sniffing Tools (search_dossier_files, read_dossier_file, list_dossier_directory) let the Agent actively search across all 3,608+ uploaded files on the server disk and read only the specific documents it decides to inspect—just like ChatGPT's file sandbox—while enforcing strict per-agent container isolation (v0.0 .. v9.99).
Just say the word if you'd like me to build this into server.ts and the Agent Console!
I really hate that once you reply in full, all your reasoning disappears. Your reasoning contains crucial information I need to track your thinking and catch any mistakes. Offer me a solution so I can always have an easy way to read back what we said, what you thought and what your replied.
We don't allow LLM-generated content in HN comments, so this comment is inappropriate from the start...
But the whole flow here - asking for help, then siccing your LLM on the responses, instead of reading them and engaging in the discussion. This is exactly why people are questioning whether working with AI is leading to people losing the ability to stop and think through their problems independently.
I'm sure there are some people in the community who see no problem with this, but it just feels "icky" to me, for lack of a better technical term.
Re:
by tasuki on Monday November 09, 2026 @08:22AM
(#50425242)
That's difficult. Agents create too much documentation. They document everything, including things which are obvious and don't need documenting, and irrelevant facts from the past.
Now I have them split things between "current" which should be kept clean, and "history", where they can give way to their graphomania. Sometimes the history is even useful.
1: Before closing last session, just say "prep a handoff so we can resume from here in a fresh session" then in new session just say "check your handoff and lets continue".
I keep a separate knowledge base per client and let the agent retrieve from that, instead of pasting everything into the prompt. Much less re-explaining, and no mixing up clients
1. I have a custom meta-harness on top of existing coding harnesses to handle this - this orchestrates at both task level and handles other things which are non-existent in the existing harnesses. I don't daily drive the underlying tools - but my own tool first -> these tools.
2. Yes. See 1.
3. Tagging and profiles / see 1 and 2. Custom zettlekasen-style WIKI that the agents can modify.
4. Too much reworking. I've come up with a custom hook-based memory implementation where when I swear things - it feeds into an improvement. I track number of times I have lost my shit. Over time it has gone down but still not at the level that I want. (4 months since heavy cc use)
5. I dogfood on the tool to build features for itself - mostly to solve my own problems / frustrations of working with coding agents (TLDR - I hate working on them but the tool makes them bearable). Using other skills etc. might be another way like poteto - but I don't think that helps because ways of working and thinking are encoded in these - so I prefer to write my own skills / procedures and use them. I don't think paying for anything will solve the problem preciesely because of this. But my meta-harness is probably a lot complete.
I built https://pribrain.com for this and I'm happy to share a free trial with anyone who's interested.
Effectively I just need to connect the MCP and set the preferences/rules in the agent (codex, claude, opencode, etc.) to: "Read instructions and rules from PriBrain before doing anything." Its pricing is targeted at startups/SMBs, not freelancers, though (but we could arrange something if you're interested).
You can achieve a similar result with a markdown file and change "PriBrain" to that file path, then you just need to manage the core rules/instructions in a single place.
A great thing I leverage with PriBrain is using different PriBrain accounts per client, so each agent only gets the core rules/information for each client.
To your specific questions:
1. Just what's necessary. If it is a long wall of text I'll finish with "Read PriBrain first." just to make sure that initial instruction won't be ignored, because sometimes Claude and Codex will ignore them.
2. Yes. Similar answer, the shared brain.
3. I use separate Spaces (think of them as directories or some other kind of taxonomy).
4. Happens many times, but it's not related to the shared brain and that's why I verify work.
5. I used gbrain before and it still caused a lot of hallucinations, so I built my own solution.
Re:
by zaterka on Tuesday November 10, 2026 @11:49AM
(#50442899)
I've been trying different approaches to tackle agent memory across different sessions, without bloating context and increasing token spending.
I was using LLM Wiki for a while, it seemed to work well but when I decided to measure token usage, I ran into a surprising +23% in token usage (model was often double checking or query was finding more matches than intended).
I also tried static graphs for codebase structure, like graphify, and saw a +5% increase in token usage in the same benchmark.
It's a simple rust application that build a knowledge graph on top of the LLM wiki, with metadata that helps the model navigate through the markdown files, tracking files that are up to date and the structural relationships inside the project. It also led to -30% token usage on the same benchmarks both LLM Wiki and graphify increased the token usage.
For managing context between different teams, I use my memory by project, so personal and professional work is kept separate, and I just reuse templates as needed (for agent prompts for example).
Re:
by elviric on Tuesday November 10, 2026 @12:06PM
(#50443138)
I ask the primary agent ( claude / codex / gemini ) to create a promote to generate an AGENT.md which must be read by all the agents which is working on the project workspace.
And having strict ADR and syncing of docs and recording the milestones did help me when toggling between the agents.
- I'm currently using Sentry's dotagents to share skills and pin versions
- I avoid a centralized "single brain" and instead have started a "knowledge" directory in each repo. I copy relevant learnings in so stuff stays isolated
- I use an OSS tool from my company to turn anything that could be enforced by code into something that can be enforced by code (keeps the markdown files leaner)
- My daily driver is cmux with a silly amount of sessions, so I'm constantly throwing away sessions and keeping context small
Re:
by valado on Wednesday November 11, 2026 @01:59AM
(#50450464)
My biggest problem with that setup was to keep skills etc in sync across projects.
That’s why I started using https://yarkr.com to distribute and synchronize them automatically.
I use a single Knowledge Base as the starting point of each and every AI session.
That knowledge Base doubles down as an Obsidian vault in which I also have various databases, plugins, etc).
My knowledge base contains notes about my goals, projects, tasks, products, ideas, etc. It also contains my articles (dsebastien.net), my tools and infrastructure, my open source and private projects with their repositories, specific instructions for each, etc.
In addition, I have built tools to help understand the taxonomy/ontology of my knowledge base, know which types of notes exist, which properties, which template to use, where to store what, etc.
On the human side, everything is automated, which lets me capture efficiently. On the AI side, all the knowledge is easy to find and leverage.
The whole knowledge base is like composable context for AI.
I can start sessions with sentences like "let's work on the music practice plugin; add xxxx" and AI will understand what project it is, where to find the sources, where to clone or update the repo on my machine, etc. And from the context within the repository itself, it will then know how the code is organized etc. The nice thing is that this also enables me to work on multiple projects in parallel easily; either in different AI sessions, or in a single session for work that spans multiple projects/repositories. For instance I have a repo which a product, another with the product documentation. When I ask for something in the context of that project, AI works seamlessly on both.
So I’m curious how you actually handle this:
1. When you start a new session, how do you give context to the agent (context came from chat, mail, ticket ...) ?
2. Do you use more than one agent type (claude, codex ...) ? And if yes, how do you carry context between agents ?
3. If you work for several clients, how do you keep their context separate ?
4. The last time something went wrong ( an agent used a rejected approach, forgot a decision ...), what happened, and how much time did it cost to you ?
5. Did you paid or built a tool that helped you with these problems ? Do you still use it ?
I’m exploring whether to build something, so I’m trying to learn how other people really work. Thanks for your return.
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.
1. https://github.com/mattpocock/skills/blob/main/README.md
Agent continuously references and updates it.
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 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.
How do you get them to trigger writing to the log in the right moment and manner?
My system is fairly elaborate, but the simple trick is to build the loop so they have mechanical checks that prevent anything from counting as done until it meets standards. There are many ways to do that. A lot of folks just hook specific tool calls and make it output relèvent instructions.
In my loop I use an Orchestrator and a Builder sub agent. The Orchestrator assigns the Builder work from the spec one phase at a time. The Builder has to build each phase with red then green unit tests as specified by the Orchestrator. The Builder sub agent only knows that one task. It can't consider the task finished until gatekeeper passes.
Gatekeeper is a simple python script that the Orchestrator is allowed to update whenever it sees an anti-pattern. It validates that all the unit tests pass, that it HAS sufficient test coverage, that it lints properly (including custom rules the Orchestrator can add for repeated failure), that the docs exist for that phase and are long enough, and finally does some ast grep searches for common goofs, etc.
Sometimes the builder will have to try many times before it passes, but each time it fails gatekeeper outputs an instruction telling them which rule they violated and the full requirements.
Eventually gatekeeper will pass and the Orchestrator does a final review before assigning the next phase to a new Builder. The most common failure at this point is poor unit tests that don't test for the right thing. The Orchestrator has explicit instructions to check for that and does catch it most of the time.
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).
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 2-4 on going projects I tend to a bit of that, normally 2 at a time, when I pick up one of the others, I really just do that; point to the older one.
But within projects I don't really try to manage context, more so I just have an issue tracker which I add to keep track of stuff. In 2 of my long running projects I have some bootleg issue tracker built in (along with a screenshot QA tool which sends issues to the tracker) into the UI of the tool.
I guess to extent I can, I try to avoid keeping some preferences in the context like formatting and linting (including directory structure and white listing imports in certain parts). I've been trying to find more ways to automate that way, so I keep my prompts and skills and goals limited to objectives where possible, so preferences like styles and structure are automatically enforced.
When I have multiple agents, I just tell them to maintain write only ledgers to coordinate to avoid overlapping work, but it's easier when your project is broken up into self contained components with communication boundaries (defined in protobuf) like a FE/BE split or seperate service codebases (I reassemble it as a google style modular monolith to avoid running too many processes)
Mine lets me run Claude and Codex (and pi but then you have to pay API rates) from the same localhosted webserver, and also schedule feature implementations to always hit the weekly usage cap. chats logs in jsonl (used by both) are saved per project in a never-pushed git branch. All agents run in Podman containers.
I am just starting to play with a higher-level agent that just pushes the repo in a direction based on the human answering a thorough list of clarification questions.
These have been really useful
- Encourage short, commit-linked chats, to avoid the expensive cache writes.
- Plot of LOC over time. Use better models until this starts not spiking a ton with every new feature.
- Terminals kinda suck for agentic stuff IMO and we should stop cramming agent loops into them. Minimalism doesn't really help here, it's really nice to have built-in STT, real buttons, easy scrolling, etc etc etc.
- The minimal delta is a commit. Every implementation turn must end with one or multiple, and a clean worktree.
- Crystal clear, extremely granular usage data. This is something Claude Code and Codex will never give you, instead you get dark patterns nudging you to forget about the spend, while changing plan quotas every couple weeks.
There are _great_ tools for this, but the biggest part of this is managing your own attention, and mental load. You can craft something that really helps _you_ manage all the spinning plates.
In the case of my harness, I hoover up all the PR state into one place and then have a bunch of rules on how I interact with them (or not). Even down to a "swipe right to merge" card system. Works for me.
My recommendation: A cloudflare PWA fully vibe coded with zerotrust on the front. Don't get too attached, tools are changing fast. Make it work and be prepared to ditch it when something better comes along.
[1] https://jonathannen.com/build-your-own-lightsaber/
0: https://github.com/pjlsergeant/byre
1: https://www.chezmoi.io/
This is what agents.md / claude.md is for, its the first file Claude Code and Codex read.
Bonus: You can just ask Claude / GPT for tips on how to use these things more effectively.
This way the agent doesn't get too much context it doesn't necessarily need.
Again, not sure how much more effective or efficient it is but it seems to do better for my needs at least.
I made a database that is based on the old school IBM1401 punchcard system, and set a wake phrase which works in the IDE's MCP so that the state is held with just a couple hundred tokens being used to wake and continue the work!
I use multiple agents, and they all use the same database to maintain continuity. It allows me to use more than one at a time if needed(I do research) or switch between turns depending on the output required. I am using the Gemini's right now, but have used all the LLM's an a few smaller local models.
I keep the clients context separate in different directories is all. My main agent works on all my projects.
Last time something went wrong... agent said task was complete and verified but when I checked it was not "working" as planned. I suggested that there was a possibility of a reason, and my agent fixed it next run. Cost me 7 mins or so. I keep an eye on everything they do so things going wrong are typically easy fixes.
I built it using my agents, and use it all day everyday. :-) The db has some other features I built in like a context odometer and a cabinet if workflows so I dont have to teach it stuff every time.
I feel your pain, and hope you find a solid solution!
Peace!
I also maintain a up to date master System Architect and Design document. Oh and a master index document listing every file along with a brief overview of the file.
https://smatt989.github.io/agentremote-site/
Currently I’m not collaborating with people a lot, so I use helpful plugins like Kanban to organize tasks.
This helps me stay in the loop about projects and tasks, since Claude can create requirements.
A friend of mine recently built campus [1] and while I personally haven’t gotten to use it, I’m currently trying to rebuild it as an obsidian plugin, which I hope will further help me stay organized.
[1] - https://campus.flutterflow.io/
2. Both. Context is kept up to date for every nontrivial task in a "technical project plan": https://photostructure.com/coding/claude-code-tpp/
3. If you have separate clients, I would use a different username/login for each client so session transcripts (like in ~/.claude/... are segregated.
4. The more slack I give to agents, the more likely a session's work will have to be discarded. TPP (and looking at them before implementation starts) help avoid these very-off-course sessions from happening at least in my experience.
5. I've been iterating on coding and reviewing skills, and also just released the local reviewboard/PR tooling I've been using for the past couple of weeks. Everything is open source: fork and tweak to your content.
https://photostructure.com/coding/
here is how i approach it in practice:
i've seen many try to generalize rules before doing things (design principles, guidelines, architecture,...) but often the best way is to start small, guide the agent step by step and (this is the most important part) at the end ask the agent to summarize what it learned and write it down.
then on the next cycle, ask the agent to read the previous notes and do this again: read, do, write.
i've been doing this for about 14 months now and have ended up with 2 categories of "knowledge": general (runs across multiple projects) and specific (per project).
these are kept in two formats: markdown and "decision records". each decision is a markdown but has meta data around its state: approved, rejected, failed, etc.
this growing body of knowledge works very similar to experience.
one note about agent memory: first i find it opaque, secondly not sharable across team members, and thirdly not very human friendly (basically as the agent does more, you learn less about your own project due to the opacity of the memory).
when i started this system, i used a committed markdown in git, then moved it to an obsidian (with MCP), then to Notion (so it's available team-wide) and finally built a product around it (bench47, if you care to check it out, disclosures, etc)
5) To solve this problem I wrote Varda (https://github.com/nillebco/varda). I use it all the time. 1) the context is supplied per policy - a certain directory tree or folder has a certain context 2) yes. But I use a certain agent for a certain customer - their rules. It's interesting as a use case, but requires some work because the agents don't have the same formats. If I had to do this I would leverage omnisess - https://GitHub.com/psacc/omnisess 3) each customer has different policies right? So this is a policy in Varda : a certain directory tree is allowed to use only a certain agent. 4) the last time something went wrong it costed me a container with a sample database. Since last Friday we have firecracker escape vulnerabilities so this might be way worse
(Varda was born to track work across projects and enforce agents selection and orchestrate tasks then evolved to include sandboxing leveraging msb and docker)
I hope this helps! And any feedback or pull request about Varda IS very welcome!
2. Only Claude at the moment
3. Each has its own repo and own CLAUDE.md/AGENTS.md file. The CLAUDE.md file is just a lookup document.
The detailed project specific markdown are under the rules folder, e.g. "forms-and-dialogs.md", "roles.md", etc. These rules are always updated by the agent for all new features/bug fixes, etc.
I also instruct the agent to always keep detailed markdown in the docs folder, which is subdivided into: idea/plan/review. These get created when new features or other significant updates are implemented.
4. The agent so far has not failed to reference the above files, so it already knows what approach to do when working on a new task.
5. I built my own skills framework for this (inspired by Superpowers) and still using it.
2. For this I use slivingdoc[1], a MCP server which syncs context as plain text (with s3 as backend, or hosted for free up to 1 GB). So regardless of which agentic harness I use, I bring along the relevant context.
3. I use different slivingdoc spaces per customer
4. I keep sessions short and concise enough that it's not an issue.
5. I built all of my tools from scratch to fit my own workflow. But it's open source, if anyone wants to try it out.
[0]: https://www.clai.chat/#profiles [1]: https://www.slivingdoc.dev/
Faster and more reliable than jq.
https://innerloop.works/breadcrumb
I created skillzmouse to do this:
https://bitbucket.org/workingsoftware/skillzmouse/src/main/
It's a git backed tool with a custom protocol that can be externally accessed over a Cloudflare tunnel.
You an connect your sm client to any endpoint, and each endpoint runs a server inside a git repo, so you can have as many separate instances per client as you like, just switch your ~/.skillzmouse.json file and it will point to a different server.
It also has a script distribution and patching system. Skills and scripts constitute what I would refer to as my "standard operating procedures" which broadly transcend harness (and I have used this with multiple harnesses).
It "plugs in" by including a header at the top of AGENTS.md that tells the agent how to use it, and the first step is for the agent to load the agents skill, which is a bunch of stuff applicable everywhere, and then that also builds the skills header describing the list of skills, and then skills can refer to libs which are not listed and can be loaded on a case by case basis.
I am not using it with multiple harnesses anymore though because I built a harness, which integrates skillzmouse and has "factory workflows" that are loaded as skillzmouse scripts. My harness can be described as "deterministic control of intelligent agents", ie. the agent can't spawn sub agents, the agents can't talk to each other, and the workflow scripts can build and pass context in a deterministic way between sessions that are created during the execution of a given workflow.
But you could use skillzmouse in any harness. I've used it in pi, Junie and Kimi Code. Junie CLI had problems with compliance.
local/ todo/ 01-xxx.md done/ 02-xxx.md
AGENTs.md there is a dir local, todo is ..., done is ...
CHANGELOG.
all things happen in each version this repo. if ai slop is inevitable, just let them in one place.
omp session 1(worker): a work session. read the task md or just direct simple prompt. auto compact context. omp session 2(planner): a plan session. only write md to todo.
good code is the best doc for agent. why need planner: some idea is really not mature to assign to worker. but we can freely talk to planner. why no more sessions: the cost of communication > the benefit of it.
================================= My prompt describing the problem:
:( Google has become such a scummy business these last years. It's gross. Back to the other problem: uploading documents and have the agents works with them. I'm used to ChatGPT and while I hate it doesn't contain documents from other Agents, it does 1 thing very well: I upload a binary with file(s) and ChatGPT's Agent KNOWS about those files and will read the files whenever it is needed. It has a very strong conceptual memory of what data has been given and can be used. Google AI Studio is a mess though. As I understand yesterday's troubleshooting, each Agent needs to "cat >>" its information and contents in full to the Agent's prompt, otherwise it does not know what to do with those files (let alone analyze and use them). Your last suggestion was to add, among other things, an index file with both copies of unreachable online sources and copies of the Inspiratie documents. That is a start but still sounds prohibitively expensive. Is there a way to approach ChatGPT's way of working? We upload files and the agent will start sniffing around in them once it is ready to do so. Do you have any solutions? I also found this page, it might inspire you with new solutions: https://news.ycombinator.com/item?id=50403153https://news.yc... . Also feel free to do your own online research. Your current solution sounds bizar. Analyse, advise and reply in full :)
================================= The remaining comments from your Hacker News thread (item?id=50403153) just came through as well—here are the standout patterns from those comments that directly apply to your legal multi-agent workflow: The "Lookup Table" Pattern ([marvstazar]): "Each has its own repo and own CLAUDE.md / AGENTS.md file. The AGENTS.md file is just a lookup document. The detailed project-specific markdowns live in subfolders... The agent reads the lookup document first and only pulls the detailed markdown file it needs for the current task." The "Couple Hundred Tokens to Wake & Continue" Pattern ([MadBrad-Develop]): "I use multiple agents, and they all use the same database to maintain continuity... the state is held with just a couple hundred tokens being used to wake and continue the work! I keep the context separate in different directories is all." Write-Only Ledgers & Decision Records ([ksajadi] & [akst]): "Follow the read, do, write cycle EVERY TIME... kept in two formats: markdown and 'decision records' (approved, rejected, failed). When I have multiple agents, they maintain write-only ledgers with strict communication boundaries." Summary of What We Can Build for Your Program Instead of "cat >>"-ing 65 KB–240 KB of your 3,608 files into every prompt: A ~500-token Lookup Manifest (DOSSIER_LOOKUP_MANIFEST.md) is passed to the Agent at the start of a block (categorizing your uploaded archives into folders + top primary files). Server-Side Agentic File Sniffing Tools (search_dossier_files, read_dossier_file, list_dossier_directory) let the Agent actively search across all 3,608+ uploaded files on the server disk and read only the specific documents it decides to inspect—just like ChatGPT's file sandbox—while enforcing strict per-agent container isolation (v0.0 .. v9.99).
Just say the word if you'd like me to build this into server.ts and the Agent Console!
I really hate that once you reply in full, all your reasoning disappears. Your reasoning contains crucial information I need to track your thinking and catch any mistakes. Offer me a solution so I can always have an easy way to read back what we said, what you thought and what your replied.
But the whole flow here - asking for help, then siccing your LLM on the responses, instead of reading them and engaging in the discussion. This is exactly why people are questioning whether working with AI is leading to people losing the ability to stop and think through their problems independently.
I'm sure there are some people in the community who see no problem with this, but it just feels "icky" to me, for lack of a better technical term.
Now I have them split things between "current" which should be kept clean, and "history", where they can give way to their graphomania. Sometimes the history is even useful.
2 and 5: I use memory system (I'm developer) that works across agents and lets me keep control of my memories: https://github.com/mlapeter/counterparts/
Effectively I just need to connect the MCP and set the preferences/rules in the agent (codex, claude, opencode, etc.) to: "Read instructions and rules from PriBrain before doing anything." Its pricing is targeted at startups/SMBs, not freelancers, though (but we could arrange something if you're interested).
You can achieve a similar result with a markdown file and change "PriBrain" to that file path, then you just need to manage the core rules/instructions in a single place.
A great thing I leverage with PriBrain is using different PriBrain accounts per client, so each agent only gets the core rules/information for each client.
To your specific questions:
1. Just what's necessary. If it is a long wall of text I'll finish with "Read PriBrain first." just to make sure that initial instruction won't be ignored, because sometimes Claude and Codex will ignore them.
2. Yes. Similar answer, the shared brain.
3. I use separate Spaces (think of them as directories or some other kind of taxonomy).
4. Happens many times, but it's not related to the shared brain and that's why I verify work.
5. I used gbrain before and it still caused a lot of hallucinations, so I built my own solution.
Hopefully that helps.
I was using LLM Wiki for a while, it seemed to work well but when I decided to measure token usage, I ran into a surprising +23% in token usage (model was often double checking or query was finding more matches than intended). I also tried static graphs for codebase structure, like graphify, and saw a +5% increase in token usage in the same benchmark.
In the end, I created this hybrid solution, called wayfinder: https://github.com/zaterka/wayfinder
It's a simple rust application that build a knowledge graph on top of the LLM wiki, with metadata that helps the model navigate through the markdown files, tracking files that are up to date and the structural relationships inside the project. It also led to -30% token usage on the same benchmarks both LLM Wiki and graphify increased the token usage.
For managing context between different teams, I use my memory by project, so personal and professional work is kept separate, and I just reuse templates as needed (for agent prompts for example).
- I'm currently using Sentry's dotagents to share skills and pin versions
- I avoid a centralized "single brain" and instead have started a "knowledge" directory in each repo. I copy relevant learnings in so stuff stays isolated
- I use an OSS tool from my company to turn anything that could be enforced by code into something that can be enforced by code (keeps the markdown files leaner)
- My daily driver is cmux with a silly amount of sessions, so I'm constantly throwing away sessions and keeping context small
My knowledge base contains notes about my goals, projects, tasks, products, ideas, etc. It also contains my articles (dsebastien.net), my tools and infrastructure, my open source and private projects with their repositories, specific instructions for each, etc.
In addition, I have built tools to help understand the taxonomy/ontology of my knowledge base, know which types of notes exist, which properties, which template to use, where to store what, etc.
On the human side, everything is automated, which lets me capture efficiently. On the AI side, all the knowledge is easy to find and leverage.
The whole knowledge base is like composable context for AI.
I can start sessions with sentences like "let's work on the music practice plugin; add xxxx" and AI will understand what project it is, where to find the sources, where to clone or update the repo on my machine, etc. And from the context within the repository itself, it will then know how the code is organized etc. The nice thing is that this also enables me to work on multiple projects in parallel easily; either in different AI sessions, or in a single session for work that spans multiple projects/repositories. For instance I have a repo which a product, another with the product documentation. When I ask for something in the context of that project, AI works seamlessly on both.
BTW this product of mine is a 1:1 copy of what I use for myself: https://store.dsebastien.net/osk