What happened
Reason Network’s release notes list v0.12.13 as released on October 25, 2026. The headline change connects Hermes conversations to Reason Network: a plugin gives each conversation its own network address. The notes say the plugin turns on with a Hermes version that has the required plugin APIs; until then, the MCP server works as before. This makes the integration dependent on the Hermes runtime’s available plugin surface rather than replacing the existing MCP option outright.
The release also describes a session convention for the associated skill: one task per session, with conversations starting at person/session@machine. That address shape expresses the intended scope—person, session, and machine—rather than treating all conversations as one undifferentiated network endpoint. The notes separately clarify that Gemini CLI has one session per window, not two, and say a Codex installation on Windows made with npm can receive messages that span several lines.
For troubleshooting, users can opt into connection-event logging by setting debug_log = true in config.toml. The release notes say this writes events to debug.log on that computer to help investigate why a connection drops or moves to a relay. The setting is off by default, and the log leaves out message text, links, and keys. Other setup fixes include no longer waiting on a hermes --version command that hangs and handling Windows npm shims more carefully.
The release page also lists changes to the Hermes integration, including a shared acknowledgment lock, a bounded version probe, and the plugin’s tool names. It does not describe a pricing change or a general availability announcement; this is a software release for users of the project. The broader release history on the same page includes subsequent versions, so v0.12.13 should be understood as a specific dated step in an actively changing project, not necessarily the current version.
What the archive adds
New Runtime’s earlier coverage on October 22 described Reason Network as an open-source Rust daemon connecting coding agents peer-to-peer across teammate machines (Reason Network and cross-machine coordination). That earlier note framed cross-machine coordination as the collaboration unit. Version 0.12.13 is a new fact on that known story: Hermes conversation-level addresses extend the project’s integration surface to another agent environment.
Trend signal
This supports the pattern that agent protocols are becoming an interoperability layer: agent protocols become the interoperability layer. The Hermes plugin and existing MCP server offer different ways to connect an agent environment to the same network. The evidence is narrow—a release note, not proof of broad adoption—but it shows a practical integration boundary developing around conversations and tools.
Why now
The release notes tie activation to Hermes versions that expose the needed plugin APIs, making compatibility a condition for use rather than an assumed universal capability. That pairing indicates the integration is timed to the availability of those APIs. The source does not state a broader launch rationale or adoption target.
Why it matters
For teams running agents on several machines, the distinction between a user-level network address and a conversation-level address can affect how work is routed and isolated. If each Hermes conversation is addressable independently, builders can reason about where a message belongs without treating every conversation from one operator as a single endpoint. That can make coordination easier to compose with session-based workflows, particularly when different tasks need distinct contexts.
The release also exposes a modest operational control: opt-in local connection logs can help diagnose drops or relay transitions without recording message text, links, or keys, according to the notes. That is useful when evaluating network behavior, though it is not a substitute for testing how the whole system handles identity, permissions, retries, and message delivery in a team’s own setup. The practical value is therefore clearest for existing Reason Network and Hermes users, not for builders looking for a general-purpose messaging layer.
What happens next
- Hermes integrations will increasingly use conversation-scoped network addressing. (6 months, 55%). Watch for: later Reason Network releases adding or documenting further agent integrations that assign addresses at session or conversation level.
Limits and uncertainty
The release notes describe the integration and its activation condition, but do not report deployment counts, reliability measurements, or comparative results against the existing MCP path. They do not establish whether the plugin is enabled by default in any Hermes release or how teams should configure identity and permissions in production. Reason Network’s release notes are a project-authored account, not an independent evaluation. Builders should verify compatibility with their installed Hermes version and test routing, delivery, and logging behavior in their own environment before relying on the integration for important work.
Skill to build now
If your team uses both Hermes and Reason Network, test the integration with a disposable Hermes conversation on two machines. Confirm the conversation’s address and message flow, then deliberately test a disconnected or relayed connection with debug_log = true. Inspect the local log for connection events and check that the expected message content, links, and keys are not present before deciding whether the diagnostic mode is appropriate for your team.
Reader takeaway
Reason Network v0.12.13 makes Hermes conversations addressable on its peer network, subject to Hermes plugin-API support. It is a useful integration step for teams already using both tools, but the release notes do not establish production-scale performance or adoption. Treat it as something to test in a bounded workflow, not as evidence that cross-machine agent coordination is solved.