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 breaks 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 could break out of its sandbox with simple herdr commands.
That's not great but my sandboxing approach wasn't great either since it didn't prevent API key discovery or abuse of MCPs and other agent tools. It might still be nice if herdr restricted inter-tab communication to the current workspace since that's where I need it most.
Running agents in proper sandboxes like CloudFlare workers or Daytona would address this but then I'd lose all the benefits of herdr. No one has really figured out how to secure coding agents yet anyway.