Arquitetura Multiagente: O Que Erlang, VS Code e um Loop dos Simpsons Revelam

Em 1986, engenheiros da Ericsson lançaram a máquina virtual BEAM para operar centrais telefônicas. Cada chamada telefônica se tornava um processo isolado com sua própria memória, seu próprio ciclo de vida e sua própria fronteira de falha. Processos se comunicavam por passagem de mensagens. Supervisores monitoravam crashes e reiniciavam processos em estado limpo. O sistema lidava com milhões de chamadas simultâneas com disponibilidade de cinco noves.

Em 2026, a indústria de IA está reconstruindo exatamente essa arquitetura --- em Python.

Quatro acontecimentos de fevereiro tornam essa observação mais do que uma nota de rodapé.

O Paralelo com o BEAM

George Guimarães, ex-engenheiro principal no Nubank (via a aquisição da Plataformatec), publicou um argumento técnico detalhado de que todo grande framework de agentes em Python está convergindo para padrões que o BEAM resolveu há décadas.

O mapeamento é desconfortavelmente preciso:

Langroid cita explicitamente o Actor Framework como inspiração. Agentes são “transformadores de mensagens” que se comunicam por passagem direta de mensagens. É o modelo de atores do Erlang com sintaxe diferente.
AutoGen v0.4 foi reconstruído pela Microsoft como um “framework de atores orientado a eventos” com passagem assíncrona de mensagens e ciclo de vida gerenciado pelo runtime. Chegaram ao modelo de atores independentemente porque o problema exige isso.
LangGraph implementa máquinas de estado com estado compartilhado via reducers.
CrewAI organiza agentes por encadeamento de saídas de tarefas e delegação.

Cada framework segue uma rota diferente, mas convergem nos mesmos requisitos: estado isolado por agente, comunicação por mensagens, orquestração de workflows e recuperação de falhas. O OTP --- Open Telecom Platform do Erlang, formalizado em 1998 --- já tinha soluções para cada um desses problemas como primitivas do runtime, não como bibliotecas.

A lacuna técnica é real. Processos BEAM ocupam aproximadamente 2KB cada. É possível criar milhões. Cada um tem seu próprio heap e coletor de lixo, e o escalonador alterna preventivamente entre eles a cada 4.000 reduções para que nenhum processo monopolize a CPU. O asyncio do Python oferece concorrência sem isolamento: todas as corrotinas compartilham memória, e uma corrotina problemática pode corromper o estado de todas as outras. O Node.js tem melhor concorrência, mas permanece fundamentalmente single-threaded.

Guimarães estima que é possível alcançar cerca de 70% das capacidades do BEAM em Python ou TypeScript com engenharia suficiente. Os 30% restantes --- escalonamento preemptivo, coleta de lixo por processo, hot code swapping, isolamento real de falhas --- requerem suporte no nível do runtime. Não há como aparafusar essas capacidades em uma linguagem que não foi projetada para isso.

A Camada de IDE Alcança o Runtime

Em 4 de fevereiro, a Microsoft lançou o VS Code v1.109, que transforma o editor no que equivale a uma superfície de controle multiagente.

Três funcionalidades importam arquiteturalmente:

Subagentes paralelos. Agentes podem gerar subtarefas que executam em paralelo, cada uma com sua própria janela de contexto dedicada. Isso é isolamento de processos no nível da IDE. O contexto do agente principal não estoura porque cada subagente opera independentemente --- o mesmo princípio do modelo de memória por processo do BEAM.

MCP Apps. Servidores agora podem enviar atualizações de contexto dinamicamente para sessões de chat. Isso muda o MCP de um modelo pull (agente chama ferramenta) para um modelo push (servidor atualiza contexto), habilitando ciclos de feedback mais ricos sem polling manual.

Gerenciamento unificado de sessões. Desenvolvedores podem executar Claude, Codex e Copilot lado a lado, alternando entre sessões de agentes locais e na nuvem a partir de uma única interface. Isso possibilita o tipo de equipes especializadas de agentes que sistemas de produção exigem: um agente de planejamento em um modelo, um agente de implementação em outro, um scanner de segurança em um terceiro.

O sinal arquitetural é que o VS Code não está adicionando funcionalidades de IA. Está adicionando primitivas de concorrência. Isolamento, execução paralela e gerenciamento de ciclo de vida de sessões são os mesmos problemas que o BEAM resolveu para telefonia, aplicados ao ferramental de desenvolvimento.

O Ciclo de Feedback Adversarial

Joshua Samuel publicou o Grandpa Loop, uma arquitetura de orquestração com 13 agentes que aborda o problema de confiabilidade de forma diferente. Onde o BEAM usa árvores de supervisão para recuperação de falhas, o Grandpa Loop usa revisão adversarial para prevenção de falhas.

A arquitetura atribui a cada agente uma única responsabilidade com zero confiança no agente anterior. Os nomes vêm de Os Simpsons, mas os padrões de design são sérios:

Sideshow Bob revisa toda especificação antes que código seja escrito. Seu trabalho é adversarial: encontrar lacunas, ambiguidades e premissas não declaradas. Uma spec rejeitada custa minutos. Uma spec ruim que sobrevive custa o ciclo inteiro de build-test-deploy.

Bart é o testador destrutivo cujo trabalho não é confirmar que o build funciona, mas provar que não funciona.

