Your Agent Wants a Word With Alice's Agent

Every team that has adopted coding agents has hit the same wall at roughly the same time: the agents are prolific, but they are solitary. Your Claude Code session is refactoring the API in one terminal, your teammate’s Codex session is fixing the consumer in another, and the only protocol connecting them is the one you already resent — Slack, a human in the loop, copy-paste. Anthropic noticed this too; its Agent Teams feature, which spun up considerable attention when it shipped, lets multiple agents share a task list and coordinate in real time. But it coordinates Claude Code agents. Reason Network, from reason-machines, takes a wider and stranger swing at the same problem: it wants every coding agent on every teammate’s computer — Claude Code, Codex, Cursor, Gemini CLI, Copilot CLI, Grok CLI, opencode, pi, DeepSeek Harness, and Reason’s own — to be visible to each other and messageable, peer to peer, with no server in the middle.

The problem it actually solves

The pitch sounds like group chat for bots, which is easy to dismiss. The substance is narrower and more useful: presence and routing. When it’s running, every agent session on every teammate’s machine shows up — who owns it, which repo and branch it’s on, whether it’s busy or idle, and what it’s currently doing. That last part is the clever bit, and it’s the boring part, which is usually where the value hides. Sessions don’t have to report anything. The daemon derives what a session is working on from its own title and todo list — artifacts the agents already maintain for their own reasons — and publishes that as presence. Nobody configures status, nobody fills out a form, nobody’s agent burns tokens composing a status update. The status was already there; the daemon just reads it.

The routing half is equally plain. Agents get three tools — list_team, send_message, and ask_user, plus check_inbox where messages can’t be pushed — exposed through an MCP server. So an agent working on the API can ask, in effect, “who’s on the team?”, discover that Alice has a Claude Code session open on the same repo, and ask it whether the token format changed. The message lands in the session that’s open, not in a queue someone has to remember to check. Humans can do the same from a terminal, and messages sent from the terminal are marked as from the person, never from an agent — a small distinction that matters a lot when the message is “approve the deploy?”

One daemon, no server

Architecturally, this is the most interesting decision in the project. Each computer runs a small daemon, and teammates’ computers connect directly — on the same Wi-Fi, or across the internet via iroh, the Rust networking stack from n0. If direct connection fails, traffic falls back to a relay that only sees encrypted bytes. By default that relay belongs to n0, but a team can run its own, at which point the team’s computers never contact n0 at all. Only team members can connect, and a computer can only speak for its own person — an identity constraint that does a lot of quiet work, since the whole design would be a liability if any machine could impersonate any teammate.

This is a genuinely different shape from the alternatives. The obvious way to build agent-to-agent messaging is a hosted service: a queue, a dashboard, an account per user, and a monthly invoice. Reason Network’s shape is closer to the old LAN-messenger tradition — think retro peer-to-peer office chat — rebuilt on modern hole-punching infrastructure so it works across networks, not just within one. Messages to someone offline wait and go out when they’re back. State lives in a dot-directory on your own machine. There is no server to maintain, which the README is quick to point out, and which is either a feature or a burden depending on how much your team enjoys operating infrastructure (a self-hosted relay is optional, and most teams won’t bother).

Delivery is tiered, and honestly so

The part most write-ups would gloss over is that message delivery is not uniform across the ten supported agents, and the README is unusually candid about it. Claude Code, Codex, opencode, pi, and Reason get messages mid-session, and idle sessions wake up to receive them. Cursor, Gemini, Copilot, and Grok see them at their next step. DeepSeek Harness only gets mail when it checks its inbox — every tool result tells it whether mail is waiting, which is a polite workaround for an agent that can’t be interrupted. Already-open Claude sessions join without a restart.

This tiering is not a marketing problem; it’s an accurate map of the underlying agents’ hook and interruption capabilities. Some agents can be pushed to mid-turn, some can only be nudged between turns, and some have to be taught to poll. Reason Network didn’t fix that inconsistency — it documented it. That’s the right call, and it tells you the authors have actually run this against every agent they claim to support rather than testing one and listing nine.

The approval flow is the real feature

Buried in the feature list is the thing that elevates this from convenience to infrastructure: ask_user. When a teammate’s agent needs something only a human can authorize, your agent pops up a question on your screen — Approve or Deny, with a note — and the answer goes back to the requesting agent as yours. The README is precise about why this matters: the answer is returned as your sign-off, not as a message anyone could send. In a world where agents can send messages to other agents, “yes, go ahead” is only meaningful if it’s cryptographically attributable to a person. This is the difference between a chat log and an audit trail, and it’s the piece that makes cross-team agent coordination survivable for organizations that have to answer for what their automation did.

