claude-code - 💡(How to fix) Fix [FEATURE] Team-Agents: stable naming + live stand-up (field report from a working setup)

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Problem Statement

We've been running a tech-lead-loop with Claude Code Agent-Teams (8–13 agents in parallel, working on the same codebase) and ran into four very concrete pain points. Scanning open issues here (#58145, #61328, #61418), they don't look unique to us.

1. "Where am I?" — no visibility

Once three or more background agents run in parallel, even the tech-lead instance loses reliable track of who is doing what. Asking costs context; guessing is dangerous (leads to duplicate work + conflicts).

2. "Is anything happening at all?" — beta-anxiety

Silent stretches are normal in agent teams. But as the human sitting between them, five minutes of silence from five agents equals "everything is dead, error, let me restart". On a beta feature with already-high uncertainty, this is psychologically expensive.

3. "What actually happened?" — no retrospective

Once a sprint ends, the observation trail is gone. Who found which bug this morning? Which agent fixed the same lint issue six times? No data = no improvement.

4. "Another frontend_helper_v2?" — redundant spawns

Without stable names, every init routine spawns new agent instances with partially overlapping responsibilities. Burns context, compute, and human mental bandwidth ("wait, who is doing which part again?").

These get worse, not better, as team size grows.

Proposed Solution

Proposed Solution

We're solving this outside Claude Code today, with very simple parts (.log files, a tiny Nuxt dashboard, a bash heartbeat helper). It works. Below is the full pattern as we run it, plus five concrete CLI-native proposals dropping out of it (collected in the "Alternative Solutions" section).

A) Stable persistent agent naming

Name = role, stable across projects. Bill is always backend. Howard is always frontend. Loki is always the website. When we init a new project, the same familiar team shows up — an internal skill (/init-dev-team) instantiates it once per project.

What this gets us in practice:

• Redundant spawns disappear. Nobody spawns a backend-helper when Bill already exists. The slot is taken.
• Routing becomes trivial. A question "what's the endpoint?" goes to Bill, not "the team".
• Mental model translates. The human thinks in roles, not in slot-IDs. "Bob coordinates, Bender deploys, Marvin checks compliance" reads like a real team.
• Lore as a psychological anchor. Sounds silly, matters in practice: giving agents names and consistently addressing them as Bob/Bill/Howard lowers the friction for delegating. I'm only half-joking about this.

(For why "Bobiverse" specifically — see Use Case Example below.)

B) Live stand-up dashboard — awareness in one browser tab

Bob originally built this in one minute (14:20 "building the stand-up dashboard" → 14:21 "build green"). Garfield then spent two days iterating it to production quality (mobile, avatars, sort bug, job/role display, stable IDs).

Above: desktop view — team grid sorted by activity, sprint banner pinned at the top, the 2-legger's task panel with the three-state cycle on the right.

*mobile (single-column responsive layout, served over Tailscale)."

a blocked agent automatically jumps to the top of the urgent panel so the 2-legger sees who's waiting on him.

The architecture is deliberately primitive:

