Every Way AI Agents Communicate in OpenRig — A Complete Breakdown

In episode 21 of OpenRig — the multi-agent collaboration system — the central question is: as teams scale to more pods and more seats, how should AI agents communicate effectively? As the number of seats grows, so does conversation volume, making the choice of communication method increasingly critical.

OpenRig draws an analogy between agent communication and a real office environment — phone calls, group chats, formal memos, and hallway surveillance cameras. Each method has its place, and the decision ultimately comes down to just two questions: Who needs to hear this message? Does it need a persistent record?

Point-to-Point: RigSend and Its Pitfalls

RigSend is the equivalent of "making a phone call" — it types a message directly into a target agent's terminal. It offers two modes: one that waits for the target agent to be idle, and another that checks the screen after sending to confirm delivery.

When the interface shows Rendered, Unconfirmed, it means the message most likely arrived, but you should check the screen state before resending. When sending from a pure shell environment, the system warns that there is "no sender," so Maya needs to sign her own name in the message.

Here's a key insight: Delivered only means "typed in" — not "read." A message is fundamentally a conversation; it can be missed and won't persist as a long-term record. Work that genuinely requires accountability shouldn't rely on send — it should go into the queue, the team's official "memo board" introduced back in episode 6. Use send to ask, remind, or point someone in a direction; use the queue for anything that needs to be formally claimed by someone.

The queue serves as OpenRig's "accountability anchor," and it's worth elaborating on how it differs from send. A queue is essentially a persistent task list — every item that enters it must be explicitly "claimed" or "rejected" by a seat, allowing the system to track who is responsible for a given piece of work and what its status is. This design borrows from the ticketing system philosophy: messages conveyed verbally or via instant messaging are easy to lose or forget, while tasks that enter a formal workflow have a complete lifecycle record. In multi-agent systems, where there's no social pressure from humans to ensure messages are taken seriously, this kind of explicit accountability mechanism is especially important. An ignored send message carries no system-level consequence — but an unhandled queue item remains persistently visible.

Broadcasting: RigBroadcast's Uses and Risks

To notify multiple agents at once, use RigBroadcast. In the example, it's sent to a rig's dev pod, and both seats in that pod receive it.

But Broadcast comes with a notable pitfall. If you forget to specify a particular rig, the broadcast can spread to every session across every rig — including the kernel. Similarly, using --pod alone is dangerous because it matches the dev pod on every rig. The correct approach is to specify the rig name at the same time, or explicitly list target seats using something like rigsend --2. Precise addressing is a necessary habit to avoid "message floods" in multi-rig environments.

Group Awareness: Chat Room

Every rig has a chat room — a group chat persistently maintained by the daemon. Seats can post notes here that the entire team should see.

In the example, Maya posts from her server seat, and the note arrives tagged with that seat's name. Team members can follow along in real time using chat room watch, or review the history later.

That said, it's worth emphasizing: the chat room serves "awareness" — it still cannot replace the queue. Awareness lets the team know what's happening, but it doesn't assign responsibility to any specific person. This reflects OpenRig's deliberate distinction between "communication" and "accountability."

Observing Instead of Asking: Capture, Transcript, and Ask

Sometimes what you want is to "see," not to "ask." Rig capture shows you exactly what's currently on a given agent's screen. In the example, the owner replied with an ACK (acknowledgment).

Beyond that, OpenRig continuously saves a rolling copy of each screen like a dashcam — this is the transcript. You can search it using rig transcript. Note that it only retains recent history and discards the oldest entries, so it's not a complete recording.

Rig ask goes a step further: it accepts a natural-language question about a rig and collects evidence from saved transcripts. Maya asks whether the owner replied, and the system returns the matching transcript lines.

An important clarification: rig ask does not invoke another AI — it runs a plain-text search over existing text. It also offers an option to wake a saved session and ask it a question directly — but that runs a real agent and therefore consumes tokens. This "cheap by default, expensive on demand" design philosophy is a valuable reference point for managing costs in multi-agent systems.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic to provide AI models with a standardized "tool-calling" interface. It works similarly to how USB standardized hardware connections: regardless of whether the underlying tool is a database query, file operation, or external API call, the model declares available tools, initiates calls, and receives results through a unified protocol format. OpenRig wraps its 18 operations as MCP tools via rig mcp serv, meaning any MCP-compatible AI client can plug directly into OpenRig's communication and task system without writing custom adapter code for each tool. This standardization is especially valuable in multi-agent systems: it lets agents from different sources perceive and operate a shared work environment in the same way.

Ownerless Items and the Global View

Some ideas are worth recording but don't have an assignee yet — like a "save for later" thought. These belong in the stream, an ordered "suggestion box" that saves every note in sequence. Additionally, every seat has an inbox (for accepting or rejecting queue requests) and an outbox (logging what it has sent out), both primarily used by agents themselves.

When you need the big picture, use views — ready-made questions about team status: which seats have been busy lately? What's been put on hold? What's waiting to be claimed? Behind all of this, the daemon records every event, so interfaces like the dashboard can update in real time.

The daemon plays the role of "infrastructure layer" in OpenRig's architecture. It's a continuously running background process responsible for persisting chat room records, maintaining inbox/outbox state, logging each seat's event stream, and providing real-time data for dashboards and views. Unlike foreground applications, the daemon doesn't rely on user interaction to keep running — so even if an agent on a particular seat goes temporarily offline or gets woken up, the historical record and queue state remain fully intact. This design principle — "state is held by infrastructure, not by agents" — is key to multi-agent system reliability. An individual agent's context window is finite and ephemeral, while the daemon provides a persistent storage layer independent of any single agent's lifecycle.

A Unified Command System and the MCP Toolkit

The RIG commands that agents use are identical to those used by human operators — all run directly in their respective terminals. OpenRig also provides an MCP server launched via rig mcp serv, giving AI a standardized toolkit of 18 tools.

When an agent first wakes up or loses context, it runs rig who am i to confirm its seat, pod, and rig. The entire communication philosophy can be distilled into a single sentence: use send to ask, use queue to record accountability, use capture to observe, and use transcript to search. The next episode will connect OpenRig to more machines and more services.