Capítulo 7 — Padrões Avançados Colaborativos e Dinâmicos

Sétima postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Quando a topologia não pode ser desenhada em tempo de design — quando o próximo passo certo depende do que o passo anterior achou — os padrões do Capítulo 6 deixam de ser suficientes.

Por que este capítulo existe

Os padrões do Capítulo 6 compartilham uma característica arquitetural que vira passivo para tarefas mais difíceis: a topologia é fixa em tempo de design. O engenheiro desenha o pipeline, nomeia os estágios, decide quem alimenta quem, e o runtime nunca reconsidera. Para tarefas cuja forma é conhecida de antemão, isto é força. Para tarefas cuja forma é genuinamente emergente — onde o especialista certo depende do que o usuário pediu, onde o próprio plano tem que ser construído conforme o trabalho avança — a topologia fixa vira gaiola.

Este capítulo percorre os padrões dinâmicos: roundtables onde agentes iteram rumo a consenso, routers que delegam a especialistas escolhidos em runtime, e orquestração magentic que constrói planos enquanto a tarefa se desenrola. Cada um compra capacidade que os padrões mais simples não conseguem oferecer. Cada um introduz modos de falha — não-terminação, mis-routing, planejamento desbocado — que os padrões mais simples evitam.

7.1 Group chat e roundtable: maker-checker, consenso multi-participante

Orquestração de group chat coloca vários agentes num contexto conversacional compartilhado e os deixa falar por vez. A forma mais simples é o loop maker-checker de dois agentes: o maker produz um candidato, o checker o avalia contra uma rubrica, o maker revisa em cima do feedback, e o loop termina por aprovação ou orçamento de turnos. Modelos de linguagem são mensuravelmente melhores em avaliação do que em produção quando ambos são enquadrados corretamente — um modelo pedido para escrever e auto-avaliar na mesma chamada tende a defender sua primeira tentativa; o mesmo modelo recebendo a mesma saída num contexto novo com uma rubrica clara é marcadamente mais crítico.

Os modos de falha honestos são três. Conluio — quando maker e checker compartilham modelo e prompt, o checker aprova qualquer coisa. A defesa é diferenciação real de papéis, idealmente modelos diferentes. Não-terminação — um checker estrito rejeita todo candidato; o orquestrador precisa aceitar o melhor visto ou escalar. Deriva do checker — num contexto de roundtable compartilhado, o checker começa a aprovar coisas que teria rejeitado antes porque as justificativas do maker se acumulam. Uma descoberta de campo do final de 2025 é contraintuitiva: os sistemas maker-checker mais confiáveis impedem o checker de ver como o candidato foi produzido. Checkers stateless — recebendo só o candidato e a rubrica — aumentam rejeições corretas em 30–50%. Contexto compartilhado é ferramenta, não default.

Roundtables multi-participante estendem o padrão com vários especialistas e um moderador. O custo cresce rápido: gasto de token cresce com o transcript compartilhado, latência cresce com turnos, e agentes ficando presos em tangentes são observados em produção. As disciplinas que fazem funcionar — tokens limitados por turno, saídas de turno estruturadas, rubricas explícitas de terminação — são a diferença entre uma reunião produtiva e uma reunião que deveria ter sido um email.

7.2 Handoff e roteamento: delegação dinâmica

Orquestração handoff toma abordagem diferente: um agente por vez cuida da conversa, e o agente ativo pode entregar quando seu trabalho termina ou quando a requisição muda para outra especialidade. O router — geralmente um LLM ele próprio — lê estado da conversa e emite decisão de roteamento: "fique com o atual" ou "passe ao especialista X com este resumo de contexto." O resumo é o contrato entre a camada de roteamento e o especialista.

O problema de engenharia mais duro é reconhecer quando handoff é necessário. Mis-routing é a falha mais comum: o router manda uma pergunta de billing para suporte técnico, suporte faz o melhor possível, e o usuário recebe uma resposta confusa que não endereça nenhuma das suas preocupações. As defesas se empilham: um limiar de confiança abaixo do qual o router deferе para um humano, ações explícitas de "isto não é minha área" que especialistas podem tomar, e log de toda decisão de roteamento para revisão.

