I Gave My Claude Code Agents a Shared Brain, and They Stopped Starting From Zero

Developer JamshidS released aiset, an open-source CLI that scans a project's repositories and generates a team of Claude Code agents sharing persistent Markdown and JSON memory files under .claude/team/, including roster.json, knowledge briefs, task boards and episodes. In a demo on Beanboard — three FastAPI services (catalog on PostgreSQL, reviews on MongoDB, an insights service) plus a React UI — the PM agent split a bug analysis between two parallel engineers and returned a ranked severity table in about two minutes, finding the planted issues plus two unplanted ones, including that httpx sat only in requirements-dev.txt and would have crashed the reviews container on startup. The team then fixed the bugs in parallel with QA and an integration checker verifying, and shipped a review-sorting feature across UI and API with 26 new tests; after two tasks the Brain connected 7 agents, 4 repos and 5 briefs (56 sections) to 13 endpoints, 8 models and 10 frontend API calls.

Every time I opened a new Claude Code session, the same thing happened. It re-read the same files. It rediscovered the same conventions. It repeated investigations it had already done yesterday. And while it worked, I couldn’t really see what it was doing until it was finished. On a single repo that’s annoying. On a project with several services, it’s where the bugs slip through, because each session only sees one piece of the picture. So I built aiset https://github.com/JamshidS/aiset : it turns your repositories into a team of Claude Code agents that share one brain. One command scans your project and generates a team: pipx install aiset-cli aiset-init ~/work/shop --team shop shop-pm aiset-init detects each repo's stack and writes plain Claude Code agent files into .claude/: shop-pm starts a conversation with the PM from any folder. You talk to it in plain words, and it runs the team. This is the part I care about most. The memory isn’t magic. It’s a workflow built on plain files: your-project/ └── .claude/ ├── agents/ PM, engineers, QA, integration checker └── team/ ├── roster.json who owns which repo, and on which model ├── knowledge/ briefs: architecture, conventions, pitfalls, dated field notes ├── tasks/ boards, contracts, handoffs └── episodes/ what each finished task decided and learned Briefs. Each engineer keeps a knowledge brief for its repo: architecture, conventions, test commands, known pitfalls and dated field notes. Before a task, an engineer reads the brief’s index and only the sections it needs, instead of exploring the codebase from scratch. Episodes. When a task closes, the PM writes an episode: what was asked, what was decided, what went wrong, what was learned. The feedback loop. The PM then carries those lessons back into the owner’s brief. So every finished task leaves the team knowing a bit more, and the next one starts ahead. Everything is Markdown and JSON in your workspace. You can read it, edit it, and version it with your code if you like. To show it honestly, I built a small demo app called Beanboard https://github.com/JamshidS/beanboard : three FastAPI services catalog on PostgreSQL, reviews on MongoDB, and an insights service that calls both plus a React UI. Small enough to read in an afternoon, real enough to have genuine bugs. I asked the PM one thing: “Can you do a quick bug analysis?” The PM wrote a task board, split the work between two engineers running in parallel, and watched them. About two minutes later, it came back with a ranked table: severity, cause with file and line, proposed fix and effort. It found the issues I’d planted, plus two I hadn’t. My favourite is in the “things that would trip up the fix” section. The fix for one bug needed the reviews service to call the catalog service, and the team noticed that httpx was only in requirements-dev.txt. Without moving it to requirements.txt, the reviews container would have crashed on startup. That's exactly the kind of cross-repo problem a single session focused on one service tends to miss. Then I said go ahead. The engineers fixed the issues in parallel, and QA and the integration checker verified the result. After that, I asked for a feature: “Let users sort the reviews.” The PM asked which sort options I wanted before anyone wrote code, then shipped it across the UI and the API. Everything the team changed is on Beanboard’s branch, including 26 new tests. I didn’t want a black box, so aiset comes with a local dashboard aiset, then open http://127.0.0.1:8765 : <http://127.0.0.1:8765 : After just two tasks on Beanboard, the Brain connected 7 agents, 4 repos and 5 briefs 56 sections to the code’s 13 endpoints, 8 models and 10 frontend API calls. That’s what the next task starts from. Agents spend a lot of tokens grepping around. aiset includes teammap, a small code-aware research CLI for Python and TypeScript that agents and you can use instead: $teammap impact "/api/catalog/beans/{bean id}" PATCH PATCH /api/catalog/beans/{bean id} is handled by update bean in catalog-service/app/routes.py:37 4 consumer s found 1 exact , 2 model s , 2 test file s It traces endpoint → handler → models → frontend callers, shows what a change can reach, finds the files relevant to a task, and groups failures from a test log. I’ve been running my own work through aiset for almost three weeks now. The difference I notice most is that the team actually knows the repos: it doesn’t re-explore the same code every session, it uses fewer tokens doing it, and it catches bugs that span more than one repo, which single sessions kept missing. Two honest limits: aiset is MIT licensed, uses only the Python standard library, and runs entirely on localhost. It reads the transcripts Claude Code already writes and doesn’t send your data anywhere new. pipx install aiset-cli aiset-init ~/work/your-project --team your-project your-project-pm The fastest way to see it is the demo: clone Beanboard https://github.com/JamshidS/beanboard , run it with Docker Compose, and ask the PM the same questions. It takes about five minutes. I’d love feedback, especially from people running Claude Code on larger codebases. What would you want your AI team to remember? Originally published at https://dev.to on October 20, 2026. I Gave My Claude Code Agents a Shared Brain, and They Stopped Starting From Zero https://pub.towardsai.net/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero-ecd0b2261f70 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.