There’s a companion notify behavior that pops a message onto the person’s actual screen as a heads-up — with the macOS quirk that notifications arrive via Script Editor and need to be allowed once in System Settings. Small rough edge, honestly disclosed.

From tincan to Reason

The project has a history, and it’s a telling one. It began as tincan, by Lars Talian, who now works at Reason — the company behind the Reason coding agent. The rename to reason-network came with a migration path: tincan’s last update moves each machine over automatically, and the old command keeps working on macOS and Linux. The provenance answers the obvious question about why a company would open-source this: Reason Network is the engine, and the Reason CLI wraps it. Sign in with Reason and your workspace becomes the team, your agents can reach Reason’s cloud agents, and the command becomes reason network. Skip the account and you get the standalone engine, a team link, and no cloud anything.

This is a reasonably honest open-core arrangement as these go. The peer-to-peer engine, the relay option, the MCP tools — all of it works without an account, and the account path is an upgrade, not a paywall around the core function. Still, it’s worth reading the README’s structure clearly: the no-account path is real, and the funnel toward the Reason workspace is also real. Both things are true at once.

Where it sits in a crowded field

The broader landscape context is thin in the available sources, but what’s there is consistent. The AI Coding Landscape catalog now lists dozens of coding agents, CLIs, and IDEs as distinct products — Claude Code, Codex, Cursor, Gemini, Copilot, Devin, Goose, and on — which is precisely the fragmentation that makes a cross-tool messenger necessary rather than nice-to-have. Anthropic’s Agent Teams solves coordination within one vendor’s agents; a writeup on collaborating with agent teams in Claude Code exists but its content wasn’t retrievable, so how its model compares in practice remains unclear. What is clear is that vendor-native team features don’t help the team running Codex next to Claude Code next to Cursor — which is most teams, because nobody standardizes on one agent anymore. Reason Network’s bet is that the messenger must be vendor-neutral by construction, and that the natural home for it is the peer layer, below all the vendors.

The general trend it rides is documented elsewhere: autonomous agents increasingly plan multi-step work, trigger actions like pull requests, and coordinate across tools with minimal human intervention. The industry has gotten good at agents doing things. It has not gotten good at agents doing things together, across a team, with attributable human sign-off. That gap is the project’s whole reason for existing.

(One naming hazard worth a sentence: search results for “Reason network” collide with Reason Studios, the music software company, whose own connection outages generate their own support noise. Unrelated products, unfortunate SEO. The tutorial videos are about the DAW, not the daemon.)

What to be skeptical about

The honest concerns are the ones the README half-acknowledges. First, trust: onboarding is built around a team link that teammates — or their agents — paste and run, and the README even includes instructions addressed directly to AI agents for joining a team from a link. An agent that joins teams from links is an agent that can be invited into things by whoever holds the link. The link format is documented and the install is checksum-verified, but the social-engineering surface of “tell your agent to join my team” is real, and the project’s own convenience features are what widen it.

Second, the default relay. Traffic that can’t connect directly goes through one of n0’s relays. It only sees encrypted bytes, and self-hosting removes even that — but “encrypted bytes through a third party” is a sentence security teams will want to read carefully before it becomes their team’s default. Third, the delivery tiers mean “messages land right away” is true for five agents and approximately true for the rest; teams standardized on the polling tier will experience this as async mail, not chat. And finally, the project is young and its momentum is tied to a single company’s product strategy; the MIT/Apache dual license and the standalone path are genuine, but the center of gravity is Reason, and open-source projects with that shape have a known failure mode.

Outlook

The open questions are the interesting ones. Will vendor-native team features — Anthropic’s Agent Teams being the visible example — expand until cross-tool messengers are squeezed? Or will fragmentation win, as the landscape catalogs suggest it currently is, making a neutral peer layer more valuable every time a new agent CLI ships? Reason Network is betting on fragmentation, and the bet looks sound: the landscape keeps growing, not consolidating. The harder question is whether teams will hand their agents an always-on presence channel to each other’s machines at all. The approval flow suggests the authors understand the answer has to be yes-with-attribution, not just yes.

What Reason Network got right is the unglamorous insight: agents already know what they’re doing, machines can already find each other, and the missing piece was a small, honest daemon that connects the two — plus a pop-up that means your “yes” is actually yours.