I have been using AI since before the OpenAI boom made GPT models the default answer to everything. Back then it felt like autocomplete with a good memory. Now it is closer to a junior engineer that can act, check what happened, and try again.

That change did not come from one magic model. It came from a stack of smaller changes:

  • loops, so the model does not answer once and stop
  • tools, so it can run commands, read files and call APIs
  • larger contexts, so it can keep a repo or a long session in its head
  • reasoning models, so it catches more of its own mistakes before I see them
  • test, lint and compiler feedback, so it can fix the errors it created
  • harnesses like Claude Code and opencode, which put all of that inside a real repository

Over the last year and a half my AI usage kept growing, but I still felt I was leaving work on the table. One-off prompts were not the problem anymore. The problem was all the routine work I knew an agent could do, but that still needed me to be at my laptop, open a terminal, pick the right machine and start it.

At the same time I moved from tmux automation to herdr. I had built Techno Haze to make tmux more agent-friendly, but the more AI-specific behavior I added, the more fragile it became. Herdr gave me a cleaner terminal layer. It could own the panes and expose an API for agents.

I still needed something above it. Something that could decide where work should run, create the workspace, start the agent, send the prompt, watch the state, and let me reconnect later.

That is where Pastor came from.

pastor machine list, task run, task list and task read

Pastor is a task and job scheduler for coding agents. It controls a flock of machines running herdr. I give it a task like “fix this flaky test in this repo”, and it picks a machine, opens an agent there, optionally in a fresh worktree, sends the prompt, and keeps an eye on it until the agent stops or gets blocked.

A job is the same idea, but recurring. Every hour, or on a cron schedule, Pastor asks a connector for work and creates tasks from the items it has not seen before. Today the built-in connector is clock, which is enough for periodic maintenance jobs. GitHub, Slack and other event sources are where this gets more interesting next.

The tool became useful once it left the happy path. Every version after 0.1.0 was built using Pastor itself and the Raspberry Pi 5s I had lying around. That is where most of the lessons came from.

  • Knowing when an agent is really done is hard. An idle agent can be finished, waiting for me, or stuck. Pastor has to tell those apart without reading the agent’s screen.
  • Work and personal machines cannot mix. One machine has access to work accounts, and a personal task landing there is not acceptable. That is why flocks and tags matter.
  • Races show up everywhere. Two commands touch the same config, a scheduler starts while another run is still active, or a queued task has no machine that can ever take it.
  • Machines drift. An older binary can silently ignore new settings unless the fleet exposes versions and protocols.
  • Agents move faster than I can review. I once merged a pull request with red CI. Since then, no agent work gets merged without green CI and a clean review.
  • The repo is public. Nothing from my machines, paths, users or addresses can leak into code written by an agent.

Pastor changed my job in the loop. I write a short plan. Pastor hands it to an agent. Copilot reviews the pull request. Another agent can fix what the review found. My time moves from typing to deciding.

That is the part I care about most. Not replacing the engineer, but changing where the engineer spends attention.

a job file, pastor job list, job run and the task it made

Right now Pastor can:

  • manage a flock of local and SSH machines
  • keep machine limits, tags, herdr versions and busy state visible
  • run one-off tasks in a repo or a fresh worktree
  • place tasks by tag or pin them to a machine
  • pass agent arguments, so a task can choose a model or harness behavior
  • run scheduled jobs with every or cron
  • keep job state, seen item keys and task history in SQLite
  • read, attach to and send input to an agent from the shell
  • open the full herdr UI for a fleet machine
  • write an event log for task, job and machine changes
  • install itself and herdr as user systemd services

The next things I want are connector plugins, event hooks, better machine identity owned by herdr, moving tasks between machines, and a tester job that keeps Pastor’s own checks running on the fleet.

The source and manual live at cacarico/pastor.