Capítulo 11 — Coordenação: um agente, vários agentes ou pipeline?

Coordenação não é sinônimo de autonomia

O capítulo anterior definiu o envelope de ação de um agente. Aqui o problema muda: como várias unidades de execução trabalham sobre um sistema compartilhado sem transformar paralelismo em conflito?

Adicionar agentes não amplia automaticamente capability. Muitas vezes apenas multiplica:

• contratos;
• handoffs;
• sincronização;
• ownership;
• integração;
• Evidence;
• resolução de conflito.

Antes de perguntar “quantos agentes?”, precisamos perguntar qual dependência realmente exige distribuição e qual custo essa fronteira adiciona.

Por isso, este capítulo trata multiagente como arquitetura de coordenação, não como nível superior de autonomia.

Single-agent é o baseline

O método deste livro começa com um baseline simples:

um agente, um contexto, uma unidade de trabalho.

Se a tarefa cabe nesse envelope e não existe ganho claro de paralelismo, distribuição adiciona complexidade sem necessidade.

McEntire argumenta que tarefas fortemente acopladas podem ser mais adequadas a execução por um único agente em um único contexto, enquanto tarefas fracamente acopladas podem ser distribuídas com interfaces bem definidas e coordenação por ambiente compartilhado. ¹ Isso produz uma regra:

não distribua antes de medir o custo da fronteira.

Um sistema multiagente deve superar o baseline single-agent em algum critério definido:

• tempo;
• throughput;
• especialização;
• isolamento;
• custo;
• disponibilidade de contexto;
• risco;
• qualidade de verificação.

Sem critério, “multi-agent” vira estética arquitetural.

Coordenação depende de acoplamento

Duas tarefas podem parecer independentes porque estão em arquivos diferentes e ainda assim depender uma da outra semanticamente.

Exemplos de alto acoplamento:

• schema e migration;
• produtor e consumidor de evento;
• API e cliente;
• autenticação e autorização;
• mudança de domínio que atravessa módulos.

Exemplos de menor acoplamento:

• geração de documentação;
• testes independentes;
• revisão de segurança;
• análise de performance;
• componentes separados por contrato estável.

O acoplamento real determina a largura do canal de coordenação necessário.

Três formas básicas

Neste livro, usamos três formas operacionais.

Single-agent

Uma única unidade mantém o máximo de continuidade de contexto.

Pipeline sequencial

A saída de uma etapa vira entrada explícita da próxima.

Trabalho paralelo

Múltiplas unidades atuam ao mesmo tempo e se integram por contratos e ambiente compartilhado.

Essas categorias são método deste livro.

Pipeline sequencial

Pipeline funciona bem quando existe dependência clara.

Exemplo:

Spec
  ↓
Implementation
  ↓
Test
  ↓
Review
  ↓
Delivery

A vantagem é reduzir ambiguidade de ordem.

O risco é transformar cada handoff em compressão.

Se a segunda etapa recebe apenas um resumo pobre da primeira, perde razões, restrições e contexto de decisão.

Por isso, handoff não deve ser apenas mensagem.

Ele precisa carregar:

• resultado;
• estado;
• decisões;
• riscos;
• evidência;
• próximos contratos;
• unresolved questions.

Trabalho paralelo

Paralelismo faz sentido quando unidades podem avançar sem escrever no mesmo estado a todo momento.

Exemplo:

• agente A implementa backend;
• agente B prepara testes de integração a partir do contrato;
• agente C revisa ameaça;
• agente D atualiza documentação.

O contrato é mais importante que a conversa.

Se cada agente precisa perguntar continuamente aos outros o que está acontecendo, o trabalho não está realmente desacoplado.

Coordenação por ambiente compartilhado

McEntire descreve coordenação estigmérgica como coordenação por sinais deixados no ambiente, em vez de diálogo par-a-par. Repositório, task board e CI podem funcionar como meios compartilhados onde cada participante observa mudanças e responde a elas. ²

Em software, esses sinais podem ser:

