shefrd

Vision

Running one coding agent is a conversation. Running six is an operations problem, and terminal tooling was not built for it. You lose the thread of which agent is waiting on you, which has been idle for an hour because it finished, and which is quietly burning tokens down a path you would have stopped.

shefrd treats that as the actual product. Agents are not tabs you remember to check; they have states, and the interface is built around showing them. Something blocked and something done look different from across the room, and getting from a status to the pane that explains it is one movement.

Where it came from

shefrd is a hard fork of herdr, Apache-2.0, maintained as a thin patch layer on upstream so improvements keep flowing in. Every herdr plugin runs here unmodified, and that compatibility is a hard requirement rather than a goal: the socket API, the manifest format, the environment contract and the config directory are all deliberately untouched.

Where it is going

Two things distinguish it from upstream.

The first is that features are built in and reviewed, not installed. The plugin ecosystem solved real problems, and it solved them by asking every user to trust a stranger's code with their terminal, their agents and their repositories. shefrd absorbs those capabilities as first-class features, each one reviewed by several independent agents before it ships, so turning one on is a toggle rather than a supply-chain decision. A feature you leave off costs nothing at all, which is the part that has to be true for this to be the better deal.

The second is the renderer. Every ceiling this fork has hit is the same ceiling: it is a guest inside somebody else's terminal. Image previews need a graphics protocol the host may not implement. A real browser view inside a pane needs pixels the multiplexer cannot draw. Owning the renderer dissolves all of it at once, and that is what the desktop app is for.