# Convergência evolutiva: o ambiente dos agentes seleciona as mesmas peças

> Equipes que não se conhecem estão chegando às mesmas peças na engenharia de agentes: registro rastreável de cada passo, verificação antes da entrega, aprovação humana nos pontos de risco e correção do ambiente em vez do agente. Isso não é cópia. É o ambiente selecionando a mesma função.

- Author: Elzo Brito
- Language: pt-BR
- Published: 2026-10-04
- Canonical URL: https://elzobrito.com/blog/convergencia-evolutiva-na-engenharia-de-agentes/
- Translation: https://elzobrito.com/en/blog/convergent-evolution-in-agent-engineering/

---
Hoje de manhã li duas coisas que não têm nenhuma relação entre si e que, lidas juntas, descrevem quase a mesma arquitetura. A primeira foi a [release v1.3.1 das skills de Matt Pocock](https://github.com/mattpocock/skills/releases/tag/v1.3.1), publicada no GitHub neste domingo. A segunda foi um documento em formato de paper, «Prompting Grok Bot: SpaceXAI Blueprint Applied to Loops for an Agent Team», sobre como desenhar uma equipe de bots. Uma é um conjunto de skills para coding agents; a outra é um guia de prompts e rotinas. A release não menciona o ESAA, e não há motivo para que mencionasse. Mesmo assim, as peças que aparecem nelas são as que eu tentei formalizar em fevereiro no paper [ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering](https://arxiv.org/abs/2602.23193) (implementação em [ESAA-Core](https://github.com/elzobrito/ESAA-Core)): um registro rastreável de cada passo, verificação antes da entrega, aprovação humana nos pontos de risco e a decisão de corrigir o ambiente em vez de corrigir o agente. Quando eu vejo isso, a pergunta que me interessa não é quem chegou primeiro. É o que o ambiente está fazendo para que todo mundo chegue ao mesmo lugar.

## O que a biologia chama de convergência

Na biologia, convergência evolutiva é o nome para linhagens independentes que desenvolvem a mesma solução porque enfrentam a mesma pressão. O olho em câmera do polvo e o dos vertebrados são o exemplo clássico: a função é quase idêntica e a origem é separada. O que a convergência informa não é parentesco, é ambiente. Se dois grupos sem ancestral comum desenvolvem a mesma peça, a peça diz mais sobre o problema que ambos enfrentam do que sobre qualquer um dos dois. Uso a metáfora porque ela me obriga a uma disciplina que a discussão sobre agentes costuma esquecer: semelhança de função não é evidência de cópia, e quem a lê como cópia perde exatamente a informação útil.

A pressão, no caso dos agentes, me parece fácil de nomear. Gerar código ficou barato. O que continua caro é saber o que aconteceu, saber se funciona, saber quem decidiu e garantir que o mesmo erro não volte. Qualquer equipe que roda agentes em volume encontra esses quatro custos, e os encontra mais ou menos nessa ordem. As quatro peças são as respostas a eles.

## A mesma peça em quatro lugares

Começo pelo registro. No `implement-spec` de Pocock, os tickets são lidos como um grafo de tarefas; subagentes implementadores trabalham cada um em sua própria worktree sobre a fronteira de tarefas prontas, e tudo aterrissa num único integration branch. Cada implementador confirma que sua worktree parte desse branch e incorpora a ponta da integração antes de reportar a tarefa como feita, de modo que cada merge é um fast-forward. O mecanismo é o git, não um event store, mas a função é a que me levou ao log append-only do ESAA: cada passo precisa deixar um rastro que outro agente, ou outra pessoa, consiga reconstruir sem depender da memória de quem executou. O documento sobre equipes de bots chega à mesma função por outro caminho, quando pede um único resultado por bot e exige evidência e handoff explícitos.

A verificação vem logo depois. Na mesma release, cada implementador constrói seu ticket com `tdd`, o fluxo fecha com `code-review`, e a skill `pr` exige que o corpo do pull request traga evidência de antes e depois de que a mudança funciona. O documento atribui a Lauren Tan (@poteto) uma prática que coloca a verificação em primeiro lugar e empurra os passos determinísticos para scripts. No ESAA, a mesma função aparece como o ciclo `claim` e `complete` com verificações declaradas, revisão por um papel de QA e a regra de que uma tarefa concluída não volta atrás. São três formas de dizer que «pronto» não é algo que o agente declara, é algo que o sistema confere.

A terceira peça é a aprovação humana no ponto de risco. A skill `pr` pede uma avaliação explícita do perigo do merge: se a mudança é uma porta de mão única ou de mão dupla, e qual é o seu blast radius. Repare que ela não pede ao humano que leia tudo. Ela prepara o humano para decidir no ponto em que a decisão pesa. O documento sobre equipes de bots chama isso de limite de aprovação e de ponto de parada explícito. O paper do ESAA trata o mesmo problema como contenção de blast radius por contratos de fronteira por tipo de tarefa. Não tomo a coincidência do termo como sinal de nada; «blast radius» é vocabulário antigo de operações. O que me interessa é que três desenhos independentes decidiram que a atenção humana é o recurso escasso e que ela deve ser gasta onde o erro é irreversível.

A quarta peça é a que mais me chamou atenção, porque é a menos óbvia. A skill `retro` olha para uma sessão de programação e sugere mudanças no ambiente do agente, não no código: ponteiros de navegação, checagens automáticas, padrões de código, arquivos de orientação, economia de ferramentas, acesso a informação. E classifica cada achado antes de agir. Uma violação mecânica vira uma checagem determinística (regra de linter, hook de pre-commit ou job de CI), e o `CODING_STANDARDS.md` fica reservado para o que é de fato julgamento. A release chega a dizer que um repositório sem nenhum guardrail é, por si só, um achado. O documento sobre equipes de bots fala em corrigir o ambiente e não o agente, e o paper do ESAA abre com a mesma aposta: o problema central não é melhorar o prompt, é reestruturar o sistema em torno de invariantes verificáveis.

## Por que isso não é cópia

Existe um teste simples para separar convergência de imitação. Cópia transmite forma; convergência transmite função. Se alguém tivesse copiado o ESAA, eu esperaria encontrar a forma: um log append-only de eventos, um envelope JSON validado, uma projeção com hash, um orquestrador como único escritor. Não encontro nada disso nas skills de Pocock, que trabalham com git, worktrees e markdown, e o documento sobre bots opera em outra camada, a de papéis, prompts e rotinas. Os mecanismos são outros, e é justamente por isso que a semelhança de função tem valor como evidência. Se o mecanismo fosse o mesmo, eu não saberia distinguir uma ideia que se sustenta de uma ideia que se espalhou.

E preciso ser honesto sobre a minha própria posição nessa árvore. O ESAA também é convergência. Event sourcing é um padrão descrito por Martin Fowler em 2005, CQRS vem da mesma tradição, revisão de código e CI são prática antiga de engenharia de software. O que eu fiz em fevereiro foi montar essas peças para o caso específico de agentes baseados em LLM e escrevê-las como protocolo. Não reivindico prioridade sobre nenhuma delas, e não acho que alguém tenha copiado o ESAA. O que eu posso dizer é mais estreito e, para mim, mais útil: as mesmas funções continuam aparecendo, em lugares que não conversam entre si, o que sugere que elas não são preferência de estilo. São respostas ao ambiente.

Já tratei uma versão parecida dessa observação em [O prompt descreve o ciclo; o ESAA o institui](/blog/o-prompt-descreve-o-ciclo-o-esaa-o-institui/), a partir das instruções de um agente comercial. Ali o contraste era entre um ciclo narrado em linguagem natural e um ciclo gravado fora do modelo. O que muda agora é a direção do movimento. A skill `retro` não se contenta em narrar a regra: ela pede que tudo o que é mecânico saia do texto e vire checagem determinística. É o mesmo gesto que motivou o ESAA, aplicado por outra equipe, numa escala menor, com outras ferramentas.

## Onde cada peça deve morar

A consequência prática da convergência não é «use o ESAA». É uma pergunta mais útil para quem opera agentes: em que camada cada uma das quatro funções está instalada? A mesma função pode morar num prompt, numa skill, num hook, num job de CI ou num orquestrador, e o que ela garante muda com a camada. Uma regra escrita num markdown depende de o modelo a seguir. Uma regra num hook de pre-commit depende só de o hook rodar. Um evento gravado por um orquestrador que é o único escritor depende só do orquestrador. A diferença não é estética; é a diferença entre uma obrigação e um invariante.

O critério da `retro` me parece o certo para decidir isso, e eu o aplicaria além dos padrões de código. O que é mecânico deve sair da prosa: registrar o passo, conferir que a verificação rodou, impedir que uma tarefa feita seja reaberta. O que é julgamento deve ficar com uma pessoa, mas o momento de chamá-la pode ser mecânico, disparado pelo tipo de mudança ou pelo tamanho do blast radius. Corrigir o ambiente, nesse sentido, é ir movendo cada função da camada em que ela é pedida para a camada em que ela é garantida. O ESAA-Security ([paper](https://arxiv.org/abs/2603.06365), [repositório](https://github.com/elzobrito/ESAA-Security)) é um exemplo do mesmo movimento num domínio específico: em vez de pedir a um modelo que «ache vulnerabilidades» em prosa livre, a auditoria vira um pipeline em que cada achado só passa a existir depois de validado e registrado, como argumentei em [Pare de pedir para a IA «achar bugs» no seu projeto](/blog/pare-de-pedir-para-a-ia-achar-bugs-no-seu-projeto-conheca-o-esaa-security/).

O documento que li hoje traz números e datas que eu não consegui verificar, e por isso não os uso aqui. Ele entra neste texto como sinal, não como prova. A release de Pocock, essa sim, está publicada e diz exatamente o que descrevi. Dois sinais não fazem uma lei. Mas quando linhagens que não se conhecem começam a desenvolver o mesmo órgão, eu prefiro estudar a pressão a discutir a autoria, e a pressão, aqui, é clara: num sistema em que gerar ficou barato, sobrevive o que consegue provar o que fez.