Herdr: The Runtime Around Your Coding Agents
Herdr is a terminal workspace manager for coding agents, and the question here is what that description means in practice. It does not replace Claude Code, Codex, OpenCode, or another agent; it owns the terminals in which those tools run, keeps their work visible, and gives humans and automation a shared place to act. Understanding that boundary lets a reader judge the rest of Herdr more accurately: when a client can disappear without stopping work, when an agent status is useful evidence rather than certainty, and why a saved layout is not the same thing as a saved process.
The problem is not a lack of terminals
A single coding agent is easy to picture. A terminal is open, the agent is working, and a person can type an answer when the agent asks for one. The difficulty changes when several projects are active at once. One agent may be waiting for approval, another may be running tests, and a third may have finished while its terminal is hidden behind a different window. The work is not necessarily lost, but the relationship between work and attention becomes hard to see.
Closing the terminal creates a second problem. In a conventional workflow, the terminal window often feels like the place where the process lives. Close it, lose the connection, or disconnect an SSH session, and the user must worry that the shell, server, test run, or agent has gone with it. A terminal multiplexer can keep processes alive, but the user still has to inspect panes manually. Herdr addresses this operational gap by placing a background server between the person and the programs they run.
More terminals do not automatically create a better operating picture. They multiply places to look, but they do not tell a person which process is waiting for a decision, which one is still active, or which one has finished out of sight. The human bottleneck is often attention, not terminal capacity. Herdr's project documentation treats that bottleneck as part of the runtime problem: agent state is surfaced across workspaces so the person can move toward the pane that needs an answer instead of polling every terminal by hand.
That framing also explains why Herdr uses a project-level workspace rather than treating every pane as an isolated window. A repository, task, or investigation can have a place of its own, with the related terminals kept together. The point is not to impose a particular development process. It is to make the relationship between a running process and the work it belongs to visible enough that a person can leave it, return to it, and make a deliberate choice about the next interaction.
That distinction matters because Herdr is not an agent platform in the sense of supplying a model, a prompt strategy, or a replacement interface for every tool. Its own project description calls it “the runtime your coding agents live on.” The phrase is useful when read literally: Herdr manages the environment around an agent. The agent remains the program that interprets requests and performs coding work; Herdr supplies a persistent, structured, observable terminal context.
This also keeps the central question concrete. The value of Herdr is not simply that it can split a screen. The more consequential question is whether a person can leave a running body of work, return to it, identify which part needs attention, and control the right terminal without confusing one project or machine with another.
Herdr owns the place where work happens
By default, Herdr has a background server and one or more attached clients. The server owns the panes and the process state. A client is a view and an interaction path: it renders terminal surfaces, forwards input, and lets a person navigate the runtime. If the client detaches, the server remains, so the shells, agents, servers, tests, and other commands in its panes can continue running. Reattaching later reconnects to that same live runtime.
The server can run without a person currently attached. In that headless condition it does not need to read the user's keyboard or render directly into a physical terminal; it continues its event loop, maintains PTYs, and can stream a newly attached client the current surface. This is the architectural reason Herdr can be used locally, after logging into a remote machine, or through a local interface bridged to an SSH-hosted server. The screen may change location, but the process owner does not silently change with it.
There is an important consequence for troubleshooting. If a client looks stale or a network path disappears, that does not by itself establish that the agent stopped. Conversely, reconnecting to a server does not establish that every piece of earlier conversation or screen history is still available. The client/server split answers the question of who owns a live process; other persistence mechanisms answer what can be reconstructed after the owner itself stops.
The distinction is easiest to hold onto as a simple ownership rule: the client shows the work; the server keeps the work alive. That rule is stronger than a visual analogy with a terminal window. It explains why ctrl+b q is a detach operation rather than a stop command, and why stopping the Herdr server is a materially different decision. The latter ends the server-owned processes; the former leaves them in place.
Herdr adds structure around that server without turning the structure into a second kind of process manager. A session is a persistent server namespace. The default session is what an ordinary herdr launch attaches to; a named session is a separate namespace with its own runtime state and sockets. Within a session, a workspace is a project or investigation container. A workspace owns tabs, and each tab contains a layout of panes. A pane is a real terminal, not a card representing a terminal somewhere else.
This hierarchy is useful because each level answers a different coordination need. A workspace can represent one repository or task. Its tabs can separate an agent view from logs, a server, or a review surface. Its panes can then be split or rearranged as the work changes. Herdr's CLI and socket API can address those objects directly, so a script does not need to simulate mouse clicks or assume that the currently focused terminal belongs to the intended project. The identifiers are meaningful as handles within the running server, while their scope remains part of the safety model.
A layout change also need not be a process change. Moving or swapping a pane changes where the terminal appears in the topology; it does not turn the shell or agent into a new program. That separation is what lets a person organize a busy workspace while work continues. It also creates a boundary that later matters for restoration: a layout can be saved and recreated more easily than the arbitrary state of every program inside it.
An agent is a process Herdr recognizes inside a pane. That last distinction is important. A pane can exist with an ordinary shell, test runner, editor, or server and still be useful. When the foreground process looks like a supported coding agent, Herdr can attach an agent identity and state to the terminal. The agent is therefore an occupant of a pane, not a replacement for the pane or a new layer that hides its input, output, and running processes.
These scopes answer different questions:
- The session asks, “Which independent Herdr runtime is this?”
- The workspace asks, “Which project or body of work does this belong to?”
- The tab asks, “Which arrangement of terminals am I viewing?”
- The pane asks, “Which real terminal should receive input or show output?”
- The agent asks, “What recognized coding process is currently occupying that terminal?”
The model can be pictured as a route from a human-facing client to a server-owned process. Detaching removes the view, not the runtime beneath it.
Visibility changes what persistence is worth
Once the ownership model is clear, persistence and awareness stop looking like unrelated conveniences. A background server makes live persistence possible: the original process remains in the same pane even when the person is not currently looking at it. The workspace and tab model make that runtime legible: the person can separate an API project from its logs, a review task from its tests, or one investigation from another without opening an unrelated collection of terminal windows.
The sidebar adds a second kind of value. Herdr can roll information about recognized agents upward so a workspace can signal that one of its panes is working, blocked, or ready to inspect. A person does not have to infer importance from whichever terminal happens to be visible. This is not the same as knowing that an agent produced a correct change. It is an attention signal: a way to decide where to look next.
That distinction is why observability belongs beside persistence. A process that survives disconnection but cannot be found is durable yet easy to neglect. A dashboard that shows agent states but does not own the terminals still leaves the user exposed to lost sessions. Herdr's design joins the two by keeping terminal processes in a server and exposing enough structure to inspect them through the UI, CLI, and socket API.
The word “blocked” should be read as an invitation to inspect, not as a verdict about the work. An agent may need an approval or a decision, but Herdr is not claiming that the agent's proposed change is correct. Likewise, a “done” indication tells a person that a completion has not yet been seen in the relevant presentation state; it does not certify the result. This distinction keeps the attention surface useful without making it a substitute for review.
It also makes the runtime legible to more than one kind of participant. A human can click the agent row and read the pane. A script can query the same server and act on a discovered target. An agent operating inside Herdr can use its inherited context to coordinate with neighboring panes. These are different interaction styles over the same owned runtime, not separate copies of the project's state. The shared model is what gives the later API and integration features a place to attach.
The human entry point is deliberately less demanding than the underlying model. Herdr is mouse-native: panes, tabs, workspaces, agents, split borders, and menus can be reached by clicking and dragging. Keyboard control is optional. Its default prefix, ctrl+b, exists because shells, editors, and agents already use most ordinary key combinations; reserving a prefix is safer than intercepting typing throughout every pane. A user can begin by opening a workspace, starting an existing agent in a pane, and returning later, without first memorizing a large command set.
The practical judgment this creates is modest but powerful. Herdr is a good fit when the problem is not “I need a different coding agent,” but “I need several existing agents to remain attached to real workspaces, remain visible when they need me, and remain controllable after the client or network path changes.” It is less useful to treat it as a guarantee that every agent conversation, screen, or arbitrary process can be reconstructed after any failure. Those are separate mechanisms with separate limits.
The next step is to inspect the running session more closely: how the background server, clients, PTY-backed terminals, and workspace topology divide responsibility while work is live. That architecture will make the later distinctions—between an agent's state, a saved layout, a resumed conversation, and a transferred process—precise rather than merely intuitive.