Dois outros modos de falha moldam o design em produção. Loops de handoff — especialista A manda pro B, B manda de volta pro A — defendidos detectando handoffs repetidos e forçando outra resolução. Perda de contexto — cada resumo de handoff é perda, e o próximo especialista pode pedir informação que o usuário já forneceu — defendido guardando a conversa completa fora do contexto de qualquer especialista, com o resumo como payload primário e o histórico completo disponível sob solicitação. Conforme contagens de especialistas crescem, routers planos viram frágeis; o padrão que emergiu em 2025 é roteamento hierárquico — um router grosseiro escolhe uma categoria, um router específico de categoria escolhe o especialista. Dois níveis é o ponto doce em produção.

7.3 Orquestração magentic: planos construídos enquanto o trabalho se desenrola

Para tarefas cuja decomposição não é conhecida no começo — investigue por que o banco está lento, depure um sistema desconhecido, pesquise um tópico complexo — nenhum dos padrões anteriores basta. Orquestração magentic, batizada em homenagem ao framework Magentic-One da Microsoft, é a família de padrões onde um agente gerente mantém um livro razão de tarefas e o atualiza conforme o trabalho avança. O livro razão tem espaços explícitos: a meta original, o entendimento atual (que pode refinar), subtarefas abertas com prioridades, subtarefas concluídas com resultados, descobertas que podem exigir revisão do plano, e uma condição de parada. O gerente lê o livro razão a cada passo, decide o próximo despacho, e integra resultados de volta.

A força é abertura genuína. "Investigue por que o banco está lento" não pode ser decomposto antecipadamente — a próxima subtarefa depende de se o gargalo for rede, plano de query, ou linha quente. Nenhum pipeline fixo daria conta; nenhuma topologia estática de handoff rotearia certo sem saber de antemão quais seriam as especialidades relevantes.

O custo é o mais severo deste capítulo em toda dimensão: latência, tokens, esforço de engenharia, risco operacional. Gasto de token cresce superlinearmente porque o livro razão é lido a cada turno. Os modos de falha catalogados são afiados. Planejamento desbocado — o gerente abre subtarefas mais rápido do que fecha, livro razão cresce sem limite. Deriva de meta — conforme o gerente aprende, ele reformula a meta para longe da intenção do usuário. Churn de plano — toda nova descoberta dispara revisão de plano, nenhum compromisso é sustentado tempo suficiente para fazer progresso. O padrão que emergiu é o loop magentic limitado: orçamentos em subtarefas abertas, invocações totais de worker, e tempo de relógio, com escalada quando qualquer limite é atingido. Sistemas magentic em produção sem limites ocasionalmente queimam centenas de dólares em tokens em tarefas que o gerente não conseguia resolver dentro de orçamento prático.

7.4 Escolhendo entre os padrões

Três perguntas selecionam entre eles. A topologia é conhecida de antemão? Se sim, fique com os padrões estáticos do Capítulo 6. O trabalho se beneficia de iteração contra checagem externa? Se sim, um loop maker-checker é a adição certa — embutível dentro de qualquer outro padrão. Quão aberto é o planejamento? Se limites claros, handoff ou sequencial dá conta; se genuinamente emergente, magentic é o padrão necessário, aceito com seus custos.

Um caso de 2025 de uma firma de serviços financeiros é o aviso instrutivo: um workflow magentic de onboarding de cliente escolhido porque o time estava animado com a flexibilidade do framework foi substituído por um pipeline sequencial fixo. Custo por onboarding caiu de aproximadamente sete dólares para oitenta centavos; taxas de conclusão melhoraram. O padrão de recorrer à ferramenta mais geral quando uma mais específica bastaria não é novo em engenharia de software, e se manifesta acentuadamente em orquestração multi-agente porque a generalidade é paga em tokens.

O que o Capítulo 7 prepara

Os Capítulos 6 e 7 especificam como agentes se coordenam. Não especificam onde os agentes rodam, como o modelo de linguagem é co-localizado com as ferramentas, ou como se parece a topologia de deployment no nível de processos, máquinas e fronteiras de rede. Dois sistemas com padrões de orquestração idênticos podem ser deployados de modos dramaticamente diferentes — perfis de latência diferentes, estruturas de custo diferentes, posturas de segurança diferentes. O Capítulo 8 cobre essa dimensão.

Próximo — Capítulo 8: Layouts de Deployment. Três jeitos amplamente diferentes em que o MCP pode ser fisicamente deployado — modelo-com-servidor, modelo-no-cliente, híbrido — com os tradeoffs do mundo real em latência, custo, complexidade operacional, e os tipos de falha que cada um torna provável.