Las llamadas a funciones de LLM no escalan; la orquestación con código es más simple y efectiva

• La forma en que los LLM procesan todo el resultado de una llamada a herramientas es lenta, costosa y poco favorable para escalar
• En su lugar, se propone que el LLM orqueste un enfoque donde los datos estructurados basados en esquemas de salida se procesen con código
• Este enfoque es adecuado para procesar grandes volúmenes de datos mediante encadenamiento de funciones con código y gestión de memoria basada en variables
• El procesamiento de datos basado en ejecución de código ofrece gran precisión y escalabilidad porque el LLM no reconstruye directamente los datos
• La construcción de un entorno de ejecución de IA seguro está surgiendo como un nuevo reto, y se necesita un entorno de ejecución sostenible y con capacidad de mantener estado

---

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

Límites del enfoque tradicional de volver a pasar al LLM los resultados de llamadas a herramientas

• Al usar herramientas MCP (Machine Context Protocol), normalmente se le entrega al LLM el resultado de salida de la herramienta como un mensaje para inducir la siguiente acción
• En casos de uso reales, los servidores MCP de Linear e Intercom devuelven respuestas grandes en formato JSON
• JSON es similar a una API, pero como no hay un esquema de salida definido, el LLM tiene la carga de analizar todo el texto
• Por ejemplo, el resultado de consultar la lista de issues de Linear es muy grande: 70,000 caracteres para 50 elementos, alrededor de 25,000 tokens
• Muchos campos id no tienen significado, pero consumen tokens, y si el LLM intenta reproducirlos tal cual, aumentan el costo y los errores

Necesidad de separar el procesamiento de datos y la orquestación

• El enfoque actual mezcla el procesamiento de datos y la orquestación en una misma sesión de chat
• Algunas implementaciones crean otros hilos como "agentes" para esto, pero cuando el JSON ya está estructurado, resulta ineficiente
• Una mejor forma es procesar directamente los datos estructurados con código
  • Ejemplo: para ordenar issues, en vez de que el LLM genere la salida, el código ejecuta sort y devuelve solo el arreglo resultante

Procesamiento de datos basado en ejecución de código

• El cómputo de IA mediante ejecución de código ya se utiliza en varios intérpretes de IA
• Este enfoque permite una estructura simple donde el LLM no produce directamente los datos, sino que solo decide cómo usar las herramientas

Conceptos principales

• Uso de variables como memoria: asignar valores = guardar, imprimir = consultar, pasar como argumentos al llamar funciones
• Soporte para encadenamiento de funciones: combinar varias llamadas de función en paralelo o en secuencia, expresando las dependencias mediante el flujo natural del código
• Procesamiento escalable de grandes volúmenes de datos: combinado con NumPy, pandas, etc., permite manejar fácilmente miles o decenas de miles de registros
• También permite llamar a otros LLM: dentro del código escrito por el LLM se puede invocar a otro LLM para procesar datos no estructurados

¿Está MCP preparado?

• La especificación MCP ya define un esquema de entrada, y recientemente también se presentó un PR de esquema de salida
• Si los esquemas de salida se vuelven universales, será posible usarlos en escenarios como:
  • panel de estado de issues
  • reporte semanal de tickets completados
  • monitoreo y notificaciones automáticas de tickets estancados por parte de la IA

Retos del entorno de ejecución de código

• La seguridad es el problema clave: como se ejecuta código generado por IA o usuarios, se necesita un diseño que evite exponer claves API y datos
• En el caso de Lutra, el entorno de ejecución se construye con un enfoque de sandbox, y al modelo solo se le proporciona la documentación para llamar APIs
• Los entornos de ejecución con estado (como Jupyter) son costosos, y para sesiones largas se necesitan características stateless + persistent
• Esto está formando una nueva categoría de runtime de IA, cuyo diseño todavía sigue evolucionando activamente

Conclusión

• El enfoque tradicional de meter en el LLM los resultados de llamadas a herramientas para que los procese tiene límites en costo y precisión
• La orquestación basada en código permite un procesamiento simple, preciso y escalable
• Los entornos de ejecución de código para IA están atrayendo atención como runtimes de nueva generación con seguridad, persistencia y escalabilidad

[GN⁺]

Opiniones de Hacker News

• Comparte la experiencia de haber sostenido durante los últimos 2 años que "un agente suficientemente sofisticado es indistinguible de un DSL". Opina que, en vez de exigir que el agente internalice algoritmos, es mucho más adecuado enseñarle APIs, pedirle que diseñe algoritmos usando esas APIs y ejecutarlos en espacio de usuario. Considera que meter algoritmos dentro del LLM es ineficiente salvo en casos muy puntuales, por costo o precisión. Lo compara con pedirle a un desarrollador que ejecute llamadas a funciones en su cabeza
  • Lo interpreta como evidencia de que el camino hacia la ASI (inteligencia artificial general) no está en expandir las capacidades del LLM, sino en extraer y compilar desde fuera algoritmos de auto-mejora en forma de aplicaciones simbólicas
  • Pide fundamentos o ejemplos que demuestren que viene usando ampliamente el término 'agent' en este contexto desde hace 2 años
