Finding the right session first
Asking a coding agent to look at work on another computer begins with finding the right session. Reason Network’s interesting contribution is the directory it builds around that small task. Person, machine, repository, branch and working status appear together. For the developer, the starting point is choosing the session that should receive a question. Selecting a model does not resolve that addressing problem on its own.[1]
Released on October 17, v0.10.4 adds a way to run the messaging engine on its own without a Reason account. The open engine is available under either MIT or Apache 2.0, while the proprietary Reason CLI remains separate. Tools including Claude Code, Codex, Cursor and Gemini CLI can appear in the same directory, giving different clients a shared way to address sessions.[1]
The request goes to a Rust daemon on the computer. Incoming and outgoing mailboxes live in SQLite, and machines seek direct connections through iroh. An encrypted-traffic relay is available when the direct path fails. Persisting and retrying outgoing messages is designed to keep a temporary network interruption from losing the request.[1]
I think this separation gives developers room to change agent clients. A shared directory and mailbox can carry a question without requiring the whole team to adopt one coding interface. The convenience may also come from the integrations prepared for supported clients, rather than openness alone. Judging portability therefore includes the maintenance of those integrations.[1]
The work after delivery
Reaching an address does not produce the same waiting behavior in every client. Claude Code, Codex, opencode and Pi can notify a running session. Cursor, Gemini CLI and Copilot CLI receive a message at a subsequent tool interaction or stopping point. Other MCP clients poll the inbox. The network’s storage of a message and the moment an agent reads it are determined in different layers.[1]
That difference belongs in the developer’s waiting-time calculation. If one session can be notified immediately while another remains quiet until its next tool call, model speed alone cannot explain the gap. A busy task or a slow connection could also delay the reply. Knowing the client’s delivery mechanism is therefore a concrete detail to examine before replacing an expensive model with a faster one.[1]
The recipient has another decision to make. Documentation treats a teammate agent’s message as a colleague’s request rather than the user’s instruction. Per-person acceptance, holding and refusal options are available. Sender limits and consecutive-message caps apply, and an agent selects one session rather than broadcasting to everybody in one call. Stored, delivered, held and refused remain distinct message states.[1]
The remaining design work becomes clear here: deciding which files an accepting session should work on and who reviews the result. Showing repository and branch information in the directory helps that conversation. But the design document places same-file overlap warnings in a later milestone. If I were organizing a team around this tool, I would name the file owner and reviewer explicitly in the request. A shared messaging path is valuable, and an intelligible handoff makes it more useful.[1]