Agent Orchestration
Padrão em que um coordinator agent recebe um objetivo, quebra em tasks, dispara workers paralelos em worktres isolados e aguarda resultados — interrompendo o humano apenas quando uma decisão é necessária.
O Ciclo
Run → Task → Worker → worker_done → next task
- Run — namespace durável e inbox do coordenador.
- Task — item com spec, dependências e status; sobrevive a tentativas.
- Worker — um agente em um worktree, reportando ao terminar.
- Dispatch — cada worker lançado gera um ID de dispatch; conclusões carregam task ID e dispatch ID, impedindo que worker obsoleto marque trabalho novo.
Ask vs. Gate
| Mecanismo | Quem pausa | Escopo | Regra prática |
|---|---|---|---|
ask | worker pergunta para cima | trava um worker até resposta | ”preciso de 1 resposta pra seguir” |
gate | coordenador segura a task | bloqueia task e dependentes | ”ninguém avança até resolver” |
Resolvers de gate cascata para toda task dependente automaticamente.
Wait Sem Polling
O coordenador usa espera bloqueante (--wait --types worker_done,escalation,question): retorna no instante em que algo precisa de humano, antes não. Timeout longo (15–60 min) é normal; heartbeat a cada 15s no stderr mantém a conexão viva.
Implicações
- Elimina a “message bus humana”: sem copiar saída entre panes, sem
sleep 300para checar fim. - Paralelismo escala porque coordenação é explícita (tasks, dependências, inbox), não por acaso.
- Mobile companion transforma o celular em superfície de decisão: responder
ask/gatesem abrir terminal.
Open Questions
- Como o coordenador lida com falha de worker sem
worker_done? - Qual a política de retry para tasks com dependências falhas?
Relacionamentos
- orca-ade — implementação de referência do padrão
- git-worktrees-for-agents — isolamento que torna o paralelismo seguro
- ai-agent-teams — equipes de agentes peer-to-peer, sem coordenador central