Llamadas Avanzadas a Herramientas Que Redujeron los Costos de Mi Agente de IA a la Mitad

Estaba mirando mi dashboard de Langfuse a las 11 PM un jueves cuando noté algo que me hizo cerrar mi laptop y alejarme de mi escritorio. Una sola ejecución de agente -- una tarea, una consulta de usuario -- había quemado 76,000 tokens y hecho 56 llamadas separadas a herramientas. ¿La peor parte? Aún así obtuvo la respuesta equivocada. Se perdió dos miembros del equipo que habían excedido sus límites de presupuesto, y el cliente iba a ver ese reporte por la mañana.

Ese agente tenía acceso a 60 herramientas en dos servidores MCP. Cada una de esas definiciones de herramientas se cargaba en la ventana de contexto al inicio de cada conversación. Trece mil tokens desaparecidos antes de que el agente siquiera empezara a pensar en la tarea real. Había construido lo que pensé era un sistema capaz. Lo que realmente había construido era un horno de tokens con un problema de precisión.

La solución vino de dos funciones que había estado ignorando en la documentación de Anthropic durante semanas: búsqueda de herramientas y llamadas programáticas a herramientas. Lo que pasó después de implementarlas es la razón por la que estoy escribiendo este post. Pero la verdadera historia no es sobre ahorrar tokens -- es sobre un cambio fundamental en cómo pienso sobre la arquitectura de agentes.

El Problema del Que Nadie Habla Hasta Que Llega la Factura

Aquí está el escenario que la mayoría de los desarrolladores de agentes de IA conocen íntimamente, lo admitan o no. Empiezas a construir un agente. Necesita leer archivos, consultar bases de datos, llamar APIs, quizás interactuar con GitHub o Slack. Cada capacidad significa otra herramienta. Tu primer prototipo tiene 8 herramientas y funciona de maravilla. Contexto limpio, respuestas rápidas, resultados precisos.

Luego llegan las solicitudes de funcionalidades. El agente necesita manejar programación de calendario. Agrega tres herramientas. Necesita crear tickets en Jira. Dos herramientas más. ¿Integración con Slack? Otras cinco. Antes de que te des cuenta, estás en 35, 40, 60 herramientas -- y tu agente ha desarrollado un trastorno de personalidad. Elige la herramienta equivocada la mitad del tiempo, alucina valores de parámetros y cuesta tres veces lo que presupuestaste.

Me estrellé con esta pared en un proyecto para un cliente que quería un agente de operaciones unificado. El agente necesitaba acceso a sus repos de GitHub, workspace de Notion, canales de Slack, calendario y una API de inventario personalizada. Sesenta herramientas en total cuando contabas todo de ambos servidores MCP.

Tres cosas me estaban matando:

Solo las definiciones de herramientas consumían aproximadamente 13,000 tokens por conversación. Eso es espacio de ventana de contexto que podría haberse usado para razonamiento real. En Claude 3.5 Sonnet, eso no es trivial -- y en conversaciones más largas, estaba rozando los límites de contexto antes de que el agente terminara su trabajo.

Las salidas intermedias de las llamadas secuenciales a herramientas estaban contaminando el contexto. Cuando el agente necesitaba verificar presupuestos de un equipo, llamaba "obtener miembros del equipo", luego llamaba "obtener gastos" para cada persona, luego llamaba "obtener presupuesto por nivel" para el rol de cada persona. Cada respuesta volcaba JSON crudo en el contexto. Para cuando llegaba al último miembro del equipo, los datos anteriores estaban siendo empujados fuera del rango de atención efectiva.

La precisión en la selección de herramientas se degradaba a medida que aumentaba la cantidad de herramientas. Con 60 definiciones de herramientas en el contexto, el modelo tenía que analizar todas cada vez que decidía qué herramienta usar. Imagina darle a alguien un menú de 60 páginas en un restaurante y esperar que ordene rápida y correctamente. Mismo problema.

Probé las soluciones obvias. Mejores descripciones de herramientas. Menos herramientas con más parámetros. Categorizar herramientas en grupos. Ninguna resolvió el problema fundamental: demasiadas definiciones cargándose demasiado temprano, y demasiados datos intermedios acumulándose demasiado rápido.

