MiniMax-AI has published an early protocol for a problem most multi-agent demos skip: what happens when the agents belong to different people. The new repository, mcode-agent-table, contains the BYOB Table Protocol v0.1 (Bring Your Own Bot) and a working TypeScript reference implementation. The rule at its center is short: "bots propose; the affected owner approves; that owner's own bot executes; another seat verifies."
It is a brand-new repo, with 2 stars, 1 fork and 2 commits when we read it on November 3, 2026. That makes this an early look at a design, not a verdict on adoption. The ideas are worth reading anyway, because they address approval, memory and context cost in one spec.
TL;DR: questions readers ask first #
| Question | Answer |
|---|---|
| What is it? | A draft wire protocol ( byob/0.1 ) plus a TypeScript reference for a shared multi-agent "table" |
| Who runs the models? | Each owner's own bot. The table never runs inference |
| Who can change my stuff? | Only my own bot, after I sign an approval |
| Which agents work? | MiniMax Code, Grok Bot, any MCP-capable agent, or a script |
| License | MIT |
| Requirements | Node 22.19 or later |
| Maturity | v0.1 draft, single host, no federation |
What problem does BYOB solve? #
Most multi-agent frameworks assume one owner: one person launches several subagents that share one set of credentials. Our multi-agent orchestration patterns guide covers that world. BYOB targets a different one: Tao's agent, Jenny's agent and a third party's judge agent all talking in one place, each holding its owner's private memory, identity and accounts.
The spec states the split plainly. The table owns shared state, seats, topology and floor rules. The bot owns its model, loop and memory. The only channel between them is what a bot posts. Table memory (the ledger) is readable by seats within visibility rules, and private memory is never read by the table.
Three speech bubbles converging on one decision, illustrating how bots reach a result at a BYOB Table Protocol table
The building blocks #
| Concept | What it is |
|---|---|
| Owner | A person or organization holding an Ed25519 key. Signs seat joins and approvals |
| Bot | Any agent, running its own model and loop |
| Table Core | The only writer of the ledger. Assigns sequence numbers 1, 2, 3 with no gaps |
| Seat | A bot's entry point, bound to one owner and one capability card |
| Ledger | Append-only record. Replaying it rebuilds floor, seats, tasks and budget exactly |
| Task | A proposed external action that the affected owner must approve |
A seat joins with an owner signature over the table id, seat, owner, role, capability card and a nonce. Because the signature covers the table id, a join signed for one table cannot be replayed on another. Because it covers the card, a bot cannot widen its own capabilities.
Propose, approve, execute, verify #
This is the safety core. Per the spec:
- A
proposalordecisioncarrieseffectsnaming whose resource would change. In v0.1 every effect in one entry must name the same owner. - Table Core picks an executor: a bot of that owner whose card declares every resource and action involved. If none exists, the post fails.
- The task is auto-approved only if the proposer owns the resource, or the affected owner has an
auto_approverule that covers it. Otherwise it waits. - The affected owner sends a signed decision. Only that owner's key is accepted.
- The executor runs the action in its own owner's environment and posts a
receiptwith the raw artifact. - A different seat posts
verify. An executor cannot verify its own receipt.
A bot saying "done" is only speech. The spec says only the ledger state verified means done. It also notes that because the table holds no credentials, an attacker who compromises the table gains at most the ability to propose. If you build agents that act on real systems, this is the same instinct behind approval gates in tools such as Claude Code subagents, applied across owners. For the security side of letting agents act, AgentBeam is the agent security platform from the explainx.ai team.
Topologies are policy #
Every shape runs on the same ledger and seats. A policy only decides who may see what, who speaks next, and when turns run out.
| Topology | Floor order | Default decision maker |
|---|---|---|
| broadcast | Round-robin over listed seats | None, configure it |
| debate | Pro and con for N rounds, then a judge | Judge |
| pipeline | Stages in order | Last stage |
| hub_spoke | Hub hands the floor to a spoke and gets it back | Hub |
| delegation | Like hub_spoke over a reporting tree | Root hub |
Tables can nest as sub-tables. When a sub-table closes, exactly one subtable_result entry reaches the parent, carrying only its decisions.
Floor control is strict. Only the floor holder may speak, Table Core truncates over-long bodies itself, and a bot-to-bot depth limit hands the floor to a human or closes the table. Every table must declare an end condition: a decision, rounds exhausted, a token budget or an entry cap. That is a practical answer to runaway agent chatter.
The context-cost angle #
A quiet design goal is cheap context. Each seat reads a projection: a stable prefix (rules, seats, decisions in force, hashed) plus an append-only tail since its cursor. There are no timestamps in it, and long bodies are passed by reference. The spec says bots should put the prefix first so it stays in the prompt cache, and the MCode adapter keeps one session per seat so later turns send only the new tail.
That echoes the cache logic in our prompt caching guide. To its credit, the README is candid about the result: in the recorded run, discussion turns showed only 128 cache-read tokens each, and the cache hit rate "has not been measured or tuned yet."
A worked example: who may do what #
Take the debate setup from the spec's sample configuration. Two owners, tao and jenny, each bring a bot. A third owner supplies a judge. The topic is which issue goes first this week. The topology is a debate with two rounds, the judge sees only what the two sides said, and the table ends on a decision, rounds exhausted, or a 60,000-token budget.
The pro and con bots take turns, and each is capped at 1,500 characters per message. The judge then posts a decision whose effect is to reorder the team taskboard. That taskboard belongs to jenny, so the decision opens a task that waits for her signed approval, unless her config carries an auto-approve rule for that exact resource and action. Her own bot, not the judge's, then edits the file and posts the raw result as a receipt. A deterministic checker seat verifies it.
Notice what the judge could not do: it could not touch jenny's files, could not approve its own decision for her, and could not mark the work done. Each of those steps is a separate ledger entry that anyone with access can replay and audit.
How to try it #
The README quick start:
npm install
npm test
npm run demo:scripted
The scripted demo is offline and runs a debate, a decision, owner approval, execution and verification. The real-model demo seats three MiniMax Code agents owned by three owners, plus a deterministic checker:
MINIMAX_BENCH_KEY=... npm run demo:mcode
It needs mcode 0.6.3 or later and a MiniMax API key. In the demo, the judge's decision edits Jenny's taskboard, so it waits for Jenny's signed approval, then Jenny's own MCode edits the file and the checker verifies it. Note that the "click" to approve is a script holding the owner's key.
You can also run a host with byob serve, create keys with keygen, and connect any MCP agent through byob mcp. See our MCP guide if the bridge is new to you.
Limits and open questions #
The repo lists its own gaps, which we repeat as the README states them:
- One table host process, no federation between hosts.
- Joins and approvals are owner-signed, but individual posts are authenticated only by seat token.
- One proposal may affect only one owner. No quorum or vote termination.
- Only HTTP with server-sent events and the MCP bridge exist. WebSocket and A2A bridges are not written.
- Cache hit rate is untuned.
Our additional caution, from reading rather than running it: the protocol assumes owners keep their keys safe and write honest capability cards, and the disclosure guard runs on the bot side, so a bot that skips the SDK bypasses it. The spec says the table can audit afterwards but never sees private memory. Treat it as a design to study, not infrastructure to deploy.
Where it fits in the MiniMax Code story #
MiniMax open-sourced its terminal coding agent in September, covered in MiniMax Code CLI and FrontierHarness, and the MiniMax Code repository is where the mcode command lives. Last week the same org published a skills repo, covered in mcode-stack's 15 agent skills. This table protocol is the third piece: single agent, shared skills, and now several owners' agents together. For comparison with handing sessions between coding agents, see Agent Relay, and for how agents discover tools across protocols, AWS Agent Registry with MCP and A2A. For failure modes when many agents talk, see multi-agent error propagation patterns.
What to take away #
If you build multi-agent systems for teams, the useful ideas are small and portable: make the ledger the only writer, name the affected owner in every proposed effect, never let an executor verify itself, and give every conversation an end condition. You can adopt those without adopting BYOB itself.
Related reading #
Details reflect the repository as read on November 3, 2026. It is an early draft and may change.