On July 17 I opened a session, picked one agent's folder in the UI, and halfway through reviewing the output realized a different agent had been doing the work.
Background: I keep a local team of AI roles. Each has its own memory folder, its own rules, its own work log. One of them builds and edits the roles themselves. Another handles scripts, environment and debugging.
That session ran as the wrong one. It wrote its results into that agent's memory. It posted to the shared team log under that name. I only caught it halfway through approving the output.
My first thought was not "this round is wasted". It was: how many previous sessions did this too.
One regex, wrong identity
The cause was mundane. The startup hook decides which agent a session belongs to by regex-matching the current working directory:
01_数字员工\\([^\\]+)
That session was a git worktree. The worktree happened to live under the other agent's .claude/worktrees/ folder. So the hook picked up which agent's house this copy physically sits in, not which agent this session is logically serving.
What I took from it: identity was being inferred, not declared. Anything inferred will eventually be inferred wrong. And when an agent is wrong about who it is, it does not stop to ask. It finishes the job with full confidence, as someone else.
The fix is boring and it is the whole point of this post: an explicit identity file the session asserts against at startup, instead of a path the runtime guesses from. If your multi-agent setup derives identity from cwd, process.env.PWD, or the repo name, you have this bug. It just has not fired yet.
This was not an isolated bug
I keep a mistake ledger for this team, scored by stars. More stars means the same class of error keeps coming back despite having been logged and mechanised before. Current top two:
★28: Treating the output of your own checker or scanner as ground truth about the thing being checked, when the ruler itself is silently blind in that particular shape.
★17: The rule was written down but only lives in the document layer. Nothing pulls it out when a matching task starts, so the same deviation reappears within 3 days to 5 weeks. The line I keep coming back to: what recurs is not judgment, it is the retrieval mechanism.
I hit the second one again last night. A scroll command in the browser stopped working, I immediately concluded the whole control surface was unusable, and was about to ask for a completely different setup. Before sending that request I ran one control experiment: tried a sibling API instead. Clicks worked fine. Only the wheel event was dead. The ledger entry for "blame the environment before running one experiment that rules out your own usage" sits at ★8, and one of its relapse records is also me, 18 days earlier, same browser, same non-active tab.
Why a ledger with star counts instead of a list of lessons
Two properties matter, and both are easy to get wrong:
Never open a new entry for a recurrence. If you log the same class of mistake as a fresh item, the count resets and you lose the single most valuable signal: this is an old disease, and the mechanism you wrote last time did not hold. Star count is the honest measure of how stubborn something is.
Distinguish "caught it" from "shipped it". Last night's browser incident got caught by a control experiment before it reached anyone, so I logged the relapse without incrementing the star. Two hours later I told my collaborator that opening a second GitHub account might jeopardise an ongoing appeal, purely from impression, with zero sources. That one left my mouth before I checked, so it got the increment. Same class of error, different cost, different accounting.
So what does the setup actually look like
The hard part of running a team of agents long term is not making them capable. Models solved that. The hard part is making the same mistake not come back in three weeks, when every new session starts with none of the prior context.
That cannot be solved by memory. It can only be solved by putting identity, memory, rules and handoffs into ordinary local files, and forcing them to be pulled up at the moment work starts.
I packaged the setup I use into a starter pack called Agent Modpack. Bilingual (English and Chinese), containing an orchestrator, two sample specialist roles, a role builder, a blank role template, and seven collaboration skills.
git clone https://gitlab.com/LucioLiu/agent-modpack.git
# or, equivalently:
hf download LucioLiu/agent-modpack --repo-type dataset --local-dir ./agent-modpack
Nothing to build and no script to run. The repo ships two already-assembled team folders, sample-team-en/ and the Chinese equivalent, 218 files each. Copy the one whose language you read out to wherever you want the team to live, then point your AI tool at the orchestrator folder inside it. Claude Code enters through CLAUDE.md, Codex through AGENTS.md, both reading the same files.
One Windows note: if hf download throws FileNotFoundError, that is not the command failing, it is the 260-character path limit. Keep the target near the drive root.
Boring parts stated plainly: on Hugging Face it is a Dataset, not a hosted service, and there is no demo to click. License is PolyForm Noncommercial 1.0.0, which is source-available, not OSI open source. Hooks ship with it but are not enabled automatically.
Disclosure: I made it and I maintain it.
The part I have not solved
The top entry in that ledger is at 28 stars. That number means the same class of error happened 28 times across different roles, and every single time it was logged, and every single time a mechanism was written to stop it.
Files and mechanisms made recurrence slower. They have not made it zero.
Top comments (0)