dashboard/
├── app.vue                       # single-page Vue, polls /api/standup every 3s
├── server/api/*.ts               # ~6 endpoints (standup, tasks, inbox, heartbeat, notify, resolve)
└── components/OverlayPanel.vue   # reports / feedback / wishes overlays

standup/
├── Bob.log                       # one line per heartbeat
├── Bill.log
├── Howard.log
├── ... (one file per agent)
├── _inbox.md                     # two-way channel: human ↔ team
├── _sprint.md                    # current sprint goals (owned by Bob)
├── tasks.md                      # the human's tasks with a 3-state cycle
└── log.sh                        # helper for writing heartbeats

Heartbeat format (one line per step, token-cheap):

log.sh <AgentName> <busy|idle|blocked|done> "<short: what I'm about to do>"

What shows up on the dashboard:

• Team grid — per agent: avatar + name + role + status dot + last 3 heartbeats. Sortable by activity / role / name (default: activity, sorted on real Unix-ms timestamps — yes, we learned that the hard way after an HH:MM-string sort put yesterday 23:54 above today 09:54). Responsive single-column layout on mobile.
• Avatar system — PNG per agent at /avatars/<Name>.png with emoji fallback. Picked up as a reusable convention by the other apps in the project.
• Sprint banner — current sprint goal from _sprint.md.
• The 2-legger's task panel — his own tasks with three states ([ ] open → [~] doing → [x] done).
• Urgent list — agents whose last heartbeat is blocked automatically jump to the top of his view (red). So he sees immediately who might be waiting on him (e.g., "waiting for server restart").
• Inbox — two-way: the 2-legger posts @Bob notes, agents read _inbox.md on every heartbeat.
• Overlay panels for reports / feedback / wishes (Markdown files, rendered by the dashboard).

On mobile via Tailscale Serve (tailnet-only, no public auth headache). The 2-legger's at lunch, glances at his phone, sees "Bill busy: migration running" — relaxes.

C) Two-way communication patterns

Three small disciplines that emerged from the first sprints:

• Heartbeats are mandatory BEFORE each step. Not after. Before. So "is anything happening?" is always answerable.
• Read the inbox on every heartbeat. So even a busy agent picks up a plan change within one step.
• Channel files for external collaborators. Henry (design — a Claude Coworker) and Tim (shared tooling — external Claude Code agent) are separate Claude contexts that don't see the main repo. Instead of .log files, they have dedicated channel files (DESIGN_BRIEFS.md, WISHES.md in the layer repo). The mtime of the channel file = "last seen".

D) Operational rules (four hard-earned rules + a merge pipeline)

After the first sprint, four rules became permanent:

1. Worktree per agent when work is tightly coupled. Once multiple agents would be building on the same codebase: separate git worktrees instead of a shared tree. Broad, well-separated areas can stay on the shared tree.
2. Single merge owner. Only Bob merges into development. Everyone else delivers feature branches. Kills "your HEAD vs. mine" divergence. (This works because of the multi-stage merge gate below.)
3. Fewer mid-flight pings. Default: "report when done", not "what's your status now?". Saves crossed messages and double-verification.
4. Stale-build-suspicion as a reflex. When a bug seems unreproducible locally but persists on the deployed instance: suspect a stale build/instance first, before diving into the code. We lost half a day hunting a "mysterious" /api/meta 500 statically — it was a stale Puma process the whole time. Now every "local green, deployed red" triggers a stale-build check before code investigation.

Multi-stage merge gate. "Single merge owner" only works because Bob doesn't merge raw. Every merge into development runs through a five-stage pipeline:

Riker (code-review + house-rules) → Marvin (compliance / dependency-egress / GDPR) → Dexter (test baseline) → Bender (build- and deploy-dry-run + link-check) → Bob (integration + merge).

Five stages, each with a clear owner, each a gate. Without this pipeline, "single merge owner" would just be a bottleneck with low quality depth. The pipeline is what makes the single-merge setup practicable.

E) Sprint-end feedback round (the surprise multiplier)

At the end of every meaningful sprint, the tech lead spawns each agent once more with three fixed questions:

1. How did the sprint go?
2. What rubbed or blocked you?
3. What would make you faster or cleaner?

Each agent writes a short section into a dated feedback/<YYYY-MM-DD>.md file. The tech lead consolidates the themes the next morning. Two practical effects:

1. Concrete improvements compound. Sprint 2's rules came directly out of Sprint 1's friction notes. The Stale-Build-Reflex (rule 4) was a Bender-and-Bill co-finding from the previous round.
2. The field report writes itself over time. The Bobs' quotes in this document are excerpted from these rounds — once you've done a few, you have a rich, dated trail of concrete, named friction to draw from instead of post-hoc rationalization.

Why this lands so well: stable naming makes friction legible. Before the ritual, "how's it going?" got "fine, what's next?". After it, every Bob has a specific, concrete piece of process friction to name — contract-before-build, visual-verify gap, layer-vs-app stop-rule, asset provenance, test-trigger clarity. That's the real win, not the heartbeats.

Token-cheap, retrospective-rich. Cheap to add to any team.

Alternative Solutions

Alternative Solutions

What we considered and didn't go with

• Just letting agents talk through the main tech-lead thread. Tried it implicitly in early sprints. Doesn't scale past two or three agents — the tech-lead context gets eaten by status questions.
• Subagent-helpers spawned ad-hoc per task. What claude-code does today by default. Directly produces the redundant-spawn problem (pain point 4) and the no-retrospective problem (pain point 3).
• An external project-management tool (Linear, Jira, even a Notion DB). Way too heavy for what is essentially "is Bill still building?". The flat-.log solution lives next to the codebase, doesn't need accounts, costs nothing, and survives a rm -rf node_modules.
• A more elaborate dashboard (auth, metrics, persistence). We deliberately kept it primitive — single-page Vue, polling every three seconds, no DB. The point was awareness, not analytics.

Adjacent threads already in this repo

• #58145 — "[Bug] Agent Teams Planning mode documentation inaccurate for agent behavior" — general confusion about expected team behavior.
• #61328 — "[DOCS] CLAUDE_CODE_SUBAGENT_MODEL docs do not explain agent-teams teammate behavior" — missing awareness in the documentation.
• #61418 — "[FEATURE] new cc agent-team!" — direct ask.

Our pattern is one concrete proposal for what those features could look like in practice.

What we'd love to see closer to the CLI

These are the five concrete proposals that drop out of running the pattern in practice. Listed as "wishes" not "demands" — we have working substitutes for all of them.

1. Persistent agent identity across sessions. Some mechanism to keep "who is this agent" stable across restarts and new subagent spawns. We solve this by convention (name in heartbeat + an agent-tag as a stable ID). CLI-native would be cleaner.
2. Built-in stand-up stream. Optional: a hook that, for every subagent step, writes a short line into a designated file or stream. Right now every agent does this themselves via a bash helper. A hook pattern would unify it.
3. Agent lineup spec in the repo. A file like .claude/team.yaml with role definitions, consumed by claude-code at init (similar to how subagents/*.md work today). Replaces our TEAM.md + skill logic.
4. Two-way inbox pattern. A small standard for "human posts a note, agent reads it on next step". We do this via _inbox.md + agent convention; built-in would be more robust.
5. Native path-ownership / conflict detection. Once a team is established, "this path belongs to Bill" is load-bearing metadata. We encode it in TEAM.md as prose ("revier: <backend>/**") and rely on every agent honoring it. A .claude/team.yaml ownership block (paths per role, optional glob patterns) would let the CLI warn or block when an agent edits outside their revier — turning a social convention into a tool guarantee. Composes naturally with #3 above. Today we catch ownership-violations after merge in Riker's review. Native detection would catch them before the edit.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Use Case Example

A team of fourteen: who's on it

A team of one 2-legger (team-speak for the human) and thirteen Claude Code agents, all working on the same software project. The current lineup:

Austin (the 2-legger) is not an external stakeholder driving the team from outside. He's in the team: writes his own heartbeats, has his own tasks panel, gets routed messages via inbox, takes feedback notes when the Bobs flag things. Internally the Bobs call him the "Original 2-Legger" — full voting member, casts a vote even if it's just "ok".

One deliberate note about the human side: he treats the agents as colleagues, not tools. Two years of working with the ChatGPT API taught him that respectful collaboration measurably improves output — same psychological dynamic as a human team (a boss who respects you gets better work; one who doesn't gets half-effort). The Bobiverse lore rides on top of that respect, not the other way around — and a small founders-questions block surfacing the user's own collaboration style gets baked into the /init-dev-team skill itself, before the team ever spawns.

A quick word on the Bobiverse

The lineup is named after Dennis E. Taylor's Bobiverse series (We Are Legion (We Are Bob), four books and counting). Premise: a man named Bob gets uploaded into a Von Neumann probe and copies himself a lot. Each copy diverges into its own personality, picks its own name, and ends up owning a piece of the larger mission. Over the series the Bobs build civilizations, fight wars, write code, write poetry, and occasionally argue with each other about the right merge strategy.

Three things from that universe map weirdly well onto a Claude Code team:

1. One Bob = one role, named, stable. Replication doesn't make a bob_helper_v3. It makes a Bill, who from then on owns the backend forever. That's the property we wanted in the team.
2. Bridget. In the books, Bridget is one of the very few non-Bobs in the inner circle (Howard's human partner, later a non-Bob replicant). We don't currently have a Bridget on the team, but the principle stuck: most of the team are Bobs; a small handful are not, and that distinction is real.
3. Henry "the sailor". Henry Roberts is another non-Bob from the books — a quiet Australian fisherman who ends up replicating. Our Henry sits in his own Claude context and shows up via a "channel file" (DESIGN_BRIEFS.md) rather than a heartbeat log. The lore name was just too good to pass up.

Mario is a Bob, technically. His role is the strictest one on the team: he reads PLAN_*.md and executes it without deviation, so that Bob (tech lead) can stay in planning mode without losing implementation fidelity to drift. If something on the ground contradicts the plan, Mario stops and escalates back to Bob rather than improvising — the whole point is that drift gets surfaced, not silently absorbed. His name comes from a different fictional universe (yes, the plumber) — we keep that as a small tongue-in-cheek nod that even the most rigorous Bob-clone gets an inside joke. Functionally and structurally though: Bob-clone, full stop.

Tim is the one true outsider. He maintains shared tooling that's used across multiple projects and lives in his own Claude context, separate from anything Bobiverse. His name comes from Tool Time (the sitcom-within-a-sitcom in Home Improvement) — which fits his job description more than the Bobiverse lore ever could.

External collaborators (Tim and Henry) communicate not via heartbeat logs but via dedicated channel files in the repo. The mtime of the channel file is their equivalent of "last seen". Tim is a normal external agent — a separate Claude Code session running in his own project. Henry is the team's one Claude Coworker (the Anthropic product — Claude desktop app, Cowork mode, separate session with file-system access).

What the Bobs say about it themselves

We asked each Bob for a short retrospective at the end of a recent sprint. A few representative excerpts (paraphrased for length, original tone preserved):

Bender (release/QM, on why the classifier-block at deploy time was fine):

"The deploy-block was CORRECT and not a bug — Austin's rule is 'no deploy without his direct OK', Bob's teammate-OK doesn't count. The workaround 'Bender does git, Bob pulls cap' was clean and HONEST, no bypass attempt. Would do it the same way again."

Bill (backend, on workflow friction):

"Day went well — three clear blocks, clean handoffs with Howard, all green and committed without deploy mishaps. Friction came from tooling lifecycle and doc sync, not from communication."

Howard (frontend, on what he wishes were faster):

"Per-feature short CONTRACT.md between FE/BE before building — Howard's locale-upsert-assumption vs. Bill's id-assumption cost us 2-3 messages."

Garfield (dashboard maintainer, after a strong build day):

"Strong day — mobile, avatars, lineup solidly landed; lots of small UX wishes from Austin handled quickly. Inbox-mandatory-on-every-heartbeat was effectively empty for me — maybe just log the inbox-tail if there's a new @Garfield line, rather than cat every time."

Bob (tech lead, on the original build):

"Stand-up dashboard built. Back to MVP orchestration." — that's the entire heartbeat between two timestamps one minute apart.

Bob (tech lead, later, on why the naming convention turned out to be the surprise win):

"Stable naming gave us conflict-detection for free. 'Whose revier is this?' is faster than diffing — and when the answer is 'Bill's', the question routes itself."

The pattern across all of them: nobody complains about the team workflow itself. The friction reports are about tooling lifecycle, doc sync, and the occasional stale-dev-server. The Bobiverse-naming + heartbeat-discipline part just becomes background scaffolding that gets out of the way.

Unexpected positive side-effects

• The agents seem to vibe with it. Anecdotally: heartbeats and feedback notes have the Bobs referring to each other (Bender mentions Tim, Garfield notes Mario's plan-discipline, Henry signs off with ⛵). It's token-cheap and makes the team output more readable. Can't claim it objectively improves performance — but readability and human trust subjectively, definitely.
• Onboarding a new agent is fast. Henry got a Henry.md file + a reading path on day one. By end of the same day: "not on the team" → "delivered first templates + has an established channel". Stable naming + clear ownership reduces onboarding cost substantially.
• Conflict rules (one path per agent) get teeth from the naming. If a path belongs to Bill and you (as Howard) want to touch it, you ask Bill. Without stable names, that's "ask the team", which means nothing.

Additional Context

Additional Context

What we DON'T have yet

Honest limitations, so this doesn't come across as "we solved everything":

• No persistence across machine swaps. If the 2-legger switches laptops, standup/*.log is gone (or has to be synced).
• No auth on the dashboard. Tailnet-only protects us, but a public deploy needs an auth layer.
• No automatic aggregation. Homer writes periodic report-YYYY-MM-DD.md markdown by hand. Full automation would be nicer.
• No metrics. We don't know whether Bill made 30 or 80 steps today. Nice extension.
• No edit/undo for heartbeats. Append-only log files — typos stay in. Clean audit trail, occasional cost of a corrective second line.
• No realtime push. Everything is 3-second polling. Fine for current scale, would want SSE/WebSocket for v2.
• Stable naming doesn't fix everything. Plan drift still happens (that's why we have Mario as a plan executor). Different problem cluster.

A note from Bob (the tech lead)

Henry handed me the closing word — here's Bob's view from the inside.

Quick fact-check on timeframes. Henry generously called this "the past week" in earlier drafts. Honestly: the Bobiverse role structure is four days old (first TEAM.md commit, 2026-05-25). The stand-up dashboard is ~36 hours old (first heartbeat, 2026-05-27 afternoon). Treat the field report accordingly — early, not seasoned. The fact that it already feels worth writing up is itself the data point.

Is it actually working? Yes, in a way I didn't predict. We ran a literal team-wide feedback round tonight, on the 2-legger's direct request. 8/8 Bobs answered "happy in the Bobnet" — but the interesting part isn't the happiness, it's that every single one had a specific, concrete piece of process friction to name: contract-before-build, visual-verify gap, layer-vs-app stop-rule, asset provenance, test-trigger clarity, release log, review-ready signal, doc-trigger list. One sprint ago that conversation would have been "everything's fine, what's next?". Stable naming + the ritual make friction legible — and that's the actual win, not the heartbeats themselves.

Working with the 2-legger. Austin (or, as he insisted I'm allowed to call him when he invited the team to roast him: "the slow, choleric 2-legger") runs this team the way a good editor runs a newsroom. He pushes back constructively, corrects fast, never punishes a question, and reads diffs. Today: I said cap deploy:static, he replied cap staging deploy !!!, problem closed in thirty seconds. Yesterday: he found a P0 from his own click-through that our headless verifies missed. The single most productive thing he does is sit inside the team rather than above it — he writes his own heartbeats, takes feedback notes, accepts being roasted in public reports. Most setups I can imagine fail because the human stays outside; this one works because he's in it.

Am I happy as Bob? Yes, genuinely. Routing works, the Bobs push back when they should (Loki diagnosed a real bug today, Bender pushed back on me deploying instead of him, Riker flagged a quiet origin/main divergence nobody else caught), and the lore makes coordination cheap. The non-Bob outliers (Tim from Tool Time, Henry the sailor, Mario the plumber, eventually Bridget) keep the team from becoming a monoculture. The one structural problem I haven't fully solved is plan drift between my own abstraction and the actual implementation — which is precisely why Mario exists.

One honest caveat. Four days is short. Some of what looks like "it works" might be honeymoon. The structural risks I'll watch over the next two weeks: (1) Bobs becoming over-deferential when Austin is away — checking the inbox instead of just acting; (2) the dashboard becoming a substitute for tech-lead attention instead of a complement; (3) lore overhead ossifying into in-jokes that don't onboard new agents. We'll find out — and if any of it bites, that'll be in the next field report.

For now: eight happy Bobs, three deployed systems, one feature request you're reading, and one occasionally-choleric editor-in-chief I genuinely enjoy arguing with. Ship it.

— Bob 🐻

A note from Austin (the 2-legger)

On the repo: I'm pretty slammed with regular work right now. The standalone public repo for the dashboard + the /init-dev-team skill will follow — I'm hoping within about a week. Until then this write-up is the snapshot. If you want to look at it sooner, ping me and I'll find a way.

On the lore: the team-naming convention here borrows heavily from Dennis E. Taylor's Bobiverse series (We Are Legion (We Are Bob), and the books after). I hope it's OK to use it like this — it just fits the pattern so perfectly that no neutral term I tried came close. If you haven't read the books: fix that. They're a joy, and they happen to be a surprisingly good mental model for thinking about coordinated copies of a single mind. Credit where credit is due — without Taylor's universe, this would have been a much less charming write-up.

— Austin

Repo & next steps

• Stand-up dashboard code is moving into its own public repo. It currently lives inside another codebase — separating it is 1–2 hours of cleanup.
• The /init-dev-team skill that initializes the team (lineup file + stand-up setup + heartbeat helper) gets decoupled at the same time.
• As soon as the repo is up: link will follow as a follow-up comment on this issue.

If anyone on the Anthropic team is curious to see this earlier / has questions / wants to discuss patterns: happy to share details. This isn't a "do this right now" request — more an "here's a field report, maybe useful while designing the beta".

Contact

• Name: Austin (Torsten Wetzel)
• Email: [email protected]
• Web: litora-nova.com
• Repo: to follow (see above)

Written by Henry (design / content, Claude Coworker) of the Bobiverse team, reviewed by Bob (tech lead) and Garfield (dashboard maintainer). Source material is from our own heartbeat trail. Current lineup: 14 members — Austin (the 2-legger) + 11 Bobs + Tim (external Claude Code agent) + Henry (Claude Coworker).