Alto Valor Se, Baixo Valor Para Cada

Por que os agentes negociam em estruturas de julgamento, não em modelos

Por que a colocação do modelo, não a frequência do modelo, determina se os agentes se tornam produtos reais

Este é o primeiro de uma série sobre a engenharia de Agentes em Tempo de Execução. Argumenta que o problema de 2026 para os construtores de agentes não é a inteligência — é onde a inteligência é colocada. A série completa constrói a disciplina desde altos valores se até funções de valor, esquemas, fluxos de trabalho e o livro razão se/para cada.

Resumo

Você não está vendendo acesso ao modelo. Você está vendendo julgamento reutilizável.

A maioria dos produtos de agentes falha não porque o modelo é muito fraco, mas porque o modelo está no lugar errado. Eles colocam um modelo de fronteira dentro do loop para cada — relendo cada página, replanejando cada passo, regenerando cada ação — e então colapsam sob custos, latência e falhas de confiabilidade no momento em que saem do ambiente de demonstração.

A disciplina que este ensaio propõe: coloque o modelo estocástico em altos valores se — ramificações com alta incerteza, semântica densa e altas apostas — e entregue o para cada determinístico a programas, fluxos de trabalho e ferramentas. Uma vez que o modelo faz um julgamento útil, o sistema deve absorvê-lo em esquemas, fluxos de trabalho, registros de auditoria, habilidades e conjuntos de avaliação. O objetivo não é mais chamadas de modelo. O objetivo é menos desnecessárias ao longo do tempo.

Modelos de fronteira abrem caminhos. Sistemas determinísticos pavimentam estradas. Tudo o mais é engenharia.

1. O Problema de 2026 para Construtores de Agentes

A maioria das demonstrações de agentes — construídas pelo que eu chamarei de construtores de agentes: as equipes que projetam roteamento de modelos, fluxos de trabalho, esquemas, permissões, aprovações e registros de auditoria — falham pela mesma razão: colocam o modelo no lugar errado.

Eles pedem ao modelo para ler cada página, reentender cada DOM, replanejar cada passo e gerar cada ação. A demonstração parece impressionante. O produto colapsa sob pressão de custos, falhas de latência, falhas de confiabilidade e falta de reutilização.

O primeiro problema comercial dos agentes não é a inteligência. É onde a inteligência é colocada. Onde o modelo estocástico deve aparecer dentro de um sistema determinístico?

Nos últimos dois anos, desde a explosão das Conclusões de Chat até o surgimento de camadas de compatibilidade de Uso de Computador, a indústria atingiu uma parede estrutural: não há mecanismo para cristalizar o julgamento estocástico em ativos determinísticos. Cada chamada de modelo ainda é uma despesa única. Quando a tarefa termina, a exploração desaparece com ela.

Em 2026, a camada de modelo está se movendo de interfaces de conclusão de chat para primitivos de construção de agentes — API de Respostas, Saídas Estruturadas, Uso de Computador, SDK de Agentes, Agentes de Sandbox. Os custos de inferência de fronteira estão caindo em uma faixa onde a análise semântica profunda finalmente se torna viável. Ecossistemas de tempo de execução locais estão se tornando maduros o suficiente para orquestrar tarefas complexas. E a velha internet passou três décadas comprimindo a realidade em proxies de baixa resolução — graus, classificações, volume de vendas, cliques, classificações e outros campos classificáveis — que agora expõem fraquezas sistêmicas sob degradação da informação e a Lei de Goodhart.

Construtores de agentes precisam de uma metodologia completa que abranja altos valores se, funções de valor e implementação de engenharia. A questão se reduz a uma coisa:

Como um único julgamento de modelo pode se tornar um ativo durável do sistema?

Construtores não vencerão superando os provedores de modelos em escala. Eles vencerão possuindo as estruturas de julgamento, fluxos de trabalho e limites de responsabilidade que os modelos atendem.

2. Colocação de Modelos, Não Frequência de Modelos

Em sistemas de agentes, a colocação do modelo importa mais do que a frequência do modelo.

O agente que faz tudo e impressiona o público das demonstrações morre na produção devido a explosões de custo e colapsos de confiabilidade. A resposta não está na contagem de parâmetros ou na sofisticação do prompt, mas na disciplina de engenharia mais fundamental: onde o modelo se senta na arquitetura.

Luo Fuli, que liderou a pesquisa DeepSeek-V2 antes de se juntar à equipe MiMo da Xiaomi no final de 2025, enquadrou isso em uma entrevista recente como um produto de três fatores: eficácia × custo × eficiência. A formulação é importante porque força o design do agente a voltar do mito da "totalmente autônomo" para a realidade de engenharia do tempo de execução. Nenhum dos três é opcional. Eficácia sem controle de custos não pode se tornar um produto comercial. Baixo custo sem resultados confiáveis não cria disposição para pagar. Eficiência que só executa fluxos determinísticos não é um agente — é RPA com uma camada.

Traduzir isso em decisões arquitetônicas concretas nos dá a primeira disciplina de engenharia da era do agente.

O Que os Modelos Devem e Não Devem Fazer

Os últimos dois anos de prática de Agentes em Tempo de Execução — a camada de execução que gerencia estado, permissões, fluxos de trabalho, chamadas de ferramentas, roteamento de modelos, registros de auditoria e aprovação humana — apontam repetidamente para uma divisão de trabalho:

O Agente em Tempo de Execução deve colocar o modelo em ramificações de decisão de alta incerteza, semanticamente densas e de altas apostas. Ele deve entregar a execução repetível, bem definida, verificável e de baixo risco a programas, fluxos de trabalho e camadas de ferramentas.

Baixo valor para cada: como é

Para cada é trabalho em lote, repetitivo, procedural e bem definido:

• Raspagem em lote de páginas da web
• Organização em lote de arquivos
• Exportação em lote de registros de conversa
• Conversão em lote de Markdown para outros formatos
• Execução em lote de fluxos de navegador conhecidos
• Chamadas em lote a endpoints de API
• Estruturação em lote de conteúdo em formatos uniformes
• Classificação em lote de itens em uma primeira passagem de baixo risco

Essas tarefas são frequentemente embaladas como "automação de IA", mas estruturalmente pertencem a programas, scripts, CLI, SQL, sistemas de fila, mecanismos de regras, Playwright, ferramentas MCP ou pipelines determinísticos.

Em tarefas que podem ser descritas de forma determinística, os programas são tipicamente ordens de magnitude mais baratos, rápidos, estáveis e mais fáceis de auditar e reproduzir do que chamadas de LLM.

Se uma tarefa pode ser descrita como:

for item in items:
    do_something<