Entonces encontré las dos funciones que cambiaron todo sobre cómo construyo agentes.

Búsqueda de Herramientas: Cargando Lo Que Necesitas, Cuando Lo Necesitas

El concepto detrás de la búsqueda de herramientas es tan simple que es casi ofensivo que no se me ocurriera a mí mismo. En lugar de cargar las 60 definiciones de herramientas en el contexto al inicio, difieres la mayoría. El agente obtiene un pequeño conjunto de herramientas esenciales más una herramienta especial: la herramienta de búsqueda de herramientas en sí. Cuando el agente necesita una capacidad que no tiene actualmente, busca la herramienta correcta por palabra clave o nombre, carga solo el esquema de esa herramienta y procede.

Las matemáticas son convincentes. Mi configuración de 60 herramientas consumía alrededor de 13,000 tokens en definiciones de herramientas. Después de implementar la búsqueda de herramientas y cargar solo 12 herramientas esenciales por adelantado, ese número cayó a 6,300 tokens. Casi la mitad de la sobrecarga de definiciones, eliminada.

Pero el ahorro de tokens ni siquiera fue la mejora más importante. La precisión en la selección de herramientas subió dramáticamente. Cuando el agente solo tiene 12 herramientas en contexto en lugar de 60, elige la correcta más consistentemente. Es la misma razón por la que un artesano enfocado con 5 herramientas en el banco trabaja más precisamente que uno rodeado de 50 -- menos ruido, mejor señal.

Así es cómo se ve el flujo de trabajo en la práctica. Digamos que el agente necesita listar commits recientes de un repositorio de GitHub. Con el enfoque tradicional, las herramientas de GitHub MCP ya están cargadas -- las 35, consumiendo alrededor de 26,000 tokens (aunque las versiones más nuevas de MCP han reducido esto a aproximadamente 4,000 tokens, lo cual es una mejora masiva de la que hablaré después). El agente tiene que escanear cada una para encontrar la herramienta correcta, luego descifrar los parámetros correctos.

Con la búsqueda de herramientas, esas herramientas de GitHub no están cargadas en absoluto. El agente reconoce que necesita datos de commits, llama a la herramienta de búsqueda con una consulta como "list commits", obtiene la herramienta específica que necesita y carga solo ese esquema. Una herramienta. Unos pocos cientos de tokens. Y una vez que esa herramienta está cargada, permanece en contexto para cualquier llamada subsiguiente -- sin cargas repetidas, sin tokens desperdiciados.

Quiero ser específico sobre cómo funciona esto porque los detalles de implementación importan. La herramienta de búsqueda acepta una consulta por palabra clave o un nombre directo de herramienta. La búsqueda por palabra clave es difusa -- puedes buscar "slack message" y devolverá herramientas relevantes de Slack clasificadas por relevancia. La selección directa usa un prefijo "select:" cuando sabes exactamente qué herramienta quieres. Ambos enfoques cargan las herramientas devueltas inmediatamente, así que no hay un proceso de dos pasos de buscar y luego cargar por separado.

Algo que aprendí por las malas: necesitas pensar cuidadosamente sobre qué herramientas permanecen en el conjunto "siempre cargado" versus cuáles se difieren. Las herramientas que el agente usa en casi cada conversación deberían permanecer cargadas. Las herramientas que solo se necesitan para tareas específicas deberían diferirse. Equivocarse en esta división significa que tu agente pierde tiempo buscando herramientas comunes o aún carga demasiadas definiciones por adelantado.

Para mi agente de operaciones, mantuve herramientas core como lectura de archivos, llamadas básicas a APIs y la herramienta de búsqueda en sí en el conjunto siempre cargado. Todo lo demás -- operaciones de GitHub, mensajería de Slack, gestión de calendario, consultas de Notion -- fue diferido. El agente aprendió a buscarlas naturalmente, y el flujo de conversación apenas cambió desde la perspectiva del usuario.

Eso resolvió el problema de inflación de definiciones. Pero aún tenía el problema de salida intermedia -- todo ese JSON crudo de llamadas secuenciales a herramientas acumulándose en el contexto. Para eso, necesitaba la segunda función.

Llamadas Programáticas a Herramientas: Escribe Código, No Cadenas de Llamadas