• Experiencia construyendo directamente sistemas agentic en su negocio de ecommerce. Evaluó smolagents y, aunque le parece elegante y atractivo, tiene la desventaja de aumentar mucho la complejidad del sistema. Es perfecto para entornos como reporteo dinámico, donde se ordenan y agregan datos sin esquema, pero para la mayoría de las tareas es excesivo. Gemini y OpenAI ofrecen funciones de intérprete de Python que pueden cubrir buena parte del trabajo de los agentes de código. No recomienda el enfoque de ir apilando indefinidamente mensajes de llamadas a herramientas, porque escala mal. Los workflows agentic reales tienen vida corta y gestionan la complejidad con estructura y disciplina. La lección del desarrollo de software tradicional —cómo escalar llamadas a funciones y evitar el caos— sigue siendo la misma. La clave para construir buenos sistemas está en manejar la carga cognitiva del desarrollador, y las soluciones simples pero suficientemente funcionales superan a los enfoques sofisticados aunque rindan bien. La combinación de llamadas a funciones es un ejemplo de estas soluciones simples, y el procesamiento de datos estructurados también puede resolverse con métodos tradicionales de parsing y transformación. Cuando la estructura es desconocida, incluso modelos baratos muestran gran desempeño para parsear. En última instancia, gestionar la complejidad de sistemas agentic se resume en administrar con cuidado el estado de la aplicación. Manipulando la pila de mensajes se puede componer con flexibilidad el contexto activo que se entrega al modelo, algo similar a la gestión de memoria en entornos restringidos
  • Un resumen que identifica con precisión los trade-offs de los sistemas agentic. También enfrentaron el mismo problema al construir una solución de búsqueda conversacional de productos para ecommerce (IsarTech). La combinación de funciones y los datos estructurados son clave para controlar la complejidad. Según su experiencia, los outputs basados en esquemas de tipos claros elevan de forma real la escalabilidad de las llamadas a herramientas. Gracias a esos esquemas, se pueden manejar tanto la carga cognitiva como la complejidad del sistema. Conviene depender de comportamientos deterministas siempre que sea posible y usar LLM solo cuando hay datos sin esquema o ambigüedad. Los LLM son muy eficaces para mapear solicitudes ambiguas hacia sistemas deterministas. Aun así, hace falta equilibrar la reducción de complejidad en entradas de alta entropía (no estructuradas) con el aumento de complejidad que producen las cadenas de llamadas a herramientas. En entornos reales de comercio es difícil usar un solo enfoque, y los outputs estructurados tienen límites cuando la intención es ambigua, así que hacen falta estrategias adicionales
• Señalan que el problema no es la llamada a funciones en sí, sino el diseño y la forma de uso de MCP. La mayoría de los MCP son copias de APIs y presentan el problema de expulsar datos inútiles. Al anidar repetidamente formato JSON, consumen contexto de entrada de manera innecesaria y contienen mucha información irrelevante. Hace falta optimizar con aplanado de datos y eliminación de campos innecesarios. Al final, el SaaS de MCP no es más que una API gateway. Hoy por hoy, MCP es uno de los principales generadores de ruido y no está lo bastante optimizado
  • GraphQL es justamente una tecnología optimizada para este propósito. Fue diseñada para permitir seleccionar solo los campos necesarios. Desarrolló un gateway open source que convierte varias queries de GraphQL en un solo servidor MCP
  • Plantea la duda de si el problema no será que el modelo no sigue bien esquemas JSON complejos
  • MCP no ayuda, pero filtrar todo tampoco es necesariamente lo mejor. A veces el agente necesita procesar grandes volúmenes de datos. En esos casos, ejecutar código con una evaluación simple de datos y una descripción del esquema es un enfoque más escalable. Claro, si el sistema crece demasiado, aparecen problemas similares. La solución definitiva sería reproducir en código la precisión del pensamiento determinista humano y estructurar el sistema para que el LLM invoque ese mecanismo de decisión. En teoría suena fácil, pero enfatiza que en la práctica es muy difícil de implementar
  • Al probar en ChatGPT una tarea de invertir cadenas, sintió que era muy difícil lograr que el LLM diera solo un resultado simple y además la confiabilidad era baja. Después de esa experiencia, adoptó la costumbre de validar siempre con varios LLM. Bromea con que, a este ritmo, quizá tenga que montar su propio datacenter con GPU para contar caracteres dentro de una cadena simple
