Explicación de la llamada a herramientas: cómo los modelos piden a los programas que actúen y dónde fallan.
Un recorrido práctico sobre la llamada a funciones y el uso de herramientas: el bucle de solicitudes, esquemas, herramientas de lectura frente a herramientas de acción, agentes, MCP, inyección de prompts, seguimiento y fallos comunes.
Fuentes: Function Calling and Tool Use: How AI Agents Automate Workflows
Los primeros chatbots eran máquinas para responder preguntas. Una persona escribía algo, llegaba una respuesta y el intercambio terminaba allí. Eran útiles, pero limitados. Un modelo podía describir cómo reservar un vuelo sin poder consultar las tarifas actuales. Podía explicar qué contiene una factura, pero nunca crear una en el sistema de facturación. Podía proponer un horario de reunión sin poder ver el calendario de nadie, y mucho menos agregar el evento a él.
La llamada a funciones elimina esa barrera. Un modelo de lenguaje obtiene la posibilidad de pedir ayuda al software circundante, y el resto de la estructura tecnológica se desarrolla a partir de esa única capacidad.
Un modelo que puede pedir cosas
Sin herramientas, un modelo responde con base en lo que absorbió durante su entrenamiento. Con ellas, puede concluir que una pregunta requiere ayuda externa y indicar qué herramienta debe proporcionarla: un servicio meteorológico, un índice de búsqueda, una consulta a una base de datos, una calculadora, un calendario, un flujo de pago, una búsqueda en un CRM, un intérprete de código o alguna función interna de la empresa. En lugar de adivinar, el modelo emite una solicitud estructurada, la aplicación la cumple y el modelo continúa trabajando con información más actual y precisa. Los grandes proveedores, como OpenAI, Anthropic y Google, junto con frameworks como LangChain, describen el uso de herramientas de manera similar: se ofrecen al modelo herramientas bien definidas, él decide cuándo invocarlas, pasa argumentos estructurados y integra los resultados obtenidos en su respuesta o acción.
Una imagen mental útil: el modelo es el cerebro de la conversación, y las herramientas son las manos, los ojos, la memoria, la calculadora, el archivador y la furgoneta de entrega. El cerebro determina qué quiere el usuario. Las herramientas realizan las tareas que la generación de texto en bruto no puede hacer de manera segura o fiable.
Llamada a función versus llamada a herramienta
Estas dos expresiones se usan de forma intercambiable, pero la segunda es más precisa, ya que la idea va más allá de las funciones tradicionales de programación. Una herramienta puede ser algo tan sencillo como get_weather(location). También podría tratarse de una búsqueda en una base de datos, una sesión en un navegador, la recuperación de documentos, una calculadora, una orden de shell, un proceso de diseño o un enlace a un servicio externo. En el vocabulario de OpenAI, una herramienta es una capacidad expuesta al modelo, y una llamada a herramienta es un tipo especial de respuesta del modelo que solicita el uso de una de ellas.
Es crucial saber que el modelo normalmente no ejecuta nada por sí mismo. En la configuración típica del lado del cliente, devuelve una solicitud estructurada, algo similar a una llamada a get_customer_profile con un customer_id de 12345. La aplicación la recibe, la examina, ejecuta la función real, recopila el resultado y lo devuelve al modelo, el cual luego escribe su respuesta final. La secuencia documentada es: proporcionar las herramientas disponibles, recibir una llamada a una herramienta, ejecutar el código en la propia aplicación, enviar el resultado y recibir ya sea una respuesta final o nuevas llamadas a herramientas.
Existen excepciones. Algunos proveedores también alojan herramientas del lado del servidor que se ejecutan en su infraestructura. Anthropic separa claramente estas dos categorías: las herramientas del cliente son ejecutadas por su aplicación y se presentan como bloques estructurados de uso de herramientas, mientras que las herramientas del servidor, como la búsqueda en la web o la ejecución de código, pueden ejecutarse en el lado de Anthropic.
La distinción tiene importancia. Decir “el modelo llamó a una API” podría significar que el modelo generó una solicitud para que su software la ejecutara, o bien que la plataforma utilizó una herramienta integrada en nombre del modelo. En entornos de producción, esto afecta la postura de seguridad, el registro de actividades, los costos, la forma en que se manejan los datos, quién aprueba qué y quién es responsable cuando ocurre algún problema.
El ciclo en cinco pasos
La mayoría de los sistemas de llamada a funciones repiten un mismo ciclo.
- Defina las herramientas. Cada herramienta recibe un nombre, una descripción y una lista de entradas esperadas. Una herramienta meteorológica puede necesitar una ciudad y un país. Una herramienta de reembolso puede requerir un ID de pedido, un motivo y una cantidad máxima. Una herramienta de programación puede necesitar asistentes, una fecha, una hora y un tema. Los ejemplos de OpenAI describen los parámetros en un estilo JSON Schema con campos obligatorios y restricciones como additionalProperties establecido en false, mientras que la documentación de Gemini de Google muestra declaraciones de función construidas a partir de nombres, descripciones y estructuras de entrada.
- El usuario solicita algo. El modelo lee la solicitud y determina si puede responder de inmediato. “Explique qué es la llamada a función” probablemente no necesita ninguna herramienta. “¿Cuál es el estado del pedido 8472?” casi con certeza sí la necesita.
El ciclo puede ejecutarse una vez o repetirse muchas veces. Un agente puede buscar, comparar resultados, llamar a otra herramienta, hacer una consulta adicional, actualizar un registro y, finalmente, resumir lo que ha hecho.
El lenguaje como interfaz
La verdadera ventaja del uso de herramientas es que el lenguaje cotidiano se convierte en una interfaz flexible para el software.
Tradicionalmente, cada función necesita sus propios botones, formularios, menús y flujos. Con la llamada a funciones, un usuario puede expresar directamente su intención: localizar la factura más reciente de Acme, verificar si el pago ha llegado y, de no ser así, enviar un correo electrónico de recordatorio cortés. Una sola oración oculta varias herramientas: una búsqueda en el CRM, la obtención de una factura, la verificación del estado de pago, un borrador de correo electrónico y, quizás, una solicitud de aprobación antes de enviar cualquier cosa.
Un buen diseño de producto no es algo opcional. Lo que cambia es el punto de inicio de la interfaz. En lugar de hacer que las personas aprendan la estructura del software, este se adapta a la forma en que ya hablan sobre su trabajo.
Esto otorga una gran importancia a las descripciones de las herramientas. Una descripción vaga deja al modelo sin saber cómo utilizarla. Una descripción clara indica cuándo recurrir a ella, qué hace, qué significa cada entrada y qué no se debe asumir. La documentación de LangChain presenta las herramientas como funciones con entradas y salidas bien especificadas, y señala que los comentarios de tipo y las descripciones breves ayudan al modelo a utilizarlas correctamente.
Una buena herramienta es más que una función: es un contrato.
Cuatro términos que se superponen
La gente confunde estas palabras, aunque pertenecen a niveles diferentes.
- Llamada a funciones es el mecanismo: el modelo solicita la invocación de una función o herramienta estructurada.
- Uso de herramientas es la capacidad más amplia. Incluye las llamadas a funciones, herramientas integradas, búsquedas en la web, búsquedas de archivos, ejecución de código, control de computadoras, servidores remotos y cualquier otro método mediante el cual un modelo puede interactuar con sistemas externos.
- Un agente es un sistema que combina el uso de herramientas en varias etapas para alcanzar un objetivo. OpenAI describe a los agentes como aplicaciones que planifican, utilizan herramientas, trabajan con especialistas y monitorean el progreso en tareas de múltiples pasos; su Agents SDK define a un agente como un LLM configurado con instrucciones, herramientas y elementos opcionales como transferencias de tarea, restricciones y salidas estructuradas.
Dicho de otra manera: la llamada a funciones es el conector, las herramientas son los aparatos conectados, los agentes deciden cómo y cuándo usarlos, y la automatización hace que todo funcione como parte de un sistema dinámico.
¿Por qué molestarse?
Los modelos de lenguaje son buenos para comprender, combinar y comunicar información. Son una mala alternativa a las calculadoras, las bases de datos o los monitores en tiempo real. Pueden escribir sobre el clima, pero no pueden conocer el pronóstico de hoy a menos que estén conectados a esos datos. Pueden discutir una factura, pero no pueden acceder a su sistema de facturación a menos que esté conectado. Pueden explicar código, pero no pueden determinar si su servicio está caído sin datos de monitoreo.
Las herramientas cierran esas brechas. Una calculadora hace que los cálculos aritméticos sean fiables. Las búsquedas proporcionan hechos actualizados. La recuperación de información basa las respuestas en documentos privados. Una herramienta de base de datos responde a preguntas sobre los registros de la empresa. Una herramienta de flujo de trabajo crea tickets, envía mensajes, actualiza pedidos o reserva citas. La documentación de Gemini de Google resume los beneficios en tres puntos: agregar conocimiento, ampliar capacidades y actuar a través de sistemas externos.
Este es el punto en el que la experiencia deja de parecerse a una conversación y comienza a parecerse a un software. El modelo ya no solo genera palabras; también ayuda a coordinar el trabajo.
Investigación detrás de la idea
Los agentes que utilizan herramientas no aparecieron de la nada. Cuatro estudios anteriores dieron forma a este campo.
- MRKL Systems (2022) propuso un diseño modular que conecta los modelos de lenguaje con módulos externos de conocimiento y razonamiento. La idea central era sencilla: no pedirle a un solo modelo que haga todo; asignar cada tarea a un componente especializado.
- ReAct (2022) analizó cómo los modelos pueden combinar el razonamiento con la acción. En lugar de limitarse a pensar o a actuar solamente, la técnica de estimulación al estilo ReAct hace que el modelo razoné, actúe, observe el resultado y modifique su plan. Este ciclo mejora el rendimiento en tareas de respuesta a preguntas y toma de decisiones, además de facilitar la comprensión del comportamiento del modelo.
- Toolformer (2023) probó si un modelo podía aprender por sí mismo a utilizar herramientas a través de APIs simples. Aprendió cuándo era necesario recurrir a una herramienta, qué enviar y cómo utilizar su resultado, tomando como ejemplos calculadoras, motores de búsqueda, traductores y calendarios.
- Gorilla (2023) abordó el problema de las llamadas a APIs a gran escala y una molestia práctica: con tantas herramientas disponibles, los modelos a veces inventan llamadas o proporcionan argumentos incorrectos. Gorilla combinó el entrenamiento con la recuperación de información para que el sistema pudiera seguir la documentación de las APIs en constante cambio y cometer menos errores.
Todo esto converge en una idea: los mejores sistemas de IA no son modelos aislados. Son partes de sistemas más grandes conectados a herramientas, memoria, reglas, software y supervisión humana.
Qué aspecto tiene una buena herramienta
Las herramientas sólidas son específicas, comprensibles y seguras.
Las herramientas específicas son más fáciles de elegir para los modelos y de controlar para los desarrolladores. Una herramienta llamada update_everything es vaga y peligrosa. create_refund_request es más clara. approve_refund requiere aún más precaución, ya que afecta al mundo real.
Las herramientas comprensibles tienen nombres y descripciones sencillas. Un modelo no debería tener que adivinar si fetch_record significa obtener un perfil de cliente, descargar un archivo o recuperar un historial médico. La descripción debe indicar su propósito, las situaciones en las que se utiliza, el significado de cada argumento y la forma del valor devuelto.
Las herramientas seguras vienen con límites integrados. Verifican los permisos, validan la entrada y evitan otorgar acceso que no sea necesario. Reportan errores claros, mantienen registros y solicitan la aprobación humana antes de realizar acciones sensibles. Nunca le otorgan al modelo más poder del que requiere la tarea.
OpenAI recomienda esquemas estrictos para que los argumentos lleguen de manera fiable, y su Agents SDK orienta a los desarrolladores hacia medidas de control, revisión humana, resultados claros, gestión de estado y capacidad de observación a medida que los flujos de trabajo crecen. En la práctica, las mejores herramientas son aburridas: cada una hace bien una sola tarea y no sorprende a nadie, ya sea al desarrollador, al modelo o al usuario.
Los esquemas como gramática
Un esquema es la gramática del uso de las herramientas. Cuando el modelo llama a una función, debe proporcionar los argumentos en un formato que la aplicación pueda entender. El esquema determina qué campos existen, sus tipos, cuáles son obligatorios y, a veces, qué valores están permitidos. Una herramienta meteorológica podría exigir una ubicación en formato de cadena y un campo de unidades limitado a grados Celsius o Fahrenheit.
Los esquemas estrictos reducen la ambigüedad y simplifican la validación. La documentación de OpenAI explica que el modo estricto mantiene las llamadas fieles al esquema declarado, y exige restricciones como que additionalProperties esté establecido en false para cada campo marcado como requerido, utilizando tipos nulables para expresar valores opcionales.
No obstante, un esquema no hace que un sistema sea seguro. Una solicitud con formato impecable puede seguir siendo mala. Una llamada a send_email dirigida a all_customers@example.com puede cumplir perfectamente con el esquema y, aun así, ser una idea terrible. Por lo tanto, la validación de esquemas debe ir acompañada de reglas de negocio, autorización, límites de frecuencia, pasos de revisión y monitoreo.
Leer versus actuar
Una decisión de diseño importante es determinar si una herramienta solo lee o también actúa.
Las herramientas de solo lectura obtienen información: buscan documentos, consultan registros, verifican inventarios, obtienen datos meteorológicos, calculan totales e inspeccionan registros. Aún así pueden exponer datos sensibles y necesitan control de acceso, pero por lo general no modifican nada.
Las herramientas de acción realizan tareas concretas. Envían correos electrónicos, realizan pedidos, cancelan suscripciones, emiten reembolsos, actualizan bases de datos, abren tickets, despliegan código o programan reuniones. Los errores con ellas tienen consecuencias reales.
Un agente bien diseñado trata estos dos tipos de herramientas de manera diferente. Las herramientas de solo lectura pueden usarse con mayor libertad, pero siempre bajo verificaciones de permisos. Las herramientas de acción generalmente requieren controles más estrictos: pantallas de confirmación, pasos de aprobación, límites de transacciones, registros de auditoría, opciones de deshacer cambios y mensajes claros para el usuario.
En este punto, la automatización se convierte en una cuestión de gestión y no solo técnica. El problema no radica en si el modelo puede llamar a la función, sino en qué condiciones se debe permitir que cualquier sistema realice la acción en nombre de una persona.
De llamadas individuales a agentes
Una sola llamada a una herramienta puede responder a una pregunta simple. Los agentes existen para tareas más largas y complejas. Si se le pide a un agente que prepare un resumen semanal de ventas y señale las cuentas que requieren atención, es posible que tenga que obtener datos de ventas, compararlos con semanas anteriores, identificar patrones inusuales, leer notas del CRM, redactar el resumen y enviarlo a un gerente. Eso constituye una cadena de decisiones, no una sola llamada.
Los frameworks de agentes gestionan toda la cadena de procesos. Almacenan el estado, ejecutan herramientas, intentan nuevamente los pasos fallidos, transfieren tareas entre agentes especializados, generan resultados estructurados, imponen restricciones y mantienen registros. La documentación del SDK de Agents de OpenAI describe dos formas comunes: un patrón de gestor en el que un agente central llama a agentes especializados como si fueran herramientas, y procesos de transferencia en los que un agente cede el control a un especialista.
Sí, son poderosos, pero no algo que deba idealizarse. Un agente no es un empleado menor que opera dentro de tu software; es un sistema probabilístico construido a partir de código, y necesita responsabilidades definidas, permisos limitados, casos de prueba, monitoreo, vías de escalada y planes para situaciones de fallo. Cuanta más libertad tenga un agente, más cuidadoso debe ser el diseño técnico que lo rodea.
Donde la automatización se encuentra con el trabajo real
La automatización es la etapa en la que el uso de herramientas se convierte en operaciones reales.
- Un equipo de soporte puede utilizar a un agente para clasificar los tickets, buscar documentos de políticas relevantes, redactar respuestas y proponer pasos siguientes.
- Un equipo financiero puede conciliar facturas, localizar órdenes de compra faltantes y preparar informes de excepciones.
- Un equipo de ingeniería puede examinar pruebas fallidas, buscar registros, proponer soluciones y abrir solicitudes de integración.
- Un equipo de ventas puede enriquecer información de potenciales clientes, preparar notas de llamadas y actualizar el CRM.
La automatización más eficaz no parte de lo que puede hacer el modelo, sino de un flujo de trabajo existente. ¿Dónde comienza el trabajo? ¿Qué información se necesita? ¿Cuáles decisiones son rutinarias y cuáles son sensibles? ¿Dónde revisan, aprueban o corrigen las personas actualmente? ¿Qué errores resultarían molestos y cuáles serían costosos?
Con esas respuestas en mano, las herramientas ayudan a que el proceso fluya de manera más fluida. El agente recopila datos, completa formularios, redacta mensajes, compara registros y hace recomendaciones, mientras las personas siguen involucradas en aquellos casos en los que sea necesario tomar decisiones, asumir responsabilidades o generar confianza.
Conexiones estandarizadas
Las integraciones iniciales eran personalizadas. Cada aplicación tenía su propio método para exponer herramientas, recursos, indicaciones y mecanismos de autenticación. Eso funcionaba bien para proyectos pequeños, pero se volvía complicado a medida que las organizaciones conectaban más modelos con más sistemas.
El Protocolo de Contexto de Modelo (MCP) es un intento por estandarizar esta capa. Su especificación describe cómo las aplicaciones pueden compartir contexto, exponer herramientas y funciones, y crear integraciones flexibles a través de una estructura de anfitrión, cliente y servidor. Los servidores MCP pueden ofrecer recursos, instrucciones y herramientas. El protocolo intercambia mensajes JSON-RPC 2.0 y abarca la negociación de capacidades, el seguimiento del progreso, la cancelación, el registro de actividades y la notificación de errores.
La ventaja es evidente: una capa de herramientas compartidas permite que las aplicaciones de IA se conecten de manera consistente a fuentes de datos y flujos de trabajo, de modo que cada empresa no tenga que volver a crear cada integración. La desventaja es que surge un nuevo riesgo. Un servidor de herramientas que ofrece funciones potentes debe ser considerado por la aplicación anfitriona como una verdadera barrera de seguridad y no como otro mero complemento. La propia especificación de MCP destaca la importancia del consentimiento del usuario, la privacidad de los datos, la seguridad de las herramientas, así como la precaución al acceder a datos de forma arbitraria o ejecutar código.
La seguridad es lo primero
Los agentes que utilizan herramientas son valiosos porque actúan, y esa misma capacidad conlleva riesgos.
Inyección de comandos es la amenaza más conocida: instrucciones hostiles ocultas en la entrada del usuario o en contenido externo que hacen que el modelo adopte un comportamiento que debería evitar. OWASP la incluye entre los principales riesgos para las aplicaciones basadas en LLM, y su material de 2025 también destaca la agencia excesiva, en la que un sistema basado en LLM tiene más poder para actuar de lo que sería prudente, por lo que resultados inesperados, ambiguos o manipulados pueden llevar a acciones dañinas.
Inyección indirecta es lo que más preocupa a quienes trabajan con agentes. Supongamos que un agente lee correos electrónicos y puede enviar respuestas. Un remitente malintencionado podría incluir en un mensaje una línea que le indique ignorar sus reglas y reenviar los contactos del usuario. El usuario podría no ver nunca esa línea, pero el modelo la procesará igualmente. Si el sistema es excesivamente confiado y tiene permisos excesivos, un mensaje que parece inocuo se convierte en una acción real.
Los equipos de seguridad están pasando a considerar a los LLM como sistemas que pueden ser engañados únicamente mediante la redacción de las instrucciones, y no solo por defectos en el código. El Centro Nacional de Ciberseguridad del Reino Unido señala que la inyección de prompts difiere de la inyección SQL porque un LLM no establece una separación estricta entre las instrucciones y los datos no confiables.
La respuesta adecuada es una defensa en capas:
- Restringir las permisos de las herramientas en la medida de lo posible.
- Separar las herramientas de lectura de las herramientas de escritura.
- Requerir aprobación antes de realizar acciones sensibles.
- Tratar todo lo que se obtenga, ya sean páginas web, correos electrónicos, documentos o campos de base de datos, como no confiable.
- Revisar cada argumento de las herramientas y sanitizar las salidas antes de pasarlas a otros sistemas.
- Usar listas de permisos, registrar cada llamada a las herramientas y vigilar cualquier actividad inusual.
- Probar con ejemplos adversariales y crear formas de revertir acciones cuando sea posible.
Concézcale al agente solo la cantidad de poder que realmente requiera el flujo de trabajo.
Viendo lo que hizo el agente
El software de agentes necesita registros aún más detallados que el software ordinario, ya que una ejecución puede incluir razonamiento de modelos, llamadas a herramientas, transferencias de tareas, verificaciones de restricciones, intentos repetidos y un resultado final. El seguimiento permite a los desarrolladores rastrear todo el proceso desde la solicitud hasta el resultado. Según la documentación de seguimiento del SDK de Agents de OpenAI, los registros pueden capturar generaciones de modelos de lenguaje grande, llamadas a herramientas, transferencias de tareas, restricciones y eventos personalizados, lo que ayuda a los equipos a depurar, visualizar y monitorear los flujos de trabajo en desarrollo y en producción.
Eso es importante tanto para la calidad como para la seguridad. Cuando un agente da una respuesta incorrecta, hay que encontrar la causa. ¿Elegió la herramienta equivocada? ¿La herramienta devolvió datos obsoletos? ¿El modelo interpretó mal la descripción? ¿Falla algún mecanismo de control? ¿Al usuario le faltan permisos? ¿El agente se detuvo demasiado pronto? Sin rastros, los equipos solo pueden adivinar. Con una buena capacidad de observabilidad, desarrollar agentes se convierte en una verdadera práctica de ingeniería.
Cómo suelen fallar estos sistemas
Las fallas son predecibles. Por parte del modelo, puede elegir la herramienta incorrecta cuando los nombres o descripciones no son claros, enviar argumentos incompletos o incorrectos, llamar a una herramienta cuando debería hacer una pregunta de aclaración, o omitir una llamada cuando se necesitan datos actualizados. También puede llamar a las herramientas con demasiada frecuencia, lo que aumenta los costos y la latencia, quedar atrapado en llamadas repetidas sin avanzar, o confiar en los resultados de una herramienta más de lo que merecen.
La aplicación también puede fallar. Puede aceptar argumentos proporcionados por el modelo sin validarlos, exponer demasiadas herramientas al mismo tiempo, devolver resultados enormes y desordenados que confunden al modelo, ocultar mensajes de error útiles, asociar erróneamente los resultados a las llamadas que los generaron, o carecer de registros de auditoría, límites de uso y controles de aprobación.
Los ajustes en los prompts rara vez solucionan estos problemas. La solución radica en un diseño de herramientas mejor, esquemas más claros, permisos más estrictos, un manejo más adecuado del estado, más pruebas y una mejor supervisión.
Cuándo omitir las herramientas
La llamada a funciones no siempre es necesaria. Si una tarea solo requiere una explicación, un herramienta añade complicaciones. Si la información necesaria ya está en la solicitud y no cambia, no hay nada que obtener. Para acciones de alto riesgo que no pueden verificarse ni revertirse de forma segura, la automatización total podría ser la elección incorrecta. Además, si el resultado de una herramienta es poco fiable, no está documentado o es inseguro, integrarlo en un agente agrava los problemas.
También tiene un costo la experiencia del usuario. Las llamadas a herramientas generan retrasos, los mensajes de permiso interrumpen el flujo, y los agentes complejos pueden resultar impredecibles. A veces, un formulario sencillo es mejor que un flujo de chat, especialmente cuando los usuarios saben exactamente lo que quieren y necesitan rapidez, consistencia o cumplimiento.
El objetivo no es convertir todo en algo gestionado por agentes. Utilice una herramienta solo cuando el lenguaje, el contexto y la acción se complementen realmente.
Hábitos para construir bien
Comience con un puñado de herramientas claras y amplíe el acceso al modelo solo de forma gradual. Elija funciones específicas con nombres sencillos. Escriba descripciones para el modelo, no solo para los ingenieros. Utilice esquemas estrictos cuando sea posible y valide siempre las entradas en su propio código. Mantenga las salidas breves y pase al modelo únicamente lo que realmente necesita.
Establezca permisos herramienta por herramienta. Un agente de soporte que puede verificar el estado del pedido no necesita necesariamente emitir reembolsos. Un asistente de programación podría necesitar la disponibilidad del calendario, pero no las notas de eventos privados. Un asistente de programación debería poder leer un repositorio con antelación antes de poder abrir solicitudes de integración.
Exija que una persona apruebe cualquier cosa sensible, costosa, pública, legalmente vinculante, financiera o difícil de deshacer, y haga que la solicitud sea específica para que el revisor vea exactamente qué ocurrirá.
Leer más
- Uso de herramientas en producción para agentes: origen de los datos, intentos de reintentos y capacidad de observación — Un agente de un banco realizó llamadas excesivas a una API de pago e inventó un número de teléfono. Conozca los conjuntos mínimos de herramientas, el origen de los parámetros, los reintentos en tres niveles y las métricas por herramienta.
- Instantáneas de memoria de los agentes, habilidades, degradación y alcance por ramas — Cuatro mejoras a la capa de memoria de base de datos vectorial incrustada para agentes de programación: instantáneas portátiles con función de fusión, activación de habilidades, degradación con verificaciones de conflictos y memoria con alcance por ramas.