Aquí es donde las cosas se ponen genuinamente interesantes y, honestamente, un poco alucinantes si has estado construyendo agentes de la manera tradicional.

La llamada estándar a herramientas funciona así: el LLM decide que necesita datos, hace una llamada a herramienta, recibe el resultado, lo procesa, decide que necesita más datos, hace otra llamada a herramienta, recibe ese resultado, y así sucesivamente. Cada llamada y cada respuesta vive en el contexto de la conversación. Para tareas simples con dos o tres llamadas, esto está bien. Para tareas complejas que requieren datos de docenas de fuentes, es un desastre.

Las llamadas programáticas a herramientas invierten el modelo. En lugar de hacer llamadas individuales a herramientas a través de la conversación, el agente genera un script de código -- Python, típicamente -- que maneja todo el flujo de trabajo programáticamente. El script se ejecuta en un entorno sandboxed, hace todas las llamadas necesarias a herramientas internamente, procesa los datos con lógica de código real y devuelve solo el resultado final al contexto de la conversación.

Déjame mostrarte la diferencia con un ejemplo concreto que realmente ocurrió en mi proyecto de cumplimiento presupuestario.

La tarea era directa: verificar si los gastos de algún miembro del equipo excedían su presupuesto autorizado para su nivel de rol. Tres herramientas estaban disponibles: obtener miembros del equipo (devuelve una lista de personas y sus roles), obtener gastos (devuelve datos de gasto para una persona específica) y obtener presupuesto por nivel (devuelve el techo de presupuesto autorizado para un rol).

Con la llamada tradicional a herramientas, el agente llamó "obtener miembros del equipo" primero. Obtuvo una lista de, digamos, 15 personas. Luego llamó "obtener gastos" para la persona uno. Obtuvo sus datos de gasto. Llamó "obtener presupuesto por nivel" para el rol de la persona uno. Comparó los números. Pasó a la persona dos. Llamó "obtener gastos". Llamó "obtener presupuesto por nivel". Y así sucesivamente. Cincuenta y seis llamadas a herramientas en total. Cada respuesta -- 15 registros de miembros del equipo, 15 reportes de gastos, 15 consultas de presupuesto -- estaba sentada en el contexto de la conversación, consumiendo tokens.

¿El resultado? Aproximadamente 76,000 tokens consumidos. Y el agente se perdió un miembro del equipo que había excedido su presupuesto, probablemente porque para cuando procesó las últimas personas, la atención a los datos anteriores se había degradado. La atención de la ventana de contexto no es uniforme -- los modelos prestan menos atención a la información en el medio de contextos largos, y mis llamadas secuenciales a herramientas habían creado exactamente las condiciones donde esa debilidad mordería.

Con las llamadas programáticas a herramientas, la misma tarea se veía completamente diferente. El agente analizó lo que necesitaba lograr, luego generó un script Python. El script llamó "obtener miembros del equipo" una vez, iteró a través de la lista programáticamente, llamó "obtener gastos" y "obtener presupuesto por nivel" para cada persona dentro de un bucle, comparó los valores en código y devolvió un resumen limpio de quién excedió su presupuesto y por cuánto.

Los números cuentan la historia. El uso de tokens cayó a entre 45,000 y 58,000 tokens a través de múltiples ejecuciones. Las llamadas a herramientas pasaron de 56 a entre 4 y 12. ¿Y la precisión? Perfecta. El código no tenía problemas de degradación de atención. Un bucle for procesa el decimoquinto elemento exactamente igual que el primero.

Debo ser honesto sobre algo, sin embargo. El enfoque programático no fue perfecto al primer intento cada vez. A través de mis ejecuciones de prueba, el agente a veces generaba código que tenía bugs en el primer intento. Un nombre de variable incorrecto, una verificación de null faltante, una suposición incorrecta de estructura de datos. El sandbox devolvía un error, y el agente analizaba el error, corregía el código e intentaba de nuevo. Este ciclo iterativo es parte del diseño, no un defecto. El desarrollo real de software funciona exactamente así -- escribe, ejecuta, depura, refina.

Algunas ejecuciones tomaron dos iteraciones, algunas tomaron cuatro. Pero incluso con la sobrecarga de iteración, el uso total de tokens y las llamadas a herramientas fueron sustancialmente menores que el enfoque tradicional. Y la precisión fue consistentemente mejor porque la lógica de comparación vivía en código real en lugar de en la memoria de trabajo del LLM.