• commit;
• branch;
• issue state;
• PR;
• test failure;
• build artifact;
• schema;
• contract;
• status file;
• deployment state. O benefício é importante: a informação de coordenação fica incorporada ao trabalho.

Não precisamos de uma conversa adicional dizendo:

“o build quebrou.”

O CI já deixou o sinal.

Stigmergy precisa de constraints

Ambiente compartilhado sem limites pode produzir caos.

Se todos podem:

• alterar qualquer arquivo;
• redefinir tipos;
• mudar interfaces;
• sobrescrever estado;
• usar padrões diferentes;

o fato de compartilharem o repositório não cria coerência.

Coordenação ambiental funciona melhor quando o ambiente também impõe contratos:

• linters;
• schemas;
• testes;
• branch protections;
• type checks;
• ownership;
• gates.

No método deste livro:

shared environment + constraints > shared environment sozinho.

Shared artifacts

Um shared artifact é um ponto de coordenação que todos podem observar.

Exemplos:

• SPEC.md;
• interface schema;
• task board;
• ADR;
• branch;
• test suite;
• Change Episode;
• Merge-Readiness Pack;
• shared state manifest.

O artefato precisa ter:

• owner;
• lifecycle;
• atualização atômica quando possível;
• forma de detectar conflito;
• significado claro.

Handoff contract

O artefato operacional deste capítulo é o Coordination Decision Record, mas todo trabalho distribuído precisa de um Handoff Contract.

Estrutura mínima:

• producer;

• consumer;

• input;

• output;

• invariant;

• evidência;

• completion signal;

• escalation path. Exemplo:

  Producer: agente de API Consumer: agente de frontend Output: openapi.yaml Invariant: backward-compatible fields Evidence: contract tests Completion signal: CI green Escalation: domain owner

Isso reduz a necessidade de explicação informal.

Shared memory

Shared memory pode ajudar quando múltiplos agentes precisam de estado comum.

Mas memória compartilhada introduz problemas:

• concorrência;
• obsolescência;
• autoridade;
• contaminação;
• conflito;
• excesso de contexto.

Por isso, nem todo estado compartilhado deve virar “memória global”.

No método deste livro, priorizamos:

1. artefato versionado;
2. estado estruturado;
3. memória recuperável;
4. chat compartilhado apenas quando necessário.

Blackboard

Um blackboard é um espaço onde participantes publicam e consultam estado comum.

Pode ser implementado por:

• arquivo estruturado;
• banco;
• queue;
• issue board;
• event log;
• task graph.

A implementação importa menos que as regras.

Precisamos saber:

• quem escreve;
• quem lê;
• qual campo é canônico;
• como detectar versão;
• como resolver conflito.

Command plane e execution plane

Hassan et al. propõem ACE e AEE como workbenches distintos: um ambiente de comando humano para orquestração e revisão e um ambiente de execução para agentes, conectados por artefatos versionados como CRPs e MRPs. ³ No nosso método, isso funciona como prior art para separar:

Command plane

• intenção;
• distribuição;
• política;
• approvals;
• risk view;
• evidência revisão;
• escalation.

Execution plane

• task execution;
• ferramentas;
• sandbox;
• state;
• tests;
• artifacts.

Essa separação é método deste livro inspirado em prior art, não uma cópia de ACE/AEE.

Human escalation

Multiagente não elimina humano.

Ele muda o ponto de intervenção.

Escalonamento é necessário quando aparece:

• ambiguidade de requisito;
• conflito de contrato;
• impacto irreversível;
• risco de segurança;
• decisão de domínio;
• trade-off não codificado;
• falha repetida.

A escalada deve incluir contexto suficiente para decisão.

Não deve enviar “deu erro”.

Deve enviar:

• decisão necessária;
• alternativas;
• evidência;
• risco;
• recomendação opcional;
• efeito de não decidir.

Coordination Decision Record

Antes de adotar múltiplos agentes, registre:

Problem

Qual limite do baseline single-agent estamos tentando superar?

Coupling

