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.
What it does
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/:
- a PM that plans the work, assigns it, and verifies it before reporting back
- one engineer per repo (or per stack in a big monorepo)
- a QA engineer and an integration checker that looks at how the services fit together
shop-pm starts a conversation with the PM from any folder. You talk to it in plain words, and it runs the team.
How the shared brain works
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.
A real run
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 aiset-run branch, including 26 new tests.
Watching the team work
I didn't want a black box, so aiset comes with a local dashboard (aiset, then open http://127.0.0.1:8765):
- Office: a live view of every agent, their assignments, task boards, model, tokens and estimated cost.
- Brain: one graph of agents, briefs, episodes, files, endpoints and models, with live trails showing what each agent is reading and editing.
- Architecture: a map of your services and infrastructure, read straight from the code, with a file and line behind every link.
- Settings: pick the model per agent, for example Opus for the PM and Sonnet or Haiku for routine work.
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.
Research tools instead of grep chains
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.
What three weeks of using it taught me
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:
- Memory is a workflow, not perfect recall. Agents are instructed to save and read knowledge, but not every chat message becomes a rule. Review the briefs now and then, like any documentation.
- Token savings are what I've seen, not a benchmark. The research tools return far less text than the greps they replace (measurements here), but I haven't proven end-to-end savings yet.
Try it
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?
Top comments (0)