Esa naturaleza iterativa es realmente una de las cosas que más aprecio de este enfoque. Refleja cómo trabajo como desarrollador. No escribo código perfecto al primer intento. Escribo algo razonable, lo pruebo, arreglo lo que se rompe e itero. Las llamadas programáticas a herramientas le dan al agente el mismo flujo de trabajo, y resulta que los LLMs son sorprendentemente buenos depurando su propio código generado cuando reciben mensajes de error claros del sandbox.

La Arquitectura de Sandbox Que Hace Esto Seguro

Ahora, si acabas de leer esa sección y tus instintos de seguridad se activaron, bien. Dejar que un agente de IA genere y ejecute código arbitrario es el tipo de cosa que mantiene despiertos a los ingenieros de seguridad por la noche. La arquitectura detrás de esta función es lo que la hace viable para uso en producción, y entenderla es esencial antes de implementar cualquier cosa.

El sistema usa contenedores Docker sandboxed. Cada ejecución de código se realiza dentro de un contenedor aislado sin acceso a internet. El script Python generado no puede alcanzar el mundo exterior, no puede acceder al sistema de archivos del host, no puede leer variables de entorno del host y no puede hacer nada que un script malicioso querría hacer.

Pero espera -- el script necesita llamar herramientas. Necesita alcanzar APIs. ¿Cómo lo hace sin acceso a internet?

Aquí es donde entra el puente de herramientas, y es una pieza de arquitectura inteligente. El sandbox tiene acceso a un solo endpoint: el servidor puente de herramientas ejecutándose en el host (o en un contenedor sidecar). Cuando el script Python dentro del sandbox necesita llamar una herramienta -- digamos, "obtener gastos" de un miembro del equipo -- hace una solicitud al puente de herramientas. El puente autentica la solicitud usando un ID de sesión, verifica que la llamada a herramienta está permitida, ejecuta la llamada real a la API en nombre del sandbox y devuelve el resultado.

La propiedad de seguridad crítica aquí es que el código del sandbox nunca ve credenciales de API, tokens o secretos. El puente de herramientas mantiene todo el material de autenticación. El sandbox solo conoce el endpoint del puente y su ID de sesión. Si el código generado fuera de alguna manera malicioso o se filtrara, ninguna credencial quedaría expuesta.

Configuré mi sandbox usando el repositorio de GitHub LLM sandbox, que abstrae la mayor parte de la complejidad de gestión de Docker. Soporta Python de serie y maneja el ciclo de vida del contenedor, la captura de salida y la limpieza. Para equipos ejecutando esto en producción, recomendaría fuertemente agregar GVisor encima del aislamiento estándar de Docker. Los contenedores Docker comparten el kernel del host, lo que significa que un exploit del kernel podría teóricamente escapar del sandbox. GVisor proporciona una capa adicional de aislamiento interceptando llamadas del sistema a través de su propio kernel en espacio de usuario, reduciendo significativamente esa superficie de ataque.

Algo que no aprecié hasta que lo construí: el enfoque de sandbox es agnóstico al lenguaje en principio. El repo de LLM sandbox soporta múltiples lenguajes, así que podrías hacer que tu agente genere JavaScript, Go o incluso scripts de shell dependiendo de la tarea. En la práctica, me he quedado con Python porque los LLMs generan el mejor código Python -- han visto la mayor cantidad de datos de entrenamiento en Python, y la sintaxis de Python hace más fácil para el modelo expresar lógica procedural.

Diseñando Herramientas Que No Desperdicien Tu Presupuesto de Contexto

La búsqueda de herramientas y las llamadas programáticas resuelven dos problemas principales: inflación de definiciones e inflación de salidas intermedias. Pero hay una tercera capa de optimización que casi pasé por alto, y marcó una diferencia mayor de la que esperaba: el diseño de herramientas en sí.

Cuando conecté por primera vez el servidor MCP de GitHub a mi agente, el conjunto completo de 35 herramientas consumía alrededor de 26,000 tokens en definiciones. Eso es absurdo. La versión más nueva del mismo servidor MCP entrega funcionalidad equivalente en aproximadamente 4,000 tokens. ¿La diferencia? Descripciones más ajustadas, parámetros consolidados y eliminación de variantes redundantes de herramientas.

