Implementação Governada

Orquestração é a Nova Camada de Governança

TV
Thiago Victorino
9 min de leitura
Orquestração é a Nova Camada de Governança
Ouvir este artigo

Um único número esconde o argumento inteiro.

No clone do Slack construído de ponta a ponta pelo novo sistema Missions da Factory.ai — seis marcos, 16,5 horas de execução, 38.800 linhas de código, 52,5% de cobertura de testes — 34,4% da implementação final vieram de correções levantadas por agentes validadores. Oitenta e um problemas viraram vinte e uma features de correção. Um terço do produto existia porque um agente diferente, com outra função, recebeu permissão estrutural para discordar de quem escreveu o código.

Isso não é uma estatística de produtividade. É uma estatística de governança.

Quatro peças independentes publicadas neste mês — a arquitetura Missions da Factory, o documento de padrões de coordenação da Anthropic, o vazamento do “Coordinator Mode” no Claude Code e o ensaio “Thin Harness, Fat Skills” — convergem num deslocamento que a maior parte dos times ainda não nomeou: governança está saindo do prompt engineering e indo para a arquitetura. O padrão orquestrador-subagente está se tornando a unidade de governança de IA porque aplica estruturalmente a única regra que todas as outras camadas vinham tentando impor à base de disciplina e checklist: nenhum agente avalia o próprio trabalho.

O Problema da Deterioração do Contexto

O texto de Theo Luan sobre como as Missions funcionam abre com uma frase que deveria ficar pendurada na parede de qualquer time de IA:

Quando a janela de contexto acumula informação irrelevante — ou ativamente contrária — ao objetivo atual, o desempenho cai.

Todo praticante que já viu uma sessão longa apodrecer em confusão reconhece o formato dessa falha. O modelo não ficou burro. O contexto está envenenado. Erros antigos de ferramentas, planos abandonados, conteúdos de arquivos desatualizados e racionalizações retrospectivas disputam a mesma janela, e o modelo não consegue separar o que ainda importa. A cada turno, os tokens mais recentes empurram o objetivo original para fora, e o agente começa a otimizar pela discussão que está tendo agora, não pela tarefa que recebeu.

Durante um bom tempo, a indústria tratou isso como problema de prompt engineering. System prompts melhores. Contextos maiores. Compactação mais esperta. Memória. Retrieval.

Os sinais de abril de 2026 estão dizendo algo mais silencioso e mais estrutural: o problema não é a janela. O problema é que um único agente está fazendo vários trabalhos dentro da mesma janela. Não existe prompt que transforme um agente em planejador rigoroso, executor paciente e revisor cético ao mesmo tempo, porque esses papéis têm incentivos incompatíveis. O planejador quer opcionalidade. O executor quer terminar. O revisor quer achar o que o executor deixou passar. Coloque os três numa cabeça só e o executor vence — é ele quem tem o cursor na mão.

Separação de responsabilidades deixa de ser preferência estilística e vira a única forma de impedir que a deterioração do contexto devore o resultado.

Os Números da Factory, Lidos como Governança

Missions, na descrição da Factory, é um orquestrador que decompõe um objetivo em marcos e delega para dois tipos de subagente: workers que executam tarefas de implementação e validators que avaliam o resultado de forma independente. O orquestrador guarda o plano da missão e o estado compartilhado. Os subagentes guardam apenas o que precisam para a sua fatia.

No benchmark do clone do Slack, o formato da execução é o que importa:

  • 90 execuções de agente no total: 1 orquestrador, 63 workers, 27 validators.
  • 778,5 milhões de tokens consumidos, dos quais 744,9 milhões foram leituras em cache — quase 96%. Estado compartilhado é o que torna o fan-out economicamente viável.
  • 81 problemas levantados pelos validators, consolidados em 21 features de correção, respondendo pelos tais 34,4% da implementação final.

Leia esses números como um organograma e o que aparece é algo familiar: uma função de planejamento pequena, uma função de execução maior e uma função dedicada de revisão cujo único trabalho é discordar. Nenhum worker é convidado a dar nota ao próprio commit. Nenhum validator tem autoridade para dar deploy.

A economia de tokens importa mais do que parece à primeira vista. O motivo de 96% dos tokens estarem em cache é que o orquestrador não re-explica a missão para cada subagente do zero; ele passa um contexto compartilhado e estável que cada worker e cada validator lê sem pagar de novo. Estado compartilhado mais separação de papéis é o que torna isso barato. Sem o estado compartilhado, o custo do fan-out explode. Sem a separação de papéis, o fan-out não compra nada que uma sessão única mais longa já não oferecesse.

A leitura de governança: a Factory não construiu um programador mais rápido. Construiu uma estrutura em que um terço do produto é escrito porque alguém foi estruturalmente autorizado a rejeitar o primeiro rascunho.

A Anthropic Nomeia os Padrões

Uma semana depois, a Anthropic publicou um texto — “Multi-Agent Coordination Patterns” — que nomeia cinco arquiteturas entre as quais times de engenharia estão escolhendo agora:

  1. Generator-Verifier — um agente propõe, outro verifica.
  2. Orchestrator-Subagent — um líder decompõe e delega para subagentes especializados.
  3. Agent Teams — vários pares colaboram em um objetivo comum.
  4. Message Bus — agentes se comunicam por um canal compartilhado e ordenado.
  5. Shared State — agentes leem e escrevem em um workspace comum.

