A Stack de Agentes Está se Dividindo em Duas

O erro mais caro no design de agentes hoje é usar o mesmo modelo para tudo. Você pega um modelo de ponta para decidir se chama uma API e depois usa esse mesmo modelo para formatar o payload JSON. Uma dessas tarefas precisa de um físico; a outra precisa de um escriturário competente. Pagar tarifa de físico para trabalho burocrático não é só desperdício — é engenharia ruim. Isso acopla a inteligência do seu agente ao seu custo operacional de um jeito que piora ambos.

O lançamento do Muse Ember pela Meta torna essa divisão concreta. É um modelo pequeno construído especificamente para o que os agentes de fato passam a maior parte dos ciclos fazendo: chamadas de ferramenta, roteamento e extração de dados [1]. A 10 centavos por milhão de tokens de entrada, ele corta pela metade o preço do Claude Haiku 5.5 e do GPT-6 Luna com uma margem enorme [3]. A Meta alega que ele entrega mais inteligência por dólar nessas tarefas repetitivas, enquanto admite abertamente que fica devendo em programação de verdade [1]. Essa admissão é a parte interessante. Eles não estão vendendo um modelo que faz tudo; estão vendendo um modelo que faz as partes chatas da agência com extrema economia.

A camada de execução vira commodity

Nos últimos dois anos, a arquitetura padrão de agentes tem sido monolítica. Um modelo — geralmente de ponta — cuida do planejamento, raciocínio, seleção de ferramentas e do trabalho mecânico de estruturar as saídas. Isso fazia sentido quando modelos menores não conseguiam produzir chamadas de função válidas ou seguir instruções de roteamento de forma confiável. Mas esse limiar de confiabilidade foi ultrapassado. O Muse Ember não é o primeiro modelo pequeno a lidar com uso de ferramentas com competência, mas seu preço e o posicionamento explícito da Meta como um motor de execução para agentes sinalizam que essa camada agora é um mercado de commodity.

A implicação para quem constrói é que a arquitetura do seu agente agora tem uma costura óbvia. A camada de raciocínio — onde você precisa de inteligência de verdade para decompor tarefas, lidar com ambiguidade ou escrever código — fica com um modelo de ponta. A camada de execução — onde você precisa de saídas rápidas, confiáveis e estruturadas a partir de padrões conhecidos — vai para algo como o Ember. As duas camadas podem ser modelos diferentes, de fornecedores diferentes, otimizados para coisas diferentes.

O que isso significa para avaliação

Essa divisão complica a avaliação de maneiras úteis. Você não pode mais fazer benchmark do seu agente como uma caixa-preta única e dar o trabalho por encerrado. Um agente que roteia de forma inteligente mas formata chamadas de ferramenta de qualquer jeito tem um problema diferente de um que formata perfeitamente mas roteia de forma estúpida. Quando os modelos de raciocínio e execução vêm de fornecedores diferentes, você precisa de avaliações que isolem cada camada. Isso significa testes de aderência ao schema de chamadas de ferramenta, precisão de roteamento sob variação de prompt e fidelidade de extração que rodam independentemente das suas avaliações de planejamento.

Isso também muda como você pensa sobre fallback. Se seu modelo de execução for barato o suficiente, você pode se dar ao luxo de rodá-lo múltiplas vezes com prompts diferentes e votar na saída — um padrão proibitivamente caro com modelos de ponta. Confiabilidade via redundância se torna uma estratégia legítima quando as chamadas redundantes custam frações de centavo.

A lição do Instagram

Há um segundo sinal que vale a pena notar, embora venha de uma direção diferente. O Effect Builder do Instagram agora gera filtros de RA a partir de prompts de IA [2]. Isso não é infraestrutura de agentes — é uma funcionalidade de consumo. Mas ilustra o mesmo padrão pelo outro lado: a IA está migrando para papéis de execução onde a saída é um artefato estruturado, não uma conversa. Um prompt produz um filtro, não uma mensagem de chat. O modelo está fazendo uso de ferramenta, só que empacotado numa interface amigável.

Para quem constrói agentes, isso é um lembrete de que saída estruturada está se tornando a expectativa padrão, não uma capacidade especializada. Quando aplicativos de consumo tratam prompt-para-artefato como uma funcionalidade normal, a capacidade do seu agente de produzir JSON válido de primeira deixa de ser impressionante e passa a ser pré-requisito. A diferenciação sobe para o raciocínio que decide qual JSON produzir e por quê.

A conclusão prática é direta. Analise o consumo de tokens do seu agente e separe-o em trabalho de raciocínio e trabalho de execução. Se mais da metade do seu gasto está em geração de saída estruturada, decisões de roteamento ou aderência a schema, você tem uma costura onde um modelo como o Muse Ember se encaixa. A diferença de custo não é marginal — é uma ordem de grandeza — e o benefício de engenharia de desacoplar inteligência de execução vai se multiplicar conforme as duas camadas evoluem em velocidades diferentes.