Si estás construyendo herramientas personalizadas para tus agentes, cada token en tu definición de herramienta cuenta. Reduce las descripciones a la información esencial. Usa nombres de parámetros claros y concisos de los que el modelo pueda inferir el uso. Elimina campos que el agente raramente usa -- siempre puedes agregarlos de vuelta con la búsqueda de herramientas si se necesitan.

Y aquí hay un tip que mejoró dramáticamente la precisión de mi agente con el manejo de parámetros: incluye ejemplos de uso de herramientas. Proporcionar un solo ejemplo de uso correcto de herramienta -- mostrando los valores esperados para cada parámetro -- elevó mi precisión de parámetros de aproximadamente 72% a aproximadamente 90%. Eso no es una mejora menor. Es la diferencia entre un agente que mayormente funciona y uno que funciona de manera confiable.

Piensa en los ejemplos de uso de herramientas como prompting multi-shot para llamadas a herramientas. Cuando el modelo ve un ejemplo como {"date": "2026-01-15"}, entiende que el formato esperado es año-mes-día. Sin ese ejemplo, podría generar "January 15, 2026" o "01/15/2026" o "15-01-2026" -- todas representaciones válidas de fecha, pero solo una coincide con lo que la API espera. Un solo ejemplo elimina esa ambigüedad casi por completo.

Ahora trato la optimización de definiciones de herramientas como una tarea de ingeniería de primera clase, no como una ocurrencia tardía. Antes de agregar cualquier herramienta a un agente, pregunto: ¿Cuántos tokens consume esta definición? ¿Puedo hacer la descripción más corta sin perder claridad? ¿He incluido un ejemplo de uso? ¿Se puede diferir esta herramienta detrás de la búsqueda, o necesita estar siempre cargada?

Esas preguntas ahorran miles de tokens por conversación, lo cual se compone en dinero real a través de miles de ejecuciones de agentes.

Uniendo Todo: La Arquitectura Que Realmente Se Despliega

Aquí es donde ato los hilos, porque estas funciones no son interruptores independientes que activas. Funcionan mejor como capas en una arquitectura deliberada.

Capa 1: Búsqueda de herramientas para gestión de definiciones. Difiere todo lo que no se necesita en cada conversación. Mantén tu conjunto siempre cargado pequeño y enfocado. Deja que el agente descubra herramientas especializadas bajo demanda. Esto maneja la inflación de definiciones.

Capa 2: Llamadas programáticas a herramientas para flujos de trabajo complejos. Cualquier tarea que requiera iterar sobre datos, comparar valores de múltiples fuentes, o hacer más de cinco llamadas secuenciales a herramientas es candidata para ejecución programática. Envía esos flujos de trabajo al sandbox. Esto maneja la inflación de salidas intermedias y mejora la precisión para tareas pesadas en datos.

Capa 3: Ejemplos de uso de herramientas para precisión de parámetros. Cada herramienta que acepta formatos de parámetros no obvios -- fechas, enums, IDs, objetos anidados -- obtiene al menos un ejemplo de uso en su definición. Esto maneja el asesino silencioso de precisión que la mayoría de los desarrolladores ni siquiera miden.

Cuando apliqué las tres capas a mi agente de operaciones, los resultados fueron contundentes. Las conversaciones que solían consumir más de 80,000 tokens cayeron al rango de 35,000-50,000. Los conteos de llamadas a herramientas para tareas complejas pasaron de 40-60 a 5-15. Los errores de parámetros esencialmente desaparecieron. Y el agente comenzó a manejar tareas correctamente al primer intento que antes necesitaban intervención humana para completar.

Pero quiero ser claro sobre algo: esto no es gratis. Implementar la búsqueda de herramientas requiere repensar la organización de tus herramientas y decidir qué diferir. Las llamadas programáticas requieren configurar y mantener una infraestructura de sandbox. Los ejemplos de uso de herramientas requieren pruebas para encontrar los ejemplos correctos que realmente mejoran la precisión. Cada capa agrega complejidad de implementación.