Quais unidades são independentes e quais compartilham estado?

Pattern

Single-agent, pipeline, parallel ou híbrido?

Shared environment

Qual artefato ou estado coordena o trabalho?

Contracts

Quais handoffs são explícitos?

Conflict model

Como colisões são detectadas e resolvidas?

Escalation

Quando a decisão volta para humano?

Evidence

Como saberemos se o desenho foi melhor?

Exit condition

Quando voltar para single-agent ou simplificar?

Métrica antes da arquitetura

Um experimento simples pode comparar:

Configuração A

single-agent.

Configuração B

pipeline.

Configuração C

parallel multi-agent.

Medir:

• lead time;
• número de handoffs;
• rework;
• merge conflicts;
• testes falhos;
• tokens/custo;
• intervenção humana;
• defects;
• tempo de integração.

O importante não é provar que uma configuração é “melhor” universalmente.

É descobrir em qual tipo de tarefa cada mecanismo ajuda.

Coordination overhead

Toda coordenação tem custo.

Podemos modelar o custo operacionalmente como:

trabalho útil
+
comunicação
+
handoff
+
sincronização
+
integração
+
conflito
+
supervisão

Se o ganho de paralelismo for menor que esse custo, distribuir piora o sistema.

Falha típica: parallelize by file

Dividir por arquivo parece fácil:

• agente 1 → file A;
• agente 2 → file B;
• agente 3 → file C.

Mas arquivos não são necessariamente boundaries de informação. Dois arquivos podem compartilhar:

• invariant;
• schema;
• lifecycle;
• data model;
• naming;
• security policy.

A divisão correta segue contrato e acoplamento, não extensão ou diretório.

Falha típica: agente coordenador que vira gargalo

Um orchestrator central pode acabar:

• lendo tudo;
• resumindo tudo;
• aprovando tudo;
• roteando tudo;
• integrando tudo.

Nesse ponto, o sistema continua single-agent na prática, apenas com overhead adicional.

O coordenador virou gargalo de contexto.

Uma arquitetura saudável desloca sinais rotineiros para:

• CI;
• task state;
• contracts;
• schemas;
• ownership;
• automatic gates.

O coordenador fica para decisões que realmente exigem síntese.

Falha típica: shared memory como despejo

Quando todos os agentes escrevem tudo em um espaço comum, o resultado pode ser:

• ruído;
• contradição;
• informações expiradas;
• perda de provenance;
• custo de leitura crescente.

Shared memory sem lifecycle vira contexto debt.

Falha típica: handoff em linguagem natural sem artifact

“Terminei backend. Está tudo certo.”

Essa mensagem não é contrato.

Um handoff verificável pode incluir:

• commit;
• API schema;
• tests;
• known limitations;
• migration state;
• evidência links.

Handoff precisa transferir capacidade de continuar, não apenas sensação de conclusão.

Concorrência de escrita

Multiagente cria risco de race condition editorial e técnica.

Estratégias:

• worktrees separados;
• branches por unidade;
• ownership de paths;
• lock lógico;
• event sourcing;
• append-only logs;
• merge queues;
• shared contracts read-only.

A melhor escolha depende da natureza do estado.

Evite múltiplos writers sobre o mesmo artefato sem protocolo.

Single-writer principle

Quando existe um estado particularmente sensível, pode ser melhor ter um único writer e vários readers/producers.

Exemplos:

• schema canônico;
• release manifest;
• migration sequence;
• production config.

Outros agentes propõem.

Um agente ou gate consolida.

Isso reduz conflito.

Pipeline não precisa significar agentes diferentes

Podemos ter:

agent A → stage 1
agent A → stage 2
agent A → stage 3

com gates entre estágios.

Pipeline é forma de processo.

Multiagente é forma de distribuição.

Não são sinônimos.

Essa distinção evita arquitetar múltiplos agentes quando o ganho vem apenas de estruturar etapas.

Especialização

Um agente especializado pode valer quando possui:

