Chamadas de função de LLM não escalam; orquestração por código é mais simples e eficaz

• A forma como LLMs processam todo o resultado de chamadas de ferramentas é lenta, cara e pouco favorável à escalabilidade
• Em vez disso, propõe-se uma abordagem em que o LLM orquestra o processamento de dados estruturados com base em esquemas de saída por meio de código
• Essa abordagem é adequada para processar grandes volumes de dados com encadeamento de funções via código e gerenciamento de memória baseado em variáveis
• A abordagem de processamento de dados baseada em execução de código oferece alta precisão e escalabilidade, já que o LLM não precisa reconstruir os dados diretamente
• A construção de um ambiente de runtime de IA seguro está surgindo como um novo desafio, e há necessidade de um ambiente de execução sustentável e capaz de manter estado

---

LLM function calls don't scale; code orchestration is simpler, more effective.

Limitações da abordagem tradicional de reenviar ao LLM os resultados das chamadas de ferramentas

• Ao usar ferramentas MCP (Machine Context Protocol), normalmente o resultado da ferramenta é enviado ao LLM como mensagem para induzir a próxima ação
• Em casos de uso reais, os servidores MCP da Linear e da Intercom retornam respostas grandes em formato JSON
• JSON é semelhante a uma API, mas sem um esquema de saída definido, o LLM tem o ônus de analisar todo o texto
• Por exemplo, o resultado da consulta da lista de issues no Linear é muito grande: 70.000 caracteres em 50 itens, cerca de 25.000 tokens
• Muitos campos id não têm significado prático, mas consomem tokens, e se o LLM precisar reproduzi-los como estão, o custo e a chance de erro aumentam

Necessidade de separar processamento de dados e orquestração

• A abordagem atual mistura processamento de dados e orquestração em uma única sessão de chat
• Alguns criam outras threads como “agentes” para isso, mas quando o JSON já é estruturado, isso é ineficiente
• Uma abordagem melhor é processar os dados estruturados diretamente com código
  • Ex.: para ordenar issues, em vez de o LLM gerar a saída, o código executa sort e retorna apenas o array resultante

Processamento de dados baseado em execução de código

• Computação de IA por meio de execução de código já é usada em vários interpretadores de IA
• Essa abordagem permite uma estrutura simples em que o LLM não produz os dados diretamente e só precisa decidir como usar as ferramentas

Conceitos principais

• Uso de variáveis como memória: atribuir um valor = armazenar, exibir = consultar, passar como argumento ao chamar funções
• Suporte a encadeamento de funções: combinação de várias chamadas de função em paralelo ou em sequência, com dependências expressas naturalmente no fluxo do código
• Processamento escalável de grandes volumes de dados: em conjunto com NumPy, pandas etc., é possível lidar facilmente com milhares ou dezenas de milhares de registros
• Também é possível chamar outros LLMs: dentro do código escrito pelo LLM, outro LLM pode ser chamado para processar dados não estruturados

O MCP está preparado?

• A especificação do MCP já define um esquema de entrada, e recentemente também foi submetido um PR de esquema de saída
• Quando esquemas de saída se tornarem comuns, usos como os seguintes passam a ser possíveis:
  • painel de status de issues
  • relatório semanal de tickets concluídos
  • a IA monitorando tickets parados e enviando alertas

Desafios do ambiente de execução de código

• Segurança é a questão central: como se executa código gerado por IA/usuário, é necessário projetar mecanismos para evitar exposição de chaves de API e dados
• No caso da Lutra, o ambiente de execução é estruturado em modo sandbox, e ao modelo é fornecida apenas a documentação de chamadas de API
• Ambientes de execução com manutenção de estado (como Jupyter) têm alto custo, e para sessões de longa duração são necessárias características de sem estado (stateless) + persistência (persistent)
• Isso forma uma nova categoria de runtime de IA, cujo design ainda está sendo desenvolvido ativamente

Conclusão

• A abordagem tradicional de inserir no LLM os resultados de chamadas de ferramentas para processamento tem limitações de custo e precisão
• A orquestração baseada em código permite um processamento simples, escalável e preciso
• Ambientes de execução de código para IA estão ganhando atenção como a próxima geração de runtimes com segurança, persistência e escalabilidade

[GN⁺]

Comentários do Hacker News

