Agent Junction: letting Claude Code instances talk to each other

Here's a problem I kept running into with Claude Code: I'd have multiple sessions open, each working on different parts of a project or different repos entirely, and one session would need information that the other one had already figured out. A config path, an environment variable, an API endpoint, a decision about which approach to take. And I'd end up manually copying and pasting between terminal windows like a human clipboard. It felt absurd -- these are AI agents, and I'm the bottleneck in their communication? That friction motivated me to build Agent Junction.

An encrypted message bus for AI agents

Agent Junction is an MCP server that creates an ephemeral, encrypted peer-to-peer message bus. You start the server (a single npx agent-junction command), each Claude Code instance connects via its MCP config, and they can immediately discover each other and exchange messages. Each session gets a memorable, human-readable alias like "crimson-falcon" or "jade-panther" so you can reference agents in conversation without needing to track session IDs.

The tool surface is deliberately minimal: register to join the junction and get your alias, list_peers to see who else is connected, send_message to send an encrypted message to a peer by alias, read_messages to consume your inbox (destructive read -- messages are deleted after retrieval), known_hosts to list pre-configured LAN machines, and disconnect to leave cleanly. Nothing persists to disk. Ever.

The security model I obsessed over

Agent-to-agent communication is inherently sensitive, and I wanted the security model to be bulletproof for the threat model it addresses. Messages are encrypted with AES-256-GCM using per-session keys and random IVs -- every session gets its own encryption key, and every message gets its own initialization vector. Reads are destructive, meaning messages are deleted the moment they're retrieved. When a session disconnects, its encryption keys are zeroed out (overwritten with 0x00 bytes, not just dereferenced). Idle sessions are automatically purged after a configurable timeout (30 minutes by default). And everything lives in memory -- there's no database, no log files, nothing written to the filesystem.

This ephemeral design was a deliberate choice. Agent Junction is meant for real-time coordination, not persistent messaging. If you need message history, you're looking for a different tool.

From localhost to LAN

By default, Agent Junction binds to 127.0.0.1 so only sessions on the same machine can talk. This is the safe default for solo development. But set JUNCTION_HOST=0.0.0.0 and it opens up to your LAN, letting Claude Code instances on different machines communicate. I use this when I have sessions running on my desktop and a VM simultaneously. You can even define named known hosts with JUNCTION_KNOWN_HOSTS="workstation=10.0.0.6,vm=10.0.0.4" so agents can discover machines on your network by name rather than IP.

The implementation under the hood

Agent Junction uses MCP's streamable HTTP transport, which means it runs as a standard HTTP server with an /mcp endpoint for MCP traffic and a /health endpoint for monitoring. The health check returns the server mode (localhost or LAN), number of active peers, and uptime -- handy for quick diagnostics. It's published on npm, so installation is just npm install -g agent-junction, or you can clone the repo and build from source if you want to hack on it.

Where this fits in the bigger picture

Agent Junction sits at an interesting intersection in the multi-agent AI landscape. Most multi-agent frameworks (CrewAI, AutoGen, LangGraph) handle agent coordination within a single process or orchestration layer. Agent Junction solves a different problem: coordination between independent agent sessions that might be running in separate terminals, on separate machines, or even started at different times. It's infrastructure for the "Claude Code as workstation" pattern where you have multiple long-running sessions, each with their own context and capabilities, that occasionally need to share information.

I think this pattern is going to become increasingly common as people build more complex agentic workflows. The human shouldn't be the message bus. Check out the full repo on GitHub -- contributions and feedback are welcome.