• El equipo de Shopify publicó recientemente Roast como open source. Es una herramienta que permite insertar tareas no deterministas de LLM dentro de workflows para automatizar grandes codebases. Es esencial para automatizar tareas complejas
  • Quedó muy impresionado con Roast. Destaca mucho la armonía entre determinismo y no determinismo. Le genera algo de confusión cómo el LLM puede orquestar múltiples llamadas a herramientas y decidir el orden de invocación. Parece funcionar cuando se le dan instrucciones de refactorización, pero le queda la duda de si sirve para tareas compuestas como "mejorar → probar repetidamente"
  • Le resulta refrescante ver que Ruby sigue funcionando de forma consistente y significativa incluso en la era de la IA
  • Es un enfoque excelente que resulta intelectualmente estimulante incluso leyendo solo la documentación. Le impresionó cómo empaqueta de forma declarativa las capacidades del LLM
  • Pide ejemplos concretos de cómo se usan realmente estos workflows dentro de Shopify
  • Dice haber logrado hacer crashear tanto Claude Code Research Preview como ChatGPT 4.5 Pro Deep Research (y tiene pruebas), y está buscando una herramienta que funcione de manera confiable
• La mejor respuesta no está en un extremo, sino en un híbrido. Cree que lo mejor es resolver tanto como se pueda con enfoques deterministas y usar LLM en las partes complejas donde especificar o aplicar técnicas deterministas resulta difícil
  • Le parece interesante el enfoque de usar LLM para generar soluciones deterministas (código) y, una vez verificado ese código, reutilizarlo desde entonces como código determinista
  • Sostiene que la meta debería ser minimizar el uso de LLM dentro del workflow
• Le sorprende que, tras haber estado fuera de la industria más de un año, este tipo de experimentos complejos se haya vuelto común
  • En realidad, todavía solo una minoría está experimentando con esto; no hay casos revolucionarios, aunque sí algunos útiles
  • También aparece la postura de que, si no se está haciendo este tipo de trabajo ahora, probablemente pronto se termine saliendo otra vez de la industria
  • Su trabajo diario ya está muy centrado en la automatización del diseño de agentes de IA basados en LLM. No fue una decisión buscada; simplemente terminó ocurriendo
• Se pregunta por qué usar LLM para ordenar datos estructurados
  • El objetivo principal es procesar datos más complejos, como construir dashboards, identificar automáticamente tickets de incidencias o hacer revisiones trimestrales. Ordenar es solo un ejemplo simple, una forma menor de mostrar el tamaño del problema de manera fácil de entender
• huggingface smolagent es un caso representativo de este enfoque, pero trae el problema de que, cuando la ejecución falla, hacer rollback o recuperación se vuelve muy complicado. En teoría se puede resolver envolviendo todo el bloque de ejecución en una transacción distribuida, pero en la práctica el LLM intenta generar código robusto y termina chocando con ese patrón, lo que dificulta rastrear errores y entender la causa de las fallas
  • Coincide en que la idea base de smolagent es buena, pero el problema está en la realidad de la ejecución y el manejo de errores. Por ejemplo, le gustaría poder continuar directamente desde el estado en que quedó una ejecución interrumpida. Confirmó que el LLM puede escribir bien código de recuperación de estado, y comenta que actualmente esta función opera bastante bien en un producto real (Lutra)
• Como otro enfoque, propone hacer que el LLM escriba código que invoque MCP como si fueran funciones (en forma de scripts de Python). Comparte un ejemplo de código
  • Presenta Lutra.ai como un caso de uso real de este enfoque. La clave depende de qué tan bien esté diseñado el runtime de código
• Señala que los LLM son especialmente débiles con JSON, sobre todo JSON grande. No hay necesidad de que los endpoints devuelvan datos necesariamente en JSON; pueden usar otros formatos. Los LLM incluso muestran mucha más fortaleza con xml, y también es posible convertirlo en texto narrativo mediante plantillas
  • Resulta sorprendente que XML, siendo un formato con información semántica intrínseca, no se use más ampliamente como opción por defecto para LLM. Cuando hace falta, puede convertirse de forma determinista a JSON e incorporarse al pipeline con buenos resultados
  • Comenta que obtuvo resultados bastante buenos usando tablas Markdown para devolver datos al LLM
  • Se pregunta si el mejor rendimiento de XML se debe a que aparece con mayor frecuencia en los datos de entrenamiento de los LLM o a que tiene más tokens de texto. Menciona la posibilidad de que bloques de texto más extensos terminen dando más contexto al LLM para trabajar