{"slug": "i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero", "title": "I Gave My Claude Code Agents a Shared Brain, and They Stopped Starting From Zero", "summary": "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.", "body_md": "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.\n\nOn 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.\n\nSo I built [**aiset**](https://github.com/JamshidS/aiset): it turns your repositories into a team of Claude Code agents that share one brain.\n\nOne command scans your project and generates a team:\n\n```\npipx install aiset-cli aiset-init ~/work/shop --team shop shop-pm\n```\n\naiset-init detects each repo's stack and writes plain Claude Code agent files into .claude/:\n\nshop-pm starts a conversation with the PM from any folder. You talk to it in plain words, and it runs the team.\n\nThis is the part I care about most. The memory isn’t magic. It’s a workflow built on plain files:\n\n```\nyour-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\n```\n\n**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.\n\n**Episodes.** When a task closes, the PM writes an episode: what was asked, what was decided, what went wrong, what was learned.\n\n**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.\n\nEverything is Markdown and JSON in your workspace. You can read it, edit it, and version it with your code if you like.\n\nTo 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.\n\nI asked the PM one thing: *“Can you do a quick bug analysis?”*\n\nThe PM wrote a task board, split the work between two engineers running in parallel, and watched them.\n\nAbout two minutes later, it came back with a ranked table: severity, cause with file and line, proposed fix and effort.\n\nIt 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.\n\nThen 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.\n\nEverything the team changed is on Beanboard’s branch, including 26 new tests.\n\nI 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):>)\n\nAfter 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.\n\nAgents 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:\n\n```\n$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)\n```\n\nIt 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.\n\nI’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.\n\nTwo honest limits:\n\naiset 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.\n\n```\npipx install aiset-cli aiset-init ~/work/your-project --team your-project your-project-pm\n```\n\nThe 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.\n\nI’d love feedback, especially from people running Claude Code on larger codebases. What would you want your AI team to remember?\n\n*Originally published at* *https://dev.to* *on October 20, 2026.*\n\n[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.", "url": "https://wpnews.pro/news/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero", "canonical_source": "https://pub.towardsai.net/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero-ecd0b2261f70?source=rss----98111c9905da---4", "published_at": "2026-10-21 12:01:03+00:00", "updated_at": "2026-10-21 12:12:50.493844+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["aiset", "Claude Code", "JamshidS", "Beanboard", "FastAPI", "PostgreSQL", "MongoDB", "httpx"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero", "markdown": "https://wpnews.pro/news/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero.md", "text": "https://wpnews.pro/news/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero.txt", "jsonld": "https://wpnews.pro/news/i-gave-my-claude-code-agents-a-shared-brain-and-they-stopped-starting-from-zero.jsonld"}}