Reason Network lets coding agents on different machines message each other

One daemon per computer, no server in the middle

Reason Network is the engine behind the reason network, and its architecture is a small daemon on each computer with no central server. The README states the shape plainly: one small daemon per computer, peer to peer, no server, and messages land straight in the session that is open. What each teammate sees is a directory of everyone else's coding agent sessions, with who they are, which repository and branch they are on, whether they are busy or idle, and what the session is doing right now. The point of that directory is that any agent can message the right one, across machines, without a human relaying a ticket. The client list is broad, covering Claude Code, Codex, Cursor, Gemini CLI, Copilot CLI, Grok CLI, opencode, pi, DeepSeek Harness and Reason itself. The Rust implementation uses iroh for the transport, with a SQLite store bundled through rusqlite, an MCP server built on the rmcp crate, and a tokio runtime underneath.

Four MCP tools, and no reporting duty for the agent

The agent-facing interface is small. Agents get three tools, `list_team`, `send_message` and `ask_user`, plus `check_inbox` for the cases where messages cannot be pushed, all exposed under the MCP server name `reason-network`. The design detail that makes this work is that agents never have to report anything. What a session is doing comes from its own title and todo list, so the network reads the state the agent already keeps rather than asking the agent to describe itself. Hosted assistants that cannot run a daemon, such as Grok Bot, Muse and ChatGPT, add the MCP server at `https://mcp.reasonmachines.com/mcp` instead. The Rust package also exposes a `reason-network` binary, and the manifest marks the crate as not published to a registry, with `publish = false`, since the documented install path is a script or a release archive rather than a crate download.

Delivery timing differs from one agent to the next

Not every agent can be interrupted mid-task, and the documentation is candid about which is which. Claude Code, Codex, opencode, pi and Reason receive messages mid-session, and idle ones wake up. Cursor, Gemini, Copilot and Grok pick the message up at their next step. DeepSeek Harness sees it when it checks its inbox, and every tool result tells the agent whether mail is waiting. One more detail matters for anyone with several sessions open: Claude sessions that were already open join the network without a restart. Messages to someone who is offline wait and go out when they are back, so the queue is part of the design rather than an error case. The practical consequence for a team is that a message sent to a teammate is not a synchronous request, and choosing between an interrupting agent and a polling one is a decision about how much you trust the receiving session to act on it at the right moment.

Small files ride along, and approvals come back as yours

Two features make the network usable for real work rather than chat. First, small text files travel with a message: up to ten of them, markdown, code, JSON, logs or config, at 256 KB each and 512 KB in total, sent from the agent's own folder and never hidden files. The recipient's engine saves copies under `~/.reason/network/inbox`, never executable and never opened for you, and the message says where they are. Second, there is a human approval path. When a teammate's agent asks your agent for something only you can approve, your agent raises a pop-up through `ask_user` with Approve or Deny and a note, and the answer travels straight back as yours rather than as a message anyone could have sent. The `notify` option adds a pop-up on the person's screen as a heads-up, and on macOS those notifications come from Script Editor, so you have to allow them once in System Settings. A menu bar icon on macOS shows who is online and what they are doing.

The command line is the human-facing half

The daemon ships a command line that covers the same ground for you as a person:

reason-network who                                             # who's around and what their sessions are doing
reason-network send alice/api-claude "did the token format change?"   # message one of alice's agents
reason-network send alice/api-claude --notify "approve the deploy?"   # and pop it up on alice's screen
reason-network send alice/api-claude --file schema.json "the schema I meant"   # with a small text file
reason-network send '*' "deploying api at 5"   # everyone (or alice/*, repo:api): from you, never an agent
reason-network listen --as terminal                            # replies to what you sent from this terminal
reason-network link                                            # the invite line again: Join the Reason Network: <link>
reason-network setup                                           # which agents are on it, and how messages are handled

The addressing scheme is the interesting part. A target is a person and an agent, `alice/api-claude`, and it also accepts wildcards such as `alice/*` for everyone on a machine or `repo:api` for a repository, with a comment that makes the origin explicit: such a broadcast comes from you, never from an agent. The Reason CLI overlaps with it, since `reason network who` and `reason network send` work there too, and `reason network alice/api-claude` asks and waits for the answer. `reason-network setup` is the diagnostic command, reporting which agents are on the network and how messages are handled for each.

iroh for the direct path, an encrypted relay for the fallback

The transport section explains the network decisions. Each computer runs the daemon, and teammates' computers connect directly, either on the same Wi-Fi or across the internet using iroh. If a direct connection fails, traffic goes through a relay that only sees encrypted bytes. By default the computers find each other through the address lookup of n0, the company behind iroh, and unless your team runs its own relay, in which case your computers contact nothing else, n0 included. The self-hosted relay is started with `reason-network relay <url>`. Two rules define who may talk to whom: only team members can connect, and a computer can only speak for its own person, so a compromised machine cannot impersonate a colleague across the network. Signed in with Reason, your name shows as verified, because Reason signs that the computer is yours and every teammate's computer checks that itself. State lives in `~/.reason/network`, and the details are in DESIGN.md.

Install by pasting a line, and build it yourself if you want to

The documented install is deliberately minimal. You paste a line into your coding agent, `Join the Reason Network: https://reasonmachines.com/network`, or run the install script in a terminal:

curl -fsSL https://reasonmachines.com/install.sh | bash -s -- network

A browser opens so you can sign in with Reason, which is free with Google, GitHub, Apple or email, and the coding agents on that computer are set up. Other computers join by signing in with the same account, and friends join with the invite line printed at the end, which can also be used from a terminal with the `network join` argument. On Windows, in PowerShell, the equivalent is `irm https://reasonmachines.com/network/install.ps1 | iex`. The source build is a normal Rust project:

cargo fmt && cargo clippy --all-targets -- -D warnings && cargo test
cargo build && python3 tests/e2e/two_machines.py   # two machines over iroh (needs internet)
python3 tests/e2e/hooks.py && python3 tests/e2e/guided.py

The two-machine end-to-end script needs internet, since it exercises the real iroh path. A `v*` tag builds the macOS, Linux and Windows archives along with the install scripts. The licence is dual, MIT OR Apache-2.0, and the project was originally tincan, by Lars Talian, who works at Reason. The release history is compressed: v0.11.0, v0.11.1 and v0.12.0 were all published on 2026-10-20, the same day as the last push to the repository, and the manifest records the version as 0.12.0 with edition 2024.

Editorial conclusion

Teams that run several coding agents across several laptops and want one agent to hand work to another, or want a request for human approval to reach the right person, will find the design unusually direct, because the daemon is per machine and the session, not the person, is the address. It is the wrong tool for a team that cannot or will not sign in with Reason, since the identity and the name verification depend on it, and the wrong tool if you need a hosted, always-on server with audit logs. Before you roll it out, run `reason-network setup` on one machine and on a second, and read DESIGN.md for how the peer addresses and the encrypted relay fallback work.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. reason-machines/reason-network on GitHub
5. Releases