A correção contraintuitiva: dê menos trabalho pro seu agente
Olha só como quase todo time começa a construir agentes de IA em produção: um agente esperto, carregado com todos os schemas, regras e padrões que ele talvez precise. Na demo, funciona lindamente. Em produção... começa a alucinar.
No Meta, esse modo de falha apareceu exatamente assim ao automatizar o onboarding de colunas de dados em sistemas de recomendação — três repositórios, três linguagens e até seis estágios de pipeline que precisam ficar sincronizados. A primeira tentativa foi um único agente com todo o conhecimento de domínio embutido. Passado certo limiar de contexto, mais conhecimento piorou o resultado, não melhorou. O agente começava a contaminar conceitos: aplicava convenções de nomenclatura de um subsistema em outro, ou usava um padrão de geração de código pensado pra uma fonte de dados diferente.
Um preprint do Windreich Department of AI and Human Health do Mount Sinai confirma a tese: sistemas multiagente orquestrados atingiram 65,3% de acurácia em lotes de 80 tarefas, onde agentes únicos caíram pra 16,6%, reduzindo o uso de tokens em até 65 vezes. O mecanismo é o isolamento de tarefas evitando interferência de contexto. O Meta vivia o inverso: um agente se afogando no próprio conhecimento.
Essa análise é baseada no writeup publicado pelo Meta Engineering — confere o 근거자료 pra ver os detalhes completos de produção.
A arquitetura: roteador determinístico + especialistas isolados
O sistema se divide em duas camadas com uma fronteira bem dura entre elas:
- Um orquestrador fino (~1.300 linhas) que faz zero trabalho de domínio. Ele classifica intenção, coleta campos obrigatórios, roda gates de confiabilidade e delega. Nunca raciocina sobre código, nunca gera config, nunca toca no repositório.
- Quatorze subagentes especialistas, cada um um expert completo de domínio com janela de contexto isolada. O agente de schema conhece os registries de config. O agente de population sabe gerar código pras 10 fontes de dados. O agente de validação conhece os build systems. Nenhum agente enxerga o todo — e isso é a feature, não o bug.
O orquestrador segue um protocolo fixo de 7 passos em toda requisição:
# Protocolo fixo — passos 1-5 e 7 são determinísticos, só o passo 6 usa raciocínio de LLM
def handle_request(user_request):
# 1. Carrega o arquivo de instruções do subagente alvo
instructions = load_subagent_instructions(classify_intent(user_request))
# 2. Checagem de duplicata — o alvo já existe?
if target_exists(user_request):
return early_exit("Alvo já existe")
# 3. Coleta os campos obrigatórios com o usuário
fields = collect_required_fields(user_request, instructions.checklist)
# 4. Auto-descobre o que dá pra inferir (tipo de repo, configs existentes)
inferred = auto_discover(fields)
# 5. Gate de confiabilidade: warnings ativos, revisores obrigatórios
gate = reliability_check(fields, inferred)
if not gate.passed:
return escalate(gate.reason)
# 6. Delega pro subagente — o ÚNICO passo com raciocínio de LLM
result = subagent.execute(context=fields + inferred)
# 7. Retorna resultado e erros de forma determinística
return confirm_or_report(result)
Workflow templates, não novos agentes
O segundo insight chave: separar o que precisa acontecer de como cada passo é feito. O orquestrador define a ordem das fases via máquinas de estado determinísticas que restringem o espaço de decisão do LLM:
| Workflow | Sequência de fases |
|---|---|
| Column Onboarding | Schema → Validation → Population → Testing |
| Event Onboarding | Schema → Population → Validation → Testing → Event Processing |
| Pipeline Migration | Assessment → Planning → Population → Validation → Monitoring |
Quando o Meta precisou de pipeline migration — um caso de uso totalmente novo — escreveu zero código de agente novo. Escreveu um novo workflow template que reordenou os 14 subagentes existentes. Cada subagente segue uma estrutura uniforme (fontes de conhecimento, checklist de pré-coleta, workflow passo a passo, padrões de descoberta, troubleshooting), então o 15º subagente é estruturalmente idêntico ao primeiro. Os arquivos de conhecimento (25+) carregam on demand no momento da execução, não ficam embutidos no orquestrador — uma atualização vale na próxima sessão, sem redeploy.
As limitações e cuidados
Esse padrão não é de graça, e o writeup do Meta é honesto sobre os trade-offs:
- Você troca generalidade por profundidade. Cerca de dois terços das mudanças entram sem edição humana significativa — mas isso porque cada subagente é bem escopado. Uma requisição fora de qualquer workflow template não tem caminho até você escrever um.
- O custo de design inicial é real. Definir 14 fronteiras de domínio limpas, estrutura uniforme de subagente e gates determinísticos é trabalho de arquitetura considerável. O retorno chega na escala, não no dia um.
- A fronteira determinístico/probabilístico precisa ser explícita. Pra cada componente, decida: é decisão de roteamento (determinística) ou tarefa de raciocínio (probabilística)? Misturar os dois é como orquestradores gordos falham — quando um orquestrador gordo alucina, o erro se espalha: agente errado, campos errados, checagens de confiabilidade puladas.
- Não conserta subagente ruim. Isolamento contém falhas; não torna um especialista correto. Você ainda precisa de validação e revisão humana em qualquer atualização automática de conhecimento.
Pra onde ir agora
A tese composicional prevê que escalar significa adicionar workflow templates e arquivos de conhecimento — não reconstruir agentes. Se você constrói agentes em produção, comece auditando seu orquestrador: se ele está tomando decisões de domínio, está fazendo demais. Empurre esse raciocínio pros subagentes isolados e mantenha o roteamento determinístico. Pra ver como uma camada de data foundation sustenta sistemas agênticos, dá uma olhada em Beyond the Model: How Pantone Built an AI-Ready Data Foundation for Agentic Creativity.
Conclusão
O componente mais importante do sistema de agentes de IA do Meta é o que faz menos trabalho. Um orquestrador fino deixa pouquíssimo espaço pra alucinação, porque roteamento e confiabilidade não dependem de raciocínio de LLM — seguem um protocolo fixo. A criatividade acontece downstream, em contextos isolados e escopados por domínio, onde o risco é minimizado e as falhas ficam contidas.
Mantenha o orquestrador fino e os especialistas profundos, e o sistema inteiro fica mais confiável. E se você está tematizando componentes de UI enquanto monta seus dashboards de agentes, o guia de theming com CSS relative colors e OKLCH combina bem com essa mentalidade arquitetural — tokens determinísticos, responsabilidades isoladas.