Eu uso IA desde antes do boom da OpenAI transformar modelos GPT na resposta padrão para tudo. Naquela época parecia um autocomplete com boa memória. Hoje está mais perto de um engenheiro júnior que consegue agir, verificar o que aconteceu e tentar de novo.

Essa mudança não veio de um modelo mágico. Veio de uma pilha de mudanças menores:

• loops, então o modelo não responde uma vez e para
• ferramentas, então ele consegue rodar comandos, ler arquivos e chamar APIs
• contextos maiores, então ele consegue manter um repositório ou uma sessão longa na cabeça
• modelos de raciocínio, então ele pega mais dos próprios erros antes de eu ver
• testes, linters e compiladores no loop, então ele consegue corrigir os erros que criou
• harnesses como Claude Code e opencode, que colocam tudo isso dentro de um repositório real

No último ano e meio meu uso de IA cresceu muito, mas eu ainda sentia que dava para fazer mais. Prompts avulsos já não eram o problema. O problema era o trabalho rotineiro que eu sabia que um agente conseguiria fazer, mas que ainda precisava de mim no notebook, abrindo terminal, escolhendo a máquina certa e iniciando tudo.

Ao mesmo tempo eu migrei de automações em tmux para o herdr. Eu tinha criado o Techno Haze para deixar o tmux mais amigável para agentes, mas quanto mais comportamento específico de IA eu adicionava, mais frágil ficava. O herdr me deu uma camada de terminal mais limpa. Ele podia cuidar dos painéis e expor uma API para agentes.

Ainda faltava algo acima dele. Algo que decidisse onde o trabalho deveria rodar, criasse o workspace, iniciasse o agente, enviasse o prompt, acompanhasse o estado e me deixasse reconectar depois.

Foi daí que veio o Pastor.

Pastor é um agendador de tarefas e jobs para agentes de código. Ele controla um rebanho de máquinas rodando herdr. Eu entrego uma tarefa como “corrige esse teste flakey neste repo”, e ele escolhe uma máquina, abre um agente nela, opcionalmente em uma worktree nova, envia o prompt e acompanha até o agente parar ou ficar bloqueado.

Um job é a mesma ideia, mas recorrente. A cada hora, ou em um cron, o Pastor pergunta a um conector por trabalho e cria tarefas para os itens que ainda não viu. Hoje o conector embutido é o clock, o suficiente para jobs periódicos de manutenção. GitHub, Slack e outras fontes de eventos são onde isso fica mais interessante depois.

A ferramenta ficou útil quando saiu do caminho feliz. Todas as versões depois da 0.1.0 foram criadas usando o próprio Pastor e os Raspberry Pi 5 que eu tinha parados. Foi aí que vieram quase todas as lições.

• Saber quando um agente terminou de verdade é difícil. Um agente parado pode ter terminado, estar esperando por mim, ou estar travado. O Pastor precisa diferenciar isso sem ler a tela do agente.
• Trabalho e máquinas pessoais não podem se misturar. Uma máquina tem acesso a contas de trabalho, e uma tarefa pessoal cair nela não é aceitável. É por isso que rebanhos e tags importam.
• Corridas aparecem em todo lugar. Dois comandos mexem na mesma configuração, um agendador começa enquanto outro ainda roda, ou uma tarefa fica na fila sem nenhuma máquina capaz de pegá-la.
• Máquinas divergem. Um binário antigo pode ignorar silenciosamente configurações novas se a frota não expõe versões e protocolos.
• Agentes andam mais rápido do que eu consigo revisar. Uma vez eu fiz merge de um pull request com CI vermelho. Desde então, nada feito por agente entra sem CI verde e revisão limpa.
• O repositório é público. Nada das minhas máquinas, caminhos, usuários ou endereços pode vazar para código escrito por agente.

O Pastor mudou meu papel no loop. Eu escrevo um plano curto. O Pastor entrega para um agente. O Copilot revisa o pull request. Outro agente pode corrigir o que a revisão encontrou. Meu tempo sai da digitação e vai para a decisão.

Essa é a parte que mais me interessa. Não substituir o engenheiro, mas mudar onde o engenheiro gasta atenção.

Hoje o Pastor consegue:

• gerenciar um rebanho de máquinas locais e via SSH
• mostrar limites, tags, versões do herdr e ocupação das máquinas
• rodar tarefas avulsas em um repo ou em uma worktree nova
• colocar tarefas por tag ou fixá-las em uma máquina
• passar argumentos para o agente, então uma tarefa pode escolher modelo ou comportamento do harness
• rodar jobs agendados com every ou cron
• guardar estado de jobs, itens já vistos e histórico de tarefas em SQLite
• ler, anexar e enviar entrada para um agente pelo shell
• abrir a interface completa do herdr para uma máquina da frota
• escrever um log de eventos para mudanças em tarefas, jobs e máquinas
• instalar a si mesmo e o herdr como serviços de usuário no systemd

As próximas coisas que eu quero são plugins de conectores, hooks de eventos, uma identidade de máquina melhor controlada pelo herdr, mover tarefas entre máquinas e um job de testes que mantenha os checks do próprio Pastor rodando na frota.

O código e o manual estão em cacarico/pastor.