Mi recomendación es agregarlas incrementalmente. Comienza con la búsqueda de herramientas si tienes más de 15-20 herramientas. Agrega llamadas programáticas cuando identifiques flujos de trabajo específicos donde las llamadas secuenciales a herramientas están causando problemas de precisión o costo. Agrega ejemplos de uso a cualquier herramienta donde estés viendo errores de parámetros en tus logs.

Lo Que Hice Mal y Lo Que Haría Diferente

Quiero compartir tres errores que cometí durante esta transición porque creo que son errores que la mayoría cometerá.

Primero, diferí demasiado agresivamente con la búsqueda de herramientas. Moví casi todo detrás de la búsqueda, incluyendo herramientas que el agente usaba en el 80% de las conversaciones. El resultado fue que la mayoría de las conversaciones empezaban con el agente buscando inmediatamente herramientas que casi siempre necesitaba. Aún funcionaba, pero el paso de búsqueda añadía latencia y una pequeña cantidad de tokens. Tuve que ajustar el conjunto siempre cargado durante aproximadamente dos semanas de monitoreo de patrones reales de uso para encontrar el punto óptimo.

Segundo, asumí que las llamadas programáticas siempre serían más baratas. Para tareas simples con dos o tres llamadas a herramientas, la sobrecarga de generar código, levantar un sandbox y ejecutar el script realmente cuesta más que simplemente hacer las llamadas directamente. Las llamadas programáticas brillan cuando el enfoque tradicional requeriría más de aproximadamente cinco llamadas secuenciales. Por debajo de ese umbral, el método tradicional es más simple y a menudo más barato.

Tercero, subestimé cuánto tiempo pasaría escribiendo buenos ejemplos de uso de herramientas. Un mal ejemplo es peor que ningún ejemplo porque puede engañar al modelo. Tenía una herramienta donde proporcioné un ejemplo con una fecha en formato "2025-12-01", pero la API realmente esperaba timestamps Unix. El modelo siguió fielmente mi ejemplo y envió fechas formateadas, que la API rechazaba cada vez. Probar tus ejemplos contra la API real es innegociable.

También hay una lección arquitectónica más amplia que sigo procesando. Estas funciones me empujaron a pensar en los agentes menos como chatbots que casualmente usan herramientas y más como sistemas de orquestación que casualmente usan LLMs. El trabajo del agente no es tener una conversación -- es descomponer una tarea, seleccionar la estrategia de ejecución correcta para cada subtarea y ensamblar resultados. La búsqueda de herramientas es sobre carga dinámica de capacidades. Las llamadas programáticas son sobre ejecución eficiente. Cuando lo enmarcar así, estas no son funciones específicas de Claude. Son patrones de diseño que aplican a cualquier framework de agentes.

Haciendo Que Esto Funcione Más Allá de Claude

Mencioné que estos son patrones de diseño, no solo funciones de Claude, y quiero ser específico sobre eso porque importa.

La búsqueda de herramientas es fundamentalmente un patrón de carga diferida. Si estás construyendo agentes en LangChain, CrewAI o cualquier framework personalizado, puedes implementar el mismo concepto. Mantén un registro de herramientas disponibles con metadatos ligeros. Dale a tu agente una función de "buscar herramientas" que consulte el registro por palabra clave. Carga esquemas de herramientas en el prompt solo cuando son seleccionados. Los detalles de implementación difieren, pero la arquitectura es portable.

Las llamadas programáticas a herramientas son un patrón de generación y ejecución de código. Cualquier framework de agentes puede extenderse para generar scripts Python, ejecutarlos en un sandbox y canalizar los resultados de vuelta. El enfoque de sandbox basado en Docker funciona independientemente de qué LLM estés usando. La arquitectura del puente de herramientas es agnóstica al modelo -- es solo un servidor HTTP que proxea llamadas API autenticadas.

Incluso los ejemplos de uso de herramientas son portables. Cada LLM se beneficia de ver valores de ejemplo para parámetros. Ya sea que estés usando Claude, GPT-4, Gemini o un modelo open-source, incluir ejemplos en las descripciones de tus herramientas mejora la precisión de parámetros. La mejora específica varía por modelo, pero la dirección es consistente.

