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: 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: 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):
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, 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 was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.