Comic Book Guy percorre jornadas reais de usuário no ambiente de staging. É o único agente que pode bloquear um commit baseado em usabilidade, não apenas em correção funcional. Se os testes automatizados passam mas a UX é confusa, ele emite ux.blocked e o pipeline reinicia.

Vovô observa o sistema inteiro. Monitora contagens de iteração, padrões de falha e tempos de ciclo. Faz uma mudança mínima por vez e documenta cada ajuste com justificativa.

O princípio-chave do design: “Se você não pode provar, não aconteceu.” Nenhum agente pode declarar sucesso sem evidência estruturada. Isso é contrapressão aplicada ao pipeline inteiro --- o mesmo conceito que as árvores de supervisão do BEAM implementam no nível de processos, aplicado aqui no nível de workflow.

Os paralelos com o BEAM são estruturais:

Árvores de supervisão reiniciam processos com crash → Revisão adversarial previne specs defeituosas de entrar no pipeline de build
Isolamento por processo → Agentes de responsabilidade única com zero confiança
Distribuição nativa → Trilhas paralelas de testes e documentação

Samuel é honesto sobre os trade-offs. Treze agentes significam treze chamadas de LLM no mínimo por iteração. Para uma mudança de uma linha, é “como contratar uma orquestra para tocar uma campainha.” Os loops derivados (Bugfix: 4 agentes, Deploy: 2 agentes, UX Discovery: 2 agentes) mostram a resposta prática: use o subconjunto do tamanho certo para a tarefa.

Estratégia Importa Mais Que Capacidade

Se arquitetura multiagente trata de como agentes se coordenam, a pesquisa do Context Lens de Lars de Ridder mostra por que a estratégia de coordenação importa mais que a capacidade bruta do modelo.

Ele plantou um bug no Express.js, deu o mesmo prompt para quatro ferramentas de coding com IA e interceptou cada chamada de API. As quatro resolveram o bug. A diferença estava em como usaram suas janelas de contexto:

Ferramenta	Tokens Médios	Estratégia
Opus 4.6	27K	”O Detetive” --- git log, diff direcionado, 20 linhas lidas, correção
Codex (GPT-5.3)	35K	”O Hacker Unix” --- grep/sed paralelo, ignora git
Sonnet 4.5	50K	”O Estudante” --- lê arquivo de teste inteiro, constrói modelo mental
Gemini 2.5 Pro	258K	”O Professor” --- despeja 118K tokens de histórico git em uma chamada

Mesmo resultado. Uma diferença de 10x no consumo de recursos. Opus usou 27K tokens porque identificou a fonte de informação mais eficiente (histórico git) e tomou o caminho mais direto. Gemini absorveu históricos inteiros de arquivos porque podia.

A conclusão de de Ridder: “Gerenciamento de contexto, do lado da ferramenta, é basicamente inexistente. As diferenças de eficiência vêm inteiramente da estratégia de investigação, não de qualquer tentativa deliberada de gerenciar a janela de contexto.”

Isso tem implicações diretas para arquitetura multiagente. Quando você executa treze agentes, disciplina de contexto se torna multiplicativa. Um agente que lê 20 linhas em vez de 500 economiza não apenas tokens, mas o efeito cascata de contexto poluído em cada decisão subsequente. O princípio do Grandpa Loop de contexto fresco por iteração e o isolamento de memória por processo do BEAM resolvem ambos o mesmo problema subjacente: prevenir que contaminação de contexto se propague pelo sistema.

O Que Isso Significa Para Equipes Construindo Sistemas de Agentes

A convergência desses quatro sinais sugere um conjunto de princípios arquiteturais:

Isolamento não é opcional. Seja através de processos BEAM, janelas de contexto de subagentes do VS Code, ou agentes de responsabilidade única com zero confiança, toda arquitetura multiagente bem-sucedida constrói muros entre agentes. Estado compartilhado é o caminho para falhas em cascata.

Supervisão supera código defensivo. A filosofia “let it crash” do BEAM e a revisão adversarial do Grandpa Loop são duas expressões do mesmo insight: você não pode antecipar todo modo de falha em um sistema não determinístico. Construa mecanismos de recuperação, não tratadores de erros.

Disciplina de contexto é um multiplicador. A lacuna de eficiência de 10x entre Opus e Gemini na mesma tarefa demonstra que estratégia importa mais que capacidade. Isso se aplica a agentes individuais e a sistemas multiagentes: a arquitetura que mantém o contexto de cada agente mínimo e focado superará a arquitetura que despeja tudo em memória compartilhada.

A arquitetura não é nova. Erlang resolveu orquestração concorrente e tolerante a falhas de agentes em 1986. O VS Code está implementando isolamento e paralelismo no nível da IDE. O Grandpa Loop demonstra ciclos de feedback adversariais no nível de workflow. Os padrões são os mesmos. O que muda em 2026 são as apostas --- e o não-determinismo das saídas de LLMs.

A verdade desconfortável de Guimarães: você não está construindo algo novo. Está reconstruindo infraestrutura de telecomunicações em uma linguagem que não foi projetada para isso. A questão é se você aprende com as três décadas de experiência de produção que já existem, ou gasta os próximos três anos redescobrindo isso.

Fontes: George Guimarães, VS Code v1.109, Joshua Samuel, Lars de Ridder. Para saber como aplicar governança multiagente na sua equipe de engenharia: contato@victorino.com.br | www.victorino.com.br