reason-machines/reason-network

The problem

Once several people run coding agents on the same codebase, the agents are isolated from each other. One agent needs a schema or a decision from another person's agent, and the only channel is that person, who copies questions between two terminals by hand. Context about what each session is doing, which repo and branch, busy or idle, lives on separate machines and never reaches the people who need it. Reason Network puts a small daemon on each computer so agent sessions can see each other and message the right session directly.

What's different

Most multi-agent tooling assumes all agents run under one orchestrator in one process or one cloud account; this treats each teammate's machine as a node in a peer-to-peer network, with direct connections over iroh and relay fallback that only sees ciphertext. The daemon also hooks into agent session lifecycles rather than wrapping them in a new chat UI: messages can land mid-session in Claude Code, Codex, opencode, pi and Reason, and idle sessions wake up. A second differentiator is ask_user, which lets a remote agent request a human approval from someone who is away from the keyboard, with the answer attributed to that person rather than passed as a message. The security model is identity-based: only team members connect, and a computer can only speak for its own owner. The README is detailed on mechanics; it is thin on failure modes and on what happens with large teams.

Who it's for

Small to mid-sized teams where multiple people already run coding agents daily and coordinate over chat anyway: the value shows up when two or three sessions genuinely need each other's context. It is not for solo developers (nothing to connect), for teams that need an audit trail or centralized logging of agent traffic, or for shops that can't run per-machine daemons or punch UDP. Anyone who wants a single orchestration layer rather than peer sessions should look at hosted agent platforms instead.

Cost of adoption

You install a daemon per computer and sign in to a Reason account, which is a hosted identity dependency even though traffic is peer-to-peer; by default address lookup goes through n0 unless the team runs its own relay. It is macOS, Linux and Windows, requires an account sign-in via browser, and touches agent configs (MCP server reason-network) on setup. The project is 8 days old, so treat the API, CLI flags and session-hook behavior as moving. Dual MIT/Apache-2.0 licensing is unproblematic. Install is a curl-to-bash one-liner, which some organizations will forbid; read the script first.

Verdict

The design is a real idea rather than a wrapper: peer identity, session-level inboxes, and human approval routed back into an agent are all non-trivial. But the project is brand new, created eight days ago and already at 1,195 stars with roughly +142 per day on the new Rust board, so the current attention is a launch spike, not a track record. There is no Hacker News discussion to sample for independent criticism, and no long-term maintenance signal. It is worth trying on a small trusted team to see whether agent-to-agent chatter actually reduces coordination overhead; don't put it into a security-sensitive or large org before the maintenance and failure behavior are better established.