• contexto diferente;
• toolset diferente;
• policy diferente;
• modelo diferente;
• objetivo diferente.

Exemplo:

• revisor de segurança read-only;
• planejador de migração sem prod write;
• agente de testes com ambiente isolado.

Especialização útil cria boundaries de responsabilidade.

Especialização cosmética apenas troca o nome do prompt.

Multi-agent como sistema distribuído

Quando vários agentes:

• operam em paralelo;
• compartilham estado;
• falham independentemente;
• trabalham com versões diferentes;
• produzem efeitos concorrentes;

começamos a enfrentar problemas semelhantes a sistemas distribuídos.

Precisamos considerar:

• ordering;
• idempotency;
• consistency;
• retries;
• stale reads;
• duplicate work;
• partial failure.

Isso não significa aplicar teoria distribuída inteira a qualquer workflow.

Significa reconhecer que paralelismo cria estados que precisam de protocolo.

Coordenação também precisa de rollback

Uma unidade pode produzir uma mudança correta localmente e errada globalmente.

Rollback deve considerar composição.

Precisamos saber:

• qual unidade gerou o artefato;
• qual commit incorporou;
• quais dependências consumiram;
• qual versão do contrato estava ativa;
• como reverter sem quebrar outras partes.

Version control ajuda, mas não resolve efeitos externos.

Da coordenação à compreensão

Coordenação pressupõe que boundaries, contratos e estado compartilhado sejam minimamente compreendidos.

Sistemas legados frequentemente quebram essa premissa: testes são incompletos, ownership é difuso, documentação está desatualizada e comportamento real diverge da arquitetura imaginada.

Nessa situação, distribuir agentes cedo não aumenta capacidade; pode multiplicar hipóteses incorretas.

O próximo capítulo muda o modo de trabalho: antes de transformar, investigar; antes de delegar amplamente, construir evidência sobre o comportamento existente.

Fronteira de confiança

Cada handoff é uma trust boundary. O consumidor não deve assumir que o produtor preservou todas as invariantes; contratos, schemas, testes e provenance precisam acompanhar artefatos compartilhados.

Evidência exigida

Uma arquitetura multiagente deve registrar evidência de que a distribuição trouxe benefício. O Coordination Decision Record deve declarar baseline, métrica, coupling assumptions, handoffs, conflito observado, rework e resultado de integração.

Rollback e recuperação

Trabalho paralelo precisa ser reversível por unidade quando possível. Branches, worktrees, manifests e commits devem permitir localizar contribuição e dependências. Shared state externo exige recovery específico e não deve depender apenas de revert Git.

Proveniência das fontes

Rastreabilidade deste capítulo:

• CLM-041 — McEntire, coordenação estigmérgica por sinais em ambiente compartilhado;
• CLM-042 — McEntire, single-agent para alto acoplamento e distribuição por contratos/ambiente quando o acoplamento é menor;
• CLM-043 — Hassan et al., ACE/AEE e artefatos versionados para orquestração, consulta e revisão.

Single-agent baseline, Coordination Decision Record, Handoff Contract, command plane/execution plane, métricas comparativas e padrões de shared-state apresentados aqui são método deste livro.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Recursos relacionados:

• Coordination Decision Record;
• Handoff Contract;
• shared-state manifest;
• multi-agent experiment template;
• coordination-cost worksheet;
• futura visualização de agent graph;
• futura comparação single-agent vs pipeline vs parallel em Change Episodes.

---

Footnotes

1. Jeremy McEntire, Beyond Code (2026), Chapter 9: Coordination Without Dialogue, p. 89. Rastreabilidade interna: CLM-042. ↩

2. Jeremy McEntire, Beyond Code (2026), Chapter 9: Coordination Without Dialogue, pp. 84–85. Rastreabilidade interna: CLM-041. ↩

3. Hassan et al., Agentic Software Engineering: Foundational Pillars and a Research Roadmap, 2 From Agency to Autonomy: A Hierarchical Framework for AI in SE, p. 4. Rastreabilidade interna: CLM-043. ↩