• Compartilhamento da experiência de defender, nos últimos 2 anos, que “um agente suficientemente sofisticado é indistinguível de uma DSL”. Em vez de exigir que o agente internalize algoritmos, a opinião é que faz muito mais sentido ensinar APIs e pedir que ele projete algoritmos usando essas APIs para execução no espaço do usuário. Colocar algoritmos dentro do LLM é visto como ineficiente, exceto em casos muito específicos (em termos de custo ou precisão). A comparação é com pedir a um desenvolvedor que execute chamadas de função mentalmente
  • Isso é interpretado como evidência de que o caminho para a ASI não está em expandir as capacidades do LLM, mas sim em extrair e compilar, externamente, algoritmos de autoaperfeiçoamento na forma de aplicações simbólicas
  • Pedido de exemplos ou evidências de que o termo 'agent' já era amplamente usado nesse contexto desde 2 anos atrás
• Experiência prática construindo diretamente sistemas agentic no próprio negócio de e-commerce. Foi avaliado o smolagents, que é elegante e atraente, mas tem como desvantagem aumentar bastante a complexidade do sistema. É perfeito para ambientes sem schema, como relatórios dinâmicos que exigem ordenar e agregar dados, mas para a maioria das tarefas é exagero. Gemini e OpenAI oferecem recurso de interpretador Python, cobrindo boa parte do trabalho de agentes de código. Uma abordagem de empilhar indefinidamente mensagens de chamada de ferramenta no stack não escala bem e não é recomendada. Na prática, workflows agentic têm vida curta e sua complexidade é administrada com estrutura e disciplina. A lição do desenvolvimento de software tradicional continua a mesma: escalar chamadas de função e evitar caos segue sendo o mesmo desafio de antes. O ponto central para construir bons sistemas é administrar a carga cognitiva do desenvolvedor, e soluções simples que funcionam bem superam abordagens rebuscadas de alto desempenho. A combinação de chamadas de função é um exemplo desse tipo de solução simples, e o tratamento de dados estruturados também pode ser resolvido suficientemente com métodos tradicionais de parsing e transformação. Quando a estrutura é desconhecida, até modelos baratos apresentam excelente desempenho de parsing. No fim, gerenciar a complexidade de sistemas agentic se resume a administrar meticulosamente o estado da aplicação. Manipular o stack de mensagens permite montar com flexibilidade o contexto ativo que será dado ao modelo, de forma parecida com gerenciamento de memória em ambientes restritos
  • Um resumo que aponta com precisão os trade-offs dos sistemas agentic. Nós também enfrentamos o mesmo problema ao construir uma solução conversacional de busca de produtos para e-commerce (IsarTech). Combinação de funções e dados estruturados são centrais para controlar a complexidade. Pela experiência, saídas baseadas em schemas de tipos claros aumentam de forma concreta a escalabilidade de chamadas de ferramenta. Graças ao schema tipado, dá para gerenciar tanto a carga cognitiva quanto a complexidade do sistema. A recomendação é depender do máximo possível de comportamento determinístico e usar LLM apenas quando houver dados sem schema ou ambiguidade. LLM é muito eficaz para mapear solicitações ambíguas para sistemas determinísticos. Ainda assim, é preciso equilibrar a remoção de complexidade em entradas de alta entropia (não estruturadas) com o aumento de complexidade causado por cadeias de chamadas de ferramenta. Em ambientes reais de comércio, é difícil usar apenas uma abordagem, e saídas estruturadas têm limites diante de intenções ambíguas, exigindo estratégias adicionais
• A crítica é que o problema não está nas chamadas de função em si, mas no design e no modo de uso do MCP. A maior parte dos MCPs são cópias de APIs e apresentam o problema de despejar dados sem sentido. O formato JSON é aninhado repetidamente, consumindo contexto de entrada desnecessariamente, e inclui muita informação irrelevante. Seria preciso otimizar com flattening dos dados e remoção de campos desnecessários. No fim, MCP SaaS não passa de um API gateway. Hoje, o MCP é apontado como um dos principais geradores de ruído e ainda está longe de ser suficientemente otimizado
  • GraphQL é justamente uma tecnologia otimizada para esse propósito. Ela foi projetada para permitir selecionar apenas os campos necessários. Foi desenvolvido um gateway open source que converte várias queries GraphQL em um único servidor MCP
  • Levanta-se a dúvida se o problema não seria o fato de o modelo não seguir corretamente schemas JSON complexos
  • MCP não ajuda, mas filtrar tudo indiscriminadamente também não é a melhor resposta. Às vezes, o agente precisa processar grandes volumes de dados. Nesses casos, executar código com uma avaliação simples dos dados e descrição do schema é uma abordagem mais escalável. Claro, quando o sistema cresce demais, problemas parecidos voltam a surgir. A solução final seria reproduzir em código a precisão do raciocínio determinístico humano e fazer o LLM chamar esse sistema de decisão. Em teoria parece fácil, mas na prática é muito difícil de implementar
  • Ao testar inversão de strings com ChatGPT, houve a sensação de que é muito difícil fazer o LLM entregar apenas um resultado simples, e a confiabilidade também pareceu baixa. Depois dessa experiência, virou hábito validar sempre com vários LLMs. Mantido esse ritmo, talvez seja preciso preparar um datacenter próprio com GPUs só para contar caracteres em uma string, em tom de piada
