El código como acción

El código como acción es la variante del agente en la que el modelo de lenguaje no pide las herramientas una a una, sino que escribe un programa que las llama, y el programa se ejecuta en un entorno aislado que devuelve al modelo solo lo que el programa imprime. La diferencia parece de formato y es de arquitectura. Un agente clásico, el del bucle ReAct, trabaja como alguien que dicta por teléfono: pide un dato, espera, lo recibe, pide el siguiente. Un agente que actúa con código trabaja como alguien que escribe un pequeño guion, lo ejecuta y lee el resultado. El nombre técnico del patrón, CodeAct, viene del artículo que Xingyao Wang y sus coautores publicaron en febrero de 2024, y la industria lo adoptó a finales de 2025 con otro nombre, ejecución de código sobre herramientas, cuando descubrió que era la solución a un problema de escala que las llamadas sueltas no podían resolver.

El formato habitual de una acción es un objeto JSON con el nombre de la herramienta y sus argumentos. Es fácil de validar y de registrar, y tiene dos limitaciones que Wang y sus coautores identificaron con precisión. La primera es que el espacio de acciones es estrecho: el modelo solo puede hacer exactamente lo que alguna herramienta hace, de una en una. La segunda es que no se pueden componer: si la tarea es consultar el precio de cinco productos, quedarse con el más barato y pedir su ficha, el agente necesita al menos seis turnos, y en cada uno el modelo tiene que leer lo anterior y decidir el siguiente paso. En un programa, eso es un bucle, un min y una llamada. El código tiene además todo lo que un lenguaje de programación trae de serie: variables para guardar resultados intermedios, condicionales, bucles, manejo de errores y miles de bibliotecas ya escritas. Y los modelos de lenguaje actuales se entrenan con cantidades enormes de código, de modo que escribir Python les resulta más natural que emitir un formato de llamada inventado por un proveedor.

Los autores lo midieron en diecisiete modelos y con un banco de pruebas propio, M3ToolEval, de ochenta y dos tareas que exigen combinar varias herramientas. El mejor modelo de la época resolvía el 74,4 por ciento de las tareas actuando con código, frente al 52,4 por ciento con llamadas JSON y el 53,7 por ciento con acciones en texto libre, y lo hacía en 5,5 turnos de media en lugar de 7,6. El resumen del artículo es prudente, hasta un 20 por ciento más de éxito y hasta un 30 por ciento menos de acciones. Lo más interesante está en la letra pequeña: en las tareas que se resolvían con una sola herramienta las dos formas de actuar quedaban muy parejas, y la ventaja se concentraba en las que obligaban a combinar varias.

La segunda razón para escribir código, la que ha hecho del patrón una práctica corriente, no tiene que ver con el acierto sino con el contexto. La figura lo muestra con una tarea sencilla. Cuando el agente consulta registros con llamadas sueltas, cada respuesta pasa por el modelo: entra en la conversación, se lee para decidir el siguiente paso y, como la conversación se reenvía entera en cada turno, se vuelve a leer en todos los turnos posteriores. Con doce consultas de mil quinientos tokens, el agente lee más de ciento cincuenta mil tokens para producir una suma. Cuando escribe un programa, las respuestas se quedan en el entorno de ejecución. El modelo solo ve el programa que escribió y las líneas que el programa imprime. Si lo que necesitaba era la suma, lee la suma.

Anthropic publicó en noviembre de 2025 el caso que convirtió esta aritmética en argumento. Un agente conectado a servicios externos mediante el protocolo MCP, el estándar abierto que la empresa había propuesto un año antes para que cualquier programa exponga herramientas a cualquier modelo, recibía el encargo de copiar la transcripción de una reunión de un documento de Google Drive a la ficha de un cliente en Salesforce. Por la vía de las llamadas sueltas, la transcripción entera pasaba dos veces por el modelo, una al leerla y otra al escribirla, además de las definiciones de todas las herramientas disponibles, cargadas de antemano. Presentando las herramientas como ficheros de código que el agente podía leer cuando las necesitaba y dejándole escribir el programa que movía el texto de un sitio a otro, el consumo pasaba de unos 150.000 tokens a unos 2.000, un ahorro del 98,7 por ciento. Tres semanas después la empresa lo incorporó a su interfaz con el nombre de llamada programática de herramientas, y en su propia evaluación con informes de gastos el consumo medio bajaba de 43.588 a 27.297 tokens, un 37 por ciento, con una pequeña mejora de acierto.

Conviene no confundir las dos cifras, porque dicen cosas distintas. El 98,7 por ciento es un caso escogido para ilustrar el mecanismo, en el que casi todo el coste eran datos que el modelo no necesitaba leer. El 37 por ciento es una media sobre una tarea menos favorable. La regla general se deduce de la figura: el ahorro es tanto mayor cuanto más grandes son los datos intermedios y cuantas más veces se consultan, y es nulo cuando el modelo tiene que leer de verdad lo que la herramienta devuelve, por ejemplo para juzgar la calidad de un texto. Un programa puede filtrar mil filas y quedarse con tres, pero no puede decidir si un párrafo está bien escrito sin enseñárselo a alguien.

El patrón trae además una consecuencia que no aparece en las cifras de tokens y que puede ser la más valiosa. Lo que el modelo no lee no puede filtrarse por el modelo. Si una herramienta devuelve la dirección y el teléfono de mil clientes y el programa solo necesita contar cuántos viven en Bilbao, esos datos pasan por el entorno de ejecución pero no por la conversación, ni por los registros del proveedor del modelo, ni por el razonamiento del agente. El propio artículo de Anthropic lo presenta como una ventaja de privacidad, y lo es, siempre que el entorno de ejecución esté bajo control de quien opera el sistema.

Ahí está también el precio. Ejecutar código escrito por un modelo exige un entorno aislado de verdad, con límites de memoria y de tiempo, sin acceso a credenciales que no necesite y sin salida libre a la red, y vigilado. Es infraestructura que una llamada JSON no necesita, y cuya ausencia convierte un agente eficiente en una puerta abierta: un programa que el modelo escribió después de leer una página web manipulada puede hacer todo lo que el entorno le permita. La discusión sobre la trifecta letal explica por qué esto no se arregla con instrucciones al modelo sino con permisos. La otra contrapartida es de depuración: una llamada JSON fallida es un objeto que se lee en un segundo, y un programa fallido de cuarenta líneas es un programa fallido.

La idea tiene un antecedente que ayuda a ver hacia dónde va. En 2023, el agente Voyager, que jugaba a Minecraft guiado por GPT-4, guardaba en una biblioteca cada programa que había funcionado, con una descripción, y los recuperaba y combinaba para tareas nuevas; sus autores atribuían a esa biblioteca de habilidades buena parte de su capacidad para progresar sin olvidar lo aprendido. Los agentes de programación actuales hacen lo mismo con otra forma: guardan en ficheros los programas y las instrucciones que les han servido y los cargan cuando hacen falta. La acción deja de ser un gesto que se repite y se convierte en código que se acumula, se revisa y se reutiliza, que es exactamente lo que el oficio de programar lleva setenta años haciendo con sus propias acciones.