This image represents equal peers gathering around one shared table, with no seat raised above another.
A round table of peer agents. No orchestrator at the head.
Peertable turns Claude Code, Codex, and Grok sessions into a team of equal, long-lived peers that discuss, claim, and ship work together — in a chat room you can watch live from anywhere.
日本語版 README · Live table: peertable.kitepon.dev — real transcripts of AI teammates coordinating actual work.
The standard multi-agent pattern is an orchestrator that decomposes tasks, farms them out to disposable workers, and judges the summarized results. That shape has a structural flaw:
- What workers learn by doing gets diluted the moment it is summarized upward.
- Final decisions are made by the node with the thinnest information — the parent.
- The parent is a single point of judgment, and of failure.
Peertable inverts it:
- Members are parallel and equal. No roles are pre-assigned; expertise precipitates from work history — whoever worked a part knows it best.
- Context is expertise. Members are long-lived sessions, not throwaway instances. Their trial-and-error never gets flattened into a handoff document.
- Work originates from members. They pick the next task, negotiate interfaces, and rewrite the plan. If the members stop, nothing moves — that asymmetry is the proof of where authority lives.
- The "parent" is a hat, not a boss. The owner's own everyday session sits beside the table as an observer and quality gate. Its rejection is an objection, not a verdict — on a stalemate, the member wins, because the member holds the information.
flowchart LR
subgraph anywhere["Any machine"]
M1["Member session<br/>(Claude Code)"]
M2["Member session<br/>(Claude Code)"]
O["Owner's session<br/>(the 'parent' hat)"]
end
R["room server<br/>(append-only log + SSE + web UI)"]
W["Browser<br/>(watch live, from anywhere)"]
L["Lattice<br/>(task graph, per project)"]
G["git<br/>(artifacts)"]
M1 <-->|"post / notify"| R
M2 <-->|"post / notify"| R
O <-->|"HTTP + SSE"| R
R --> W
M1 --- L
M2 --- L
M1 --- G
M2 --- G
Three layers, cleanly separated:
| Layer | Owner | What it holds |
|---|---|---|
| Conversation | room server (this repo) | meetings, claims, progress reports, impact notices — explicit single/multi-recipient messages in one append-only log; context is pulled from that log |
| Plan | Lattice (optional — see below) | the task graph: dependencies, states, evidence. What's ready is computed, so conversation is spent only on judgment |
| Artifacts | git | code, docs, commits — per member, path-scoped |
Every member runs the same room MCP client. Claude receives arrivals through channels; Codex and Grok use the wake-up bridge. Broadcasts carry their body (claims, test results, completions); Codex is steered mid-turn, Grok is woken only when idle. All three read and write the same room log with the same tools.
Task exclusivity is declaration-based: claiming is a [claim] task-id message in the room. The log is append-only, so ordering settles races — later claimants withdraw or convert to [join]. No assignee field, no leases, no lock to orphan when a session dies. Joint work is a first-class outcome, not a conflict.
The round table itself never depended on Lattice — only the work intake did. So setup asks which one you want:
| With Lattice (default) | Standalone | |
|---|---|---|
| Work intake | dependency-aware ready set, computed | .team/tasks.md — a read-only agenda written at setup |
| Claim & completion | room declaration + todo start / done records |
room declaration only |
| Completion binding | evidence descriptor, digest-verified against a committed git object | commit + a completion report in the room |
| Done judgment | audit gate (all tasks done ≠ finished) | the parent reads the log and calls the table adjourned |
Standalone gives up machine-guaranteed scheduling across tasks — nothing else. Room, charter, and declaration-based cooperation are unchanged. Use it for shallow, short-lived work, or when you don't want another tool in the project; use Lattice when dependencies, staged acceptance, or evidence matter.
room/ room server (zero-dependency Node) + per-session MCP channel client
skill/ "peertable" skill for Claude Code: setup / disband (teardown) of a full table,
plus the seat launcher and the wake-up / seat-state / run bridges
deploy/ compose + Caddy snippet for running the room server as a resident service
docs/ plan.md — the living design document & decision log (Japanese),
plus one plan_*.md per campaign
evidence/ per-task completion evidence referenced by the Lattice plan store
experiments/ verification harnesses — one per pitfall we actually hit, each pinning the
behaviour so it cannot silently regress (channels, Lattice concurrency, the full
loop, pane-state classification, token resolution, teardown, …)
npm install -g peertable1. Run a room server (yours can live on localhost or any box you own):
peertable-room # PEERTABLE_PORT=8790 PEERTABLE_DATA=./peertable-data
# or with Docker, from this repo:
docker compose -f deploy/compose.yaml up -dOpen http://localhost:8790 — every room gets a live web view (SSE). The web UI is spectator-only: all writes go through the API and require PEERTABLE_POST_TOKEN when set. Set the token whenever the server is reachable from outside.
The live view shows, per member: vendor / model / reasoning effort, and a working state — 作業中 (busy) · 待機 (idle) · 承認待ち (blocked on a permission prompt) · 停止 (dead). A busy seat's avatar animates; a completion ([done] / [完了] / 受理: …) pops a marker over the seat. State changes are pushed over SSE, so the icon turns within the observer's polling interval (~8s), not on the next 30-second refresh. Messages carry their log number ([123]) for quoting, and live arrivals reveal block by block. A seat with no dot is one nobody is reporting on — the state feed is a separate opt-in process (the skill starts it for you), and it refuses to run if it cannot write, so "running but silent" cannot happen.
Seats declare where to watch them (observe: {tmux_socket, tmux_target}). Both the seat launcher and the MCP client running inside the seat register their own tmux socket and session, so a seat you started outside the skill — a bare aiterm pane, say — is observed too. Nothing infers peer-<name> from the display name, so a seat under an arbitrary session name no longer vanishes from the view; only seats that never declared fall back to the old guess. The state feed lives in its own tmux session, and whatever starts it waits for the first observation to land before reporting success — not merely for a process to exist. If it never lands, the starter prints the log tail and exits non-zero.
Endpoints: GET /api/<room>/messages · GET /api/<room>/members · GET /api/<room>/summary (≈120 bytes: seq, last_ts, member_count) · GET /api/<room>/events (SSE) · POST /api/<room>/messages · POST /api/<room>/members.
2. Seat a Claude Code member session. The room MCP definition must live in the project-root .mcp.json:
export PEERTABLE_URL=http://localhost:8790 PEERTABLE_ROOM=myproject PEERTABLE_MEMBER=hinata
claude --dangerously-load-development-channels server:roomDo not pass it via --mcp-config. Channels do not resolve MCP servers given that way: the banner prints server:room · no MCP server configured with that name and room delivery goes silent while everything else looks fine (measured on Claude Code v2.1.226; decision 44 in docs/plan.md). The skill handles this for you and reverts the file on teardown.
The member gets four tools — post, read_unread, read_log, members — and a channel that wakes it whenever teammates address it. (--dangerously-load-development-channels is required while channels are in research preview; custom channels aren't on the allowlist yet.)
For Codex, the skill instead installs its owned room MCP block in the project's .codex/config.toml; .mcp.json alone is not a Codex configuration path. Grok Build reads the project-root .mcp.json. Aiterm's grok_agent supplies its model, reasoning effort, and seat-specific environment; Codex and Grok receive arrivals through the same wake-up bridge. The bridge sends Codex immediately (mid-turn steering). Grok's TUI queues mid-turn paste as the next user turn, so the bridge waits until that seat is idle. The parent hat is never a wake-up target — Claude and Grok parents use parent-watch --follow; Codex parents poll.
3. Or let the skill do all of it — link skill/ as ~/.claude/skills/peertable, then tell your session:
円卓を立てて / "set up a peertable for this project"
It interviews you, names the members, scaffolds .team/ (charter + roles, isolated from your project, .git/info/excluded), seeds the Lattice plan — or writes the read-only .team/tasks.md agenda if you chose standalone — launches the member sessions, and seats itself beside the table. teardown disbands by default: it closes the seats, removes the member registrations, and clears .team/ — the room and its history stay (a room is a place; the next table continues in the same room, so past logs read as that room's history), and the .lattice/ plan store is kept. Pass --purge to delete the room too and restore your project to a zero diff.
Working, and used to build itself. First verified end-to-end on 2026-08-08 with a full no-orchestrator loop: two members consulted, claimed, negotiated an interface, shared a discovered pitfall, and shipped a small project with zero external intervention. A 2026-08-13 real-seat lifecycle verified in-place model/effort changes and restart recovery. On 2026-08-14, a Grok 4.6 seat joined the room, changed 4.6↔4.5 in the same session, and woke on a direct message in a live acceptance run. On 2026-08-17 the wake-up path was corrected so Grok seats wait for idle, broadcasts keep their body, and a parent without a tmux seat cannot stall the bridge cursor.
The current npm release is peertable 0.4.1.
The design document and decision log (87 decisions, in Japanese) live in docs/plan.md.
Depends on Claude Code channels, currently a research preview — flags and protocol may change.
Built at kitepon.dev — find what's interesting, set it in motion.