O ponto de partida recomendado é Orchestrator-Subagent. Não por ser o mais sofisticado — não é — mas por ser o padrão que força a separação que falta à maior parte dos times. Um agente planeja. Outros executam. Um caminho distinto faz a verificação. O orquestrador guarda o objetivo; os subagentes guardam a sua fatia; ninguém enxerga uma janela grande o bastante para confundir as duas coisas.

Lendo os cinco padrões lado a lado, a lógica de governança aparece. Generator-Verifier é a versão mínima viável de “nenhum agente avalia o próprio trabalho”. Orchestrator-Subagent é esse princípio somado à disciplina de contexto. Agent Teams, Message Bus e Shared State são o que se usa quando a superfície de coordenação ultrapassa um supervisor único. Mas todos os cinco compartilham o mesmo compromisso arquitetural: a unidade de confiança não é mais o agente. É o padrão.

É essa mesma mudança que o ensaio “Thin Harness, Fat Skills” torna explícita por outro caminho. Se o harness permanece fino — o loop, a interface de ferramentas, o escalonador — e as skills ficam gordas — as capacidades específicas de papel, os guardrails, a lógica de avaliação — a governança passa a morar em como as skills são compostas, não em como o harness é afinado. O harness coordena. As skills se especializam. A separação é o ponto.

A IDE Absorve o Padrão

O quarto sinal é o mais visível para o usuário final. O Testing Catalog reportou no começo de abril que a Anthropic está testando um Coordinator Mode para o Claude Code, uma interface visual estruturada para orientar sub-agentes em paralelo. O enquadramento do relato é competitivo — “para rivalizar com o superapp do Codex” — mas o significado arquitetural é maior do que isso.

O Coordinator Mode pega um padrão que antes exigia cola de orquestração feita em casa e transforma em uma superfície do próprio produto. O desenvolvedor passa a enxergar as subtarefas paralelas. Vê qual branch está planejando, qual está implementando, qual está revisando. O orquestrador deixa de ser detalhe de implementação e vira objeto de primeira classe na interface. É assim que padrões migram de “coisa que especialista constrói” para “coisa que todo mundo usa”: a IDE absorve.

Somado ao movimento anterior do VS Code em direção a contextos paralelos para subagentes, a direção é clara. O editor não é mais uma superfície de texto com IA pregada em cima. Está virando uma superfície de coordenação — e superfícies de coordenação são onde mora a governança.

O Pitch de Uma Frase

Já escrevemos sobre harnesses como a camada estrutural do trabalho com agentes, sobre arquitetura multiagente como redescoberta do isolamento da era Erlang, sobre a diferença que um bom harness faz e sobre times de agentes como um novo modelo operacional. Esses textos cobriram o “o que” e o “como”. Os sinais desta semana permitem formular o “por quê” em uma frase:

Nenhum deles avalia o próprio trabalho.

Esse é o pitch de governança do padrão orquestrador-subagente, e é o que separa esse padrão de qualquer experimento de “vamos encadear alguns prompts” que veio antes. O planejador não dá nota ao plano. O worker não dá nota ao commit. O validator não faz deploy. Cada papel recebe contexto suficiente para fazer o seu trabalho e autoridade suficiente para rejeitar o passo anterior. O orquestrador guarda o objetivo. A deterioração de contexto perde a sua superfície de ataque favorita — a janela única sobrecarregada — porque não sobra mais janela única sobrecarregada.

A consequência prática para quem está construindo com agentes agora é que escolher um padrão deixou de ser questão de estilo. Virou decisão de governança. Escolher Generator-Verifier em vez de um prompt único maior é decisão de governança. Escolher Orchestrator-Subagent em vez de Generator-Verifier é decisão de governança. Adotar ou não shared state é decisão de governança. Onde caem as linhas de separação determina o que o sistema é estruturalmente incapaz de errar — e esse é o único tipo de garantia que vale alguma coisa em um stack não-determinístico.

Trinta e quatro por cento de um produto escrito por agentes autorizados a discordar entre si não é uma história sobre orquestração esperta. É o novo piso. Times ainda rodando um agente, uma janela, um contexto e chamando isso de “um desenvolvedor de IA” não estão atrasados em ferramental. Estão atrasados em governança.

Os quatro sinais de abril — os números do Missions da Factory, o documento de padrões da Anthropic, o Coordinator Mode no Claude Code e o enquadramento thin-harness/fat-skills — não descrevem uma capacidade nova. Descrevem um novo formato para a mesma capacidade, e esse formato é o que engenheiros de Erlang, operadores de telecom e qualquer pessoa que já conduziu um code review sempre entenderam: separe as funções, limite o contexto e nunca deixe o executor dar nota para si mesmo. A camada de governança é a arquitetura. A arquitetura é o padrão orquestrador-subagente. E o padrão deixou de ser opcional.

Fontes

Ajudamos times a desenhar arquiteturas de agentes em que a governança é estrutural, não acoplada: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Parte do The Thinking Wire, publicado por Victorino Group.

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa