A Clock and a Queue: Two Plugins on Herdr

Most tools for running coding agents make the same bet: that you will sit in front of them. Herdr makes the opposite one. It is not an app you keep open — it is a server running in the background, and the terminals live inside it. Close the lid, drop the network, and the agents keep working. Restart the machine and the layout comes back and their sessions resume. A sidebar marks each agent working, blocked or idle, so you don’t go pane by pane looking for whoever is waiting on you. My current session has three workspaces and four agents in it, two of them mid-task, with nobody attached to any of it.

That is what got me off Emdash. Emdash is a good app, and I used it as my agentic development environment for a while: a real GUI, a built-in browser, prompts and MCP servers managed in one place. But once my agents were living in Herdr’s terminals, one thing I relied on was gone — repeat work, on a schedule. The second plugin came from somewhere else: an idea that had been in my notes for a while, and that I finally had a runtime to try it on.

Herdr’s plugin system is why I could build both.

Thin plugins, because Herdr already has the hard parts

A Herdr plugin is a directory with a manifest and commands Herdr can launch. Write it in Bash, Go, Rust, whatever your machine runs. Herdr owns the host surface — installation, keybindings, terminal panes, events, invocation context, socket access — and the plugin owns its language, its files and its state. There is no plugin SDK, because the entire Herdr CLI is the plugin API.

That last sentence is the whole design, and it is why the plugins stayed small. The command my plugin runs to open a workspace is the same command my agent runs to open a workspace. No private hooks, nothing to reimplement, nothing to break on a Herdr upgrade. So I left workspaces, worktrees, panes and agents to Herdr, and kept in the plugins only the two things it does not have: a clock and a queue.

Both plugins put their UI in a pane, which is the same pane model the agents use. A board is a pane you bind to a chord:

[[keys.command]]
key = "prefix+a"
type = "shell"
command = "herdr plugin pane open --plugin dnzzl.automations --entrypoint board --placement overlay"

herdr-automations: the clock

The first plugin ports the one Emdash feature I missed on day one — repeat work. One YAML file, a prompt, a cron line:

automations:
  - name: issue-triage
    cron: "0 9 * * 1-5"
    repo: ~/Projects/myapp
    model: sonnet
    prompt: |
      Triage new GitHub issues: label them, close duplicates,
      draft replies for the ones needing more info.

Every weekday at 9:00, an agent starts in a fresh worktree on auto/issue-triage-<timestamp> and works until it is done. A run that goes sideways is a branch I throw away, not a mess in my working copy. The scheduler reads the wall clock rather than arming a timer, because macOS suspends the monotonic clock when the laptop sleeps — an occurrence that came due overnight fires when the machine wakes, and anything older than the catch-up window is recorded as missed instead of vanishing. The board pane shows each automation’s next run and last status, r fires one now, and enter drops me into the terminal the last run opened.

What it is not: a workflow engine, or an event system. Herdr’s plugin manifest has events, but as of 0.8.2 they are workspace, tab and pane lifecycle — no push, no pull request. A cron automation that polls and does nothing when there is nothing new is one entry in the file, and I decided that was the honest boundary.

herdr-docket: the queue

The second plugin is the one I actually wanted. paperclip.ing runs a company of agents — an org chart, goals, budgets. I do not need a company. I wanted the smallest version of that idea that still works, embedded in the runtime I already had.

herdr-docket is a shared task queue worked by named agents. The queue is a Backlog.md project by default — or Basecamp, or a GitHub Projects board, if the work already lives there. An agent is one markdown file: YAML frontmatter for the run parameters, body for the persona every run opens with. A daemon polls every ~15 seconds and, for each idle agent, picks its most urgent open task, provisions a Herdr workspace on that agent’s repo, and starts a real coding agent with the persona plus the task. The agent reports back with herdr-docket task note and closes itself with done, fail or block.

The useful part is how little you hand over. The fleet only ever picks up the one status you name as todo — so a project with a triage column, a wontfix column and a waiting-on-a-human column keeps all three. Autonomy is a set of levers, one per line of config: whether a reviewer gates the dev’s pull requests, whether the failure column is a real Failed or a human’s inbox, and what a day costs via runs_per_day and minutes_per_day. One task per agent at a time, and root-mode agents sharing a checkout are serialized, so parallelism is bounded by what a git working copy can survive.

And the two plugins compose. Automations decide when; docket decides what and who:

prompt: |
  Check the queue and create a task for anything that needs follow-up.

Two people showed up

Both plugins are young and small, so I assumed I would be the only person touching them for a while. Then one release carried patches from two people I have never met.

Oliver Lukschander added workspace: existing, so an hourly automation opens a tab inside one workspace instead of burying the sidebar in a new worktree per run. Terry Li caught that model: on a pi automation was rejected at load, because pi was missing from an allowlist. His PR also proposed a separate provider: field, which I did not take — Pi’s --model already accepts a provider/id pattern — but he found the bug and the fix is his.

That is the whole story: two small patches on a plugin I wrote for myself, from people who had no reason to send them.

Why I think this one sticks

Herdr joined Y Combinator in August and raised a $6M seed in September, and the runtime is Apache-2.0 and stays open. That matters to me less as news than as a reason the plugin API I just bet two projects on will still be there next year. 38,000 stars and 1,100 community plugins say I am not the only one making that bet.

I have stopped opening Emdash. My morning starts with herdr-automations list and a board with a task on it. That is the only endorsement I have.