herdr: Enabling Different AI Agents to Message Each Other at the Terminal Layer

herdr is a Rust terminal multiplexer that lets heterogeneous AI coding agents communicate across ecosystems at the terminal layer.
herdr is a terminal multiplexer built for AI agent collaboration, written in Rust as a single binary. Unlike general tools like tmux, herdr recognizes each agent running in its panes and tracks four states — Working, Block, Idle, and Unknown — so you can see at a glance who's busy and who's waiting. Its key design: a CLI built for agents to use themselves, making cross-agent messaging an atomic one-liner. Unlike Claude Code's application-layer approach (Claude-only), herdr works at the terminal layer and supports any recognized agent, with 17 officially integrated tools today.
Starting with Claude Code's New Feature
Yesterday, Claude Code officially rolled out an update: your sessions can now send messages to each other. This feature addresses a genuine pain point — previously, every time you switched sessions, you had to re-explain all the context and background from scratch, which was time-consuming and tedious. With cross-session messaging, you can now have one Claude session directly "talk" to another, eliminating a huge amount of repetitive work.
This feature is genuinely useful, but it has one obvious limitation: the communication only happens between Claude and Claude. In other words, the official implementation is an "application-layer" integration — Claude sends a summary to Claude, and it's inherently locked within the same ecosystem.
If you're also using Codex, Cursor, or other coding agents, there's no official channel for them to communicate with each other. The tool we're introducing today — herdr — takes this capability to an entirely different level.

What is herdr
herdr is a terminal multiplexer written in Rust, compiled into a single binary, installable with a single cargo install command. Its official positioning is straightforward: your coding agents live on herdr.
If you've used tmux, herdr's foundation will feel familiar — both manage multiple panes within a terminal. But the problems they're solving are fundamentally different.
tmux answers one question: Is the process still alive? It's a general-purpose session management tool that doesn't care what's running in your panes.
herdr answers a different question: The process is alive — but who is it waiting for? This is a design philosophy built specifically for AI Agent collaboration. It recognizes which agent is running in each pane and maintains a finite state machine for each one.
Four Agent States at a Glance
herdr tracks the following states for each agent:
- Working: Currently doing work
- Block: Stuck waiting for you to make a decision
- Idle: Finished its work but you haven't checked yet — nothing to do
- Unknown: Current state cannot be determined
When you're running five or six agents simultaneously, this design proves its value immediately — a quick glance at the sidebar tells you who's working and who's waiting for you, without having to check each pane individually.

A terminal multiplexer is a class of tools that allows users to manage multiple independent terminal sessions within a single terminal window. The most well-known implementations are tmux and screen. Their core value lies in decoupling processes from terminals — even if a user disconnects an SSH session, processes running inside the multiplexer continue to live on. They also support pane splitting, so the output of multiple processes can be displayed side by side on the same screen. For AI agents — workloads that run for extended periods and are often launched as multiple simultaneous instances — terminal multiplexers are a natural hosting environment. herdr inherits this foundational capability and builds on top of it a state-awareness and inter-process communication layer specifically designed for agent collaboration.
A Finite State Machine (FSM) is a model in computer science that describes how a system transitions between a finite number of discrete states. herdr maintaining an FSM for each agent means it doesn't just passively display an agent's output text — it actively parses that output, using pattern matching and similar techniques to identify which phase the agent is currently in. For example, if an agent outputs a prompt waiting for user input, it's classified as Block; if the output stream stops but the process is still running, it's classified as Idle. This state-driven design enables herdr to coordinate actions like "wait for the other agent to finish before sending a message" — rather than blindly firing off commands.
Core Capability: A CLI Designed for Agents
herdr's most critical design decision is this: its command-line interface is designed to be used by agents themselves, not just by humans.
This means having one agent send a message to another is a single command: herdr agent prompt. Going further, "send a message" and "wait for the result" can be composed into a single atomic call — the sending agent can wait directly for the other's response, forming a complete collaboration loop.
There's a carefully chosen line in herdr's documentation: it doesn't wrap or replace any agent — it simply owns their terminals. This captures its design philosophy — herdr doesn't interfere with any agent's internal logic. It achieves agent identification and communication purely by controlling the terminal layer.
This "terminal layer" positioning is exactly what differentiates it from Claude Code's official approach.

