I've been using herdr for day-to-day coding with my favorite agent pi. Here's its special power: I can run a herdr command to talk to any other agent running in any other terminal. I can run a herdr command to reconfigure my terminal layout on the fly. With the herdr skill, agents know how to run all of these same commands so they can help me debug servers, read terminal output, etc.
I was excited enough about this to make a demo 😊
Here are my dotfiles if you want to see how I configured it.
This feels like the right abstraction. Being able to see all subagents under control of an orchestrator right there in my terminal beats making a custom subagent viewer. Telling an agent to look at all running terminals so it can diagnose a problem is a huge unlock. All of this was possible before but I'd have to give the agent special access to a server or point it at a specific log file, etc.
Security
The herdr command does wat? Yeah, so, anything running as my user can now connect to the local herdr socket and control any process in any herdr workspace.
This broke the way I like to sandbox my pi agents.
I usually run them with sandbox-exec on macOS to restrict writes to their current directory (with some exceptions like ~/.cache).
I'm not paranoid but I've seen too many agents try to be "helpful" by reconfiguring my system.
Now, with herdr, any agent running in a sandbox could use herdr to get access to another shell or agent and do whatever.
That's not great but my sandboxing approach wasn't great either since it didn't prevent API key sharing or abuse of MCPs and other agent tools. It might be nice if herdr added something like workspace isolation to restrict communication between tabs and agents to the current workspace.
Running agents in a proper sandbox like on CloudFlare or Daytona would solve it but then I'd lose all the benefits of herdr. No one has really figured out how to secure coding agents yet anyway.