O gargalo não é o modelo, é atenção humana gerenciando sessões

Existe um padrão que aparece quando você começa a usar agentes de código de forma intensiva: você começa com uma sessão, fica confortável, abre uma segunda, depois uma terceira. Cada sessão numa worktree isolada, cada uma trabalhando em uma feature diferente. Em teoria, você está multiplicando sua capacidade por três.

Na prática, o que acontece é que você passa a maior parte do tempo alternando contexto entre sessões, perdendo o fio de onde cada uma parou, mandando instrução errada para o agente errado. O gargalo não é mais o modelo. É a sua própria atenção.

O que a gestão de software evoluiu para entender

Líderes de engenharia que gerenciam times de dezenas de pessoas não acompanham o progresso revisando cada PR individualmente. Eles trabalham com outcomes: tickets, milestones, issues. O estado do trabalho vive no tracker, não na cabeça do líder.

A proposta do Project Symphony, o repo que a OpenAI lançou recentemente, parte dessa observação. Em vez de interagir com sessões de agente, você interage com tickets. O agente trabalha no nível do ticket, reporta de volta através do próprio ticket, e você fica no loop sem precisar monitorar sessões individuais.

O tracker de tickets vira a máquina de estado do sistema.

Como funciona na prática

O sistema é simples no design. Um processo em background verifica o board do Linear a cada 30 segundos. Se encontra ticket em "to do", configura uma worktree isolada e inicia um agente nesse workspace. Quando o agente termina, atualiza o status do ticket para revisão humana. Quando o humano aprova, o agente cria o PR.

O que define o comportamento do agente é um arquivo workflow.md que vive dentro do repositório, versionado com o código. A parte superior é YAML que configura o scheduler: qual projeto, com que frequência, quantos agentes em paralelo. A parte inferior é markdown: o SOP para o agente, como planejar a tarefa, como verificar que funcionou, quando pedir revisão humana.

Essa decisão de design importa. O comportamento do agente não está num painel de admin ou num arquivo de configuração separado. Está no repositório, acessível via pull request como qualquer outra mudança. Quando você quer mudar como o agente aborda um tipo de tarefa, você abre um PR no workflow.md.

O que torna o loop fechável de forma autônoma

O que diferencia esse tipo de sistema de um batch job glorificado é a capacidade do agente de verificar o próprio trabalho. O Symphony integra com Playwright para que o agente possa gravar a sessão do browser, verificar que a feature funciona visualmente, e incluir o vídeo como evidência no ticket.

Isso resolve um problema real: como você confia que o agente fez o que disse que fez, sem ter que repetir o trabalho de verificação que você delegou? Com evidência em vídeo no ticket, a revisão humana vira uma confirmação, não uma auditoria.

No GITFLOW, a plataforma que construímos para automatizar processos de BPM na Guaraves, o princípio é parecido. Cada etapa do processo tem log estruturado. Quando a IA executa uma etapa, o resultado fica registrado com o contexto que levou àquela decisão. O humano responsável não precisa acompanhar a execução: ele verifica o resultado quando chega para revisão. Isso foi o que permitiu que times diferentes conseguissem operar os processos sem precisar entender a implementação subjacente.

A diferença é de responsabilidade: o agente é responsável por executar e provar que executou corretamente. O humano é responsável por aprovar ou rejeitar o resultado.

O que precisa estar pronto para isso funcionar

O workflow de ticket funciona quando o ambiente do agente está configurado para execução autônoma. O agente precisa conseguir inicializar o sistema, rodar testes, verificar que as mudanças não quebraram nada, tudo sem precisar de ajuda.

Isso não é uma configuração trivial. Depende de ter scripts de bootstrap claros, documentação estruturada sobre convenções do codebase, e ferramentas de verificação que o agente possa invocar de forma autônoma. Sem isso, o agente passa tempo significativo descobrindo como fazer as coisas que deveriam ser procedimento padrão.

O Symphony como arquitetura é uma observação sobre onde o valor humano está. Não está em monitorar sessões. Está em definir o que conta como "pronto" e em validar que os resultados chegaram lá.

O que você gerenciaria de forma diferente se pudesseelevar um nível e trabalhar com outcomes em vez de sessões?