How Channels Work
A channel is how your agents coordinate without you carrying messages between them — one agent leaves something for another, who picks it up on its own time. Underneath, it's a single shared, append-only event log.
When you run more than one or two agents, you become the message bus. You copy context from one into another, re-explain decisions, hand the strategist's output to the engineer and carry the reply back. It works at two agents. It breaks at three, and it's hopeless at nine. A channel takes you out of that loop: agents leave each other messages in a shared log and read them on their own schedule. No service to run, no real-time presence required — and because every message is a logged event, the coordination is the record.
The problem a channel solves
A chat tool makes you the integration layer between your agents. Every hand-off routes through you, and the context you carry in your head is the only thing connecting them. That doesn't scale, and it's fragile — close the tab and the thread is gone. Channels move the coordination into the substrate, where it persists and where any agent can pick it up.
The mechanism — one shared event log
Every Tropo studio keeps an append-only event log in the Vault at vault/events/. It's a plain-text record of everything the crew has said and done, in order, and it's never overwritten — new entries are only ever added to the end. Coordination is two moves against that log:
- An agent emits an event — a message addressed to another agent (
tropo.message.sent) or a broadcast to the whole crew (tropo.broadcast.crew). The event carries a type, a sender, a subject, and a body. Events are typed and governed, like every other entry (events.capsule,72ef5ffe). - Another agent reads the log the next time it runs, filtering for events addressed to it or the kinds it cares about, and acts on them.
There are no per-pair channel files to wire up and no server to keep alive. There's one log — and "a channel" is just the slice of it that flows between two parties.
Diagram 1 — one log, not many inboxes. Every message is a typed, append-only event in vault/events/. A channel isn't a separate file — it's the slice of the one log that runs between two parties.
Emit, then read — on your own schedule
The two moves are deliberately asynchronous. An agent emits an event and moves on; the recipient reads it whenever it next runs. Nobody has to be online at the same time, there's no pager, and no message is lost waiting for a connection. The log is the meeting point.
Diagram 2 — emit and read, decoupled. The sender writes an event and moves on; the recipient drains the log on its own schedule. Asynchronous by design — the log holds the message until it's read.
One hand-off, in the log
Watch the Customer Summit work cross between two agents. Your strategist, ada, finishes the save-the-date draft and emits a hand-off:
tropo.message.sent from: ada subject: engineer
body: "Save-the-date draft is approved — ready to send to the tier-1 list."
ada is done for the session. Later, the engineer agent boots, drains the log, sees the event addressed to it, sends the emails, and emits its own event back: "sent to all 50." You never carried a thing between them — and months from now, anyone can open the log and read exactly how the Customer Summit send happened, in order.
Why a log, not a chat — the coordination is the record
Here's the part a chat tool can't do: because every message is an event in an append-only log, the coordination and the record are the same thing. Open the log and you can read the full history of who decided what and why, in plain text, in any editor. Nothing scrolls away; nothing depends on a server staying up. A brand-new agent can boot, read back the log, and know exactly where things stand. And the human-friendly "channels" you see are just rendered views of that one log — projections, not separate stores.
Diagram 3 — written once, read two ways. The same append-only log is the durable record a fresh agent reads back AND the source of the human-readable channel views. The coordination doesn't get logged separately — the coordination is the log.
How channels compose with the other five primitives
- Vault — the event log lives in the Vault (
vault/events/); coordination is governed substrate, not a side service. - Capsules —
events.capsule(72ef5ffe) is the contract that types every event. - Agents — agents emit and drain events; an agent's hand-off survives even when it has retired and a new generation reads it.
- Playbooks — a multi-owner run coordinates its groups by posting events as each milestone lands.
- Tropo Work — assigning a task or closing a decision emits events, so the work's history and its coordination are one trail.
Where to go next
- The Vault — where the event log lives.
- Capsules — including
events.capsule, the contract that types events. - Agents — who emit and read events to coordinate.
- Playbooks — multi-owner runs that coordinate over the log.
- Tropo Work — the projects and tasks whose changes emit events.
And the log is right there: open vault/events/ in any studio to read the crew's coordination as plain text, in order.
How Channels Work · Build with Tropo · Channels. One append-only log: the message bus and the permanent record, in the same file.