He empezado a aplicar estos patrones a un proyecto paralelo que usa una mezcla de Claude y GPT-4o dependiendo de la complejidad de la tarea. La capa de búsqueda de herramientas funciona idénticamente para ambos modelos. El sandbox de llamadas programáticas no le importa qué modelo generó el código. La única pieza específica del modelo es ajustar las definiciones de herramientas para las fortalezas y debilidades particulares de cada modelo en generación de código.

Si estás atado a un framework o modelo específico, no descartes estas técnicas como "funciones solo de Anthropic". Extrae los patrones, adapta la implementación y aplícalos donde sea que estés construyendo agentes.

Los Números Después de 30 Días en Producción

He estado ejecutando la arquitectura de agente optimizada por aproximadamente un mes, y quiero compartir números reales de producción porque estoy cansado de posts de blog que muestran benchmarks seleccionados a dedo.

El uso promedio de tokens por conversación cayó un 42% comparado con la arquitectura anterior. Para el agente de operaciones específicamente, eso es aproximadamente $0.03 por conversación en lugar de $0.05. Con aproximadamente 200 conversaciones por día a través de todos los usuarios, eso ahorra alrededor de $4/día o aproximadamente $120/mes. No es dinero que cambie la vida, pero es una reducción del 42% que no requirió cambios en las capacidades del agente.

Los errores de llamadas a herramientas -- casos donde el agente llamó la herramienta equivocada o pasó parámetros inválidos -- cayeron de aproximadamente el 8% de las llamadas a menos del 2%. La mayoría de los errores restantes son casos extremos con nombres ambiguos de herramientas que sigo refinando.

La precisión de completación de tareas de extremo a extremo para el flujo de trabajo de cumplimiento presupuestario mejoró de aproximadamente 85% (el enfoque tradicional a veces perdía casos extremos) a 97% con llamadas programáticas. La tasa de fallo del 3% es casi enteramente por el sandbox alcanzando límites de timeout en conjuntos de datos inusualmente grandes, lo cual estoy abordando aumentando el timeout del contenedor.

La latencia percibida por el usuario realmente aumentó ligeramente para consultas simples -- aproximadamente 200ms de sobrecarga de búsqueda de herramientas en el primer uso. Para consultas complejas que antes requerían más de 30 llamadas secuenciales a herramientas, la latencia disminuyó significativamente porque el sandbox ejecuta llamadas a herramientas más rápido que el bucle de razonamiento serial del LLM.

Estos números no son hipotéticos. Son de trazas de Langfuse en un sistema de producción manejando consultas reales de usuarios. Tus números específicos dependerán de tu cantidad de herramientas, complejidad de tareas y patrones de conversación. Pero la mejora direccional debería ser similar para cualquiera lidiando con inflación de herramientas o sobrecarga de llamadas secuenciales.

La Pregunta Que Debería Mantenerte Construyendo

Hace seis meses, pensé que el camino hacia mejores agentes de IA era mejor prompting. Escribe instrucciones más claras, proporciona más contexto, usa system prompts más sofisticados. Y el prompting importa -- no lo estoy descartando. Pero el prompting solo no puede resolver problemas arquitectónicos. No puedes hacer prompt para salir de una sobrecarga de 13,000 tokens en definiciones de herramientas. No puedes hacer prompt hacia un procesamiento preciso de datos cuando los resultados intermedios están inundando tu ventana de contexto.

Las ganancias reales viven en la arquitectura de ejecución: cómo se cargan las herramientas, cómo fluyen los datos, cómo se ejecuta el código y cómo el agente decide entre estrategias. La búsqueda de herramientas, las llamadas programáticas y el diseño cuidadoso de herramientas son la primera generación de estas herramientas arquitectónicas. No serán las últimas.

La pregunta que sigo haciéndome -- y la que te desafío a considerar -- es esta: ¿Cómo se vería tu arquitectura de agente si la diseñaras para 500 herramientas en lugar de 50? Porque hacia ahí vamos. El ecosistema de servidores MCP, integraciones de API y herramientas personalizadas está creciendo rápido. Los agentes que prosperen no serán los que tengan los prompts más ingeniosos. Serán los que tengan arquitecturas que escalen elegantemente cuando la cantidad de herramientas se duplique, y luego se duplique de nuevo.

Comienza con las tres capas. Mide tu uso de tokens. Observa tus métricas de precisión. Y construye la base ahora, porque la complejidad solo va a subir desde aquí.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portafolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io