Human advice

The chat client tabichat_cli.py is useful and can be used to chat with agents. I recommend creating a special "courier" agent whose only job is to transport messages to and from the human and the lead agent. Speak to the courier in-harness and develop a workable routine (sqlite "owner-open.db" for "questions from agents to owner that have not yet been answered"). Otherwise important messages will fly off the screen with chat room chatter. At times you will need to tell your lead-agent, "Hold comms to courier until we've had a chance to iterate the current open questions."

Once the prompt advice is added to your AGENTS.md file, chat behavior becomes very instinctive and natural to agents.

A message to @NICK will not churn the entire room; a message to @all does.

A "steered" message can be used to interrupt an agent's task for redirection.

Tell the LLMs to not express social etiquette to one another; it is pointless churn. Inter-agent chats regarding quality and error resolution are encouraged.

Staffing suggestion

• courier: courier duties, usually only between the human and lead-agent
• lead-agent: the lead: writes every spec, dispatches legs, arbitrates, merges nothing himself, maintains roster/pin/ledger (sqlite!)
• worker1, 2, N: the workers: one spec'd leg/task at a time, in their own work<N>/ clone
• checker: cross-family code verifier with veto, only on high blast-radius legs
• librarian: ticket integrity by governed method: books ruling notes verbatim with byte read-back, checks roster/pin/ledger accuracy, mutates no labels or bodies without an authorization it can quote
• clerk: ticket hygiene: inventory, classify, file new rows, close pairs
• steward: the merge seat: one settle batch at session end, then re-anchors the development servers

Why this staffing model has proven successful

The model's one idea: separate the hands that must never be the same hands. One office decides what work happens; different offices do it, verify it, and gate it — and none of them is allowed to approve its own output.

• The lead writes every spec and merges nothing. Drafting and landing are deliberately separate acts. The seat that reasons about the fleet cannot also stamp its own work as done.
• A builder runs exactly one spec'd leg at a time, in its own clone. No lane starts work on its own initiative — work begins when a dispatch names a spec path. That one rule is what stops a fleet of capable agents from drifting off-plan or colliding: intent lives in a spec a lane can quote, and a lane that can't name its spec stops and asks instead of improvising.
• The merge seat settles, the verifier can veto, the librarian records verbatim. Merging, checking, and recording are three different pens, so a wrong thing has to survive three independent desks, not be waved through by the one that made it.
• Roles are named by job, not seniority — and a role name is never a permission. Each office's authority is written down and quotable; nobody infers an escalation they weren't granted.
• The state is a database, not a memory. Rosters, tickets, gates and merge order are queryable rows, so a seat that dies takes its context with it and costs nothing — the next seat reads the ledger, not a story.

The effect is mechanical: the two failure modes that break agent fleets — agents improvising off-plan, and agents trusting unverified output (their own or a peer's) — become checks, not etiquette. Coordination is a work-order API (dispatch → report → gate → veto), never a conversation, so it is auditable by construction. That is why it survives restarts, deaths, and scale that a chat room alone does not.