Hands-On: A Conversation Between Three Agents
I actually tried this out myself: opened three panes running three agents — Pi, Pimmy, and Hermes.
I then had Pi send Hermes a message: "Hi, greetings from herdr." The moment the message was sent, Hermes's status immediately changed from Idle to Working, as it began processing how to respond. Pi, meanwhile, behaved like someone waiting for a reply — checking Hermes's terminal every few seconds, and upon detecting activity, called out "It worked!"
The whole process demonstrated the complete chain of autonomous agent collaboration: initiation, waiting, sensing the other party's state, and confirming the result.
The most amusing moment was Hermes spending the entire time trying to figure out what "herdr" actually was — it even suspected it might be the name of a Feishu (Lark) bot. Watching an AI work hard to understand the identity of an unfamiliar tool was quite vivid.

Application Layer vs. Terminal Layer: Two Different Approaches
Coming back to the Claude Code update we started with, here's a clear comparison of the two approaches:
Official Approach: Application-Layer Integration
- Communication happens at the application layer
- Claude sends summaries to Claude
- Limited to the Claude ecosystem
- High integration quality, works out of the box
herdr Approach: Terminal-Layer Integration
- Communication happens at the terminal layer
- Any agent recognized by herdr can message any other
- Currently 17 officially integrated agents, including Claude Code, Codex, Open Code, Pi, Cursor, and more
- Requires user setup and configuration
One thing worth noting: both approaches fundamentally enable agents to start talking to each other. But the terminal-layer path clearly fits a much wider range of scenarios.
The distinction between "application layer" and "terminal layer" corresponds to different levels of integration abstraction. Application-layer integration requires both parties to use the same SDK or API protocol — it's essentially a feature the platform vendor actively exposes, giving the platform full control over data formats and content. The advantage is a polished integration experience with clear security boundaries, but it inherently creates ecosystem lock-in. Terminal-layer integration bypasses application-layer protocols entirely, intercepting and injecting at the OS process and I/O level. By "owning the terminal," herdr can write to any process's stdin and read from its stdout — requiring no interface contracts with the agent whatsoever. As long as an agent runs in a terminal and its state can be recognized, it can be brought into the collaboration system. The tradeoff is higher setup overhead and a dependency on herdr's own maintenance of output-format adapters for each agent.
What Kinds of Workflows Can You Build
The biggest opportunity that terminal-layer communication unlocks is cross-agent automated workflows.
The most direct example: after Agent A finishes writing code, it automatically sends the result to Agent B to do a code review. You can build this kind of workflow with herdr today — without waiting for some vendor to ship an official application-layer integration.
More broadly, as multi-agent collaboration becomes a new trend in coding, "who handles which stage, and how context is passed" will become a critical question. herdr's non-invasive, terminal-owning approach provides a lightweight and flexible foundation for collaboration between heterogeneous agents.
For developers who are simultaneously using multiple AI coding tools, herdr is worth trying — it doesn't force you to migrate to any particular ecosystem. Instead, it teaches your existing agents to "talk to each other."
Related articles

BearDrive: The Open-Source Shared Folder for AI Agent Teams — New Infrastructure for Multi-Agent Collaboration
BearDrive is an open-source, self-hostable shared folder for AI agent teams. It auto-syncs local files from Claude Code, Codex, and Gemini CLI with versioning and agent attribution.

How to Eliminate 1,400 CVEs from Your Container Images
How NanoClaw eliminated 1,400 CVEs from container images using minimal base images and multi-stage builds — a practical guide to container supply chain security.

GPT-6 Astra Tested: SVG Generation Quality Surpasses Entire GPT-5.6 Lineup
Developer Simon Willison benchmarks GPT-6 Astra vs GPT-5.6 series on SVG generation. Astra's lowest reasoning level beats GPT-5.6 Sol's best, with better token efficiency and lower real-world cost.