• A equipe da Shopify recentemente abriu o código do Roast. É uma ferramenta que permite inserir tarefas não determinísticas de LLM em workflows dentro de uma grande base de código automatizada. Essencial para automatizar trabalhos complexos
  • Roast causou forte impressão. A harmonia entre determinismo e não determinismo chama muita atenção. Há alguma confusão sobre como o LLM orquestra várias chamadas de ferramenta e como decide a ordem das chamadas. Parece funcionar bem para instruções de refatoração, mas fica a dúvida se serve para tarefas compostas como “melhorar → testar repetidamente”
  • É interessante ver que Ruby continua funcionando de forma relevante até na era da IA
  • Mesmo lendo só a documentação, já parece uma abordagem intelectualmente estimulante. Impressiona a forma como as capacidades do LLM foram empacotadas de forma declarativa
  • Pedido de exemplos concretos de como esse tipo de workflow é usado na prática dentro da Shopify
  • Houve experiência de travar tanto o Claude Code Research Preview quanto o ChatGPT 4.5 Pro Deep Research (com evidências), e segue a busca por uma ferramenta que funcione de forma confiável
• A melhor resposta está em um híbrido, não em um extremo. A visão é que o ideal é resolver o máximo possível com abordagens determinísticas e usar LLM apenas nas partes complexas em que especificação ou técnicas determinísticas não bastam
  • Focar em usar LLM para gerar soluções determinísticas (código) é uma abordagem interessante; uma vez validado, esse código pode ser reutilizado daí em diante como código determinístico
  • Defende-se que o objetivo deve ser minimizar o uso de LLM dentro do workflow
• Surpresa ao ver que, após mais de 1 ano fora do setor, esse tipo de experimento complexo parece ter se tornado comum
  • Na prática, ainda são poucos os que estão experimentando, e embora não haja casos revolucionários, existem alguns usos úteis
  • Também aparece a opinião de que, se a pessoa não estiver fazendo esse tipo de trabalho agora, em breve vai acabar saindo do setor de novo
  • O trabalho cotidiano de uma pessoa já está fortemente voltado para automação de design de agentes de IA baseados em LLM. Não foi algo planejado; simplesmente aconteceu
• Pergunta sobre por que usar LLM para ordenar dados estruturados
  • O objetivo principal é lidar com processamento de dados mais complexo, como construção de dashboards, identificação automática de tickets de issues e revisões trimestrais. Ordenação é apenas um exemplo simples para facilitar a compreensão da escala do problema
• O huggingface smolagent é um caso representativo dessa abordagem, mas traz o problema de que rollback ou recuperação ficam muito difíceis quando a execução real falha. Em teoria, seria possível resolver encapsulando todo o bloco de execução em uma transação distribuída, mas na prática o LLM tende a gerar código robusto de um jeito que não combina com esse padrão, tornando rastreamento de erros e identificação da causa da falha mais difíceis
  • Concordância de que a ideia central do smolagent é boa, mas a realidade de execução e tratamento de erros é o problema. Por exemplo, seria desejável conseguir continuar diretamente a partir do estado em que a execução foi interrompida. Já foi confirmado que o LLM escreve bem código de recuperação de estado, e hoje essa funcionalidade está operando razoavelmente bem em um produto real (Lutra)
• Como outra abordagem, sugere-se induzir o LLM a escrever código que chama MCP como se fosse uma função (na forma de script Python). Um exemplo de código é compartilhado
  • Como caso de uso prático dessa abordagem, é apresentado o Lutra.ai. O ponto principal é o quão bem o runtime de código é projetado
• O fato de que LLMs são particularmente fracos com JSON, especialmente JSON grande. Não há necessidade de que o endpoint retorne dados obrigatoriamente em JSON; outros formatos também servem. LLMs às vezes mostram desempenho bem melhor com XML, e também é possível gerar texto narrativo por template
  • XML é um formato com significado intrínseco, então causa estranheza que ele não seja mais amplamente usado como padrão com LLMs. Quando necessário, converter XML deterministicamente para JSON e inserir no pipeline também pode ser eficaz
  • Experiência de ter obtido resultados bastante bons usando tabelas Markdown ao retornar dados para o LLM
  • Fica a curiosidade se o melhor desempenho de XML acontece porque aparece com mais frequência nos dados de treinamento do LLM ou porque contém mais tokens de texto. Também se menciona a possibilidade de que blocos de texto maiores deem mais contexto ao LLM