Function calling con agentes: la guía técnica para producción

Function calling permite a un agente LLM ejecutar acciones concretas fuera del modelo: llamar APIs y herramientas externas mediante argumentos JSON estructurados. El modelo no ejecuta código directamente; propone qué función invocar y con qué parámetros, y un sistema externo se encarga de ejecutarla y devolver el resultado al hilo de conversación.

El mecanismo sigue un ciclo de tres pasos que aparece en casi toda arquitectura de agentes: pensar, actuar y observar. El modelo razona sobre la tarea, decide qué herramienta necesita, genera los argumentos en JSON, espera el resultado de la ejecución y lo reincorpora antes de continuar.

Esto resulta útil en escenarios muy concretos:

• Consultar datos en tiempo real (precios, inventario, estado de un sistema) que el modelo no puede conocer por sí solo.
• Ejecutar acciones con efectos reales: crear un ticket, enviar un correo, actualizar una base de datos.
• Alimentar generación aumentada por recuperación (RAG) con consultas dinámicas en lugar de contexto estático.
• Encadenar pasos de automatización donde cada resultado condiciona el siguiente.

Dato clave: según Hugging Face, estructurar la salida como JSON reduce las alucinaciones porque obliga al modelo a comprometerse con un formato verificable en lugar de responder en texto libre.

Puntos clave

Function calling funciona cuando el agente declara esquemas JSON precisos, valida cada llamada antes de ejecutarla y persiste el estado en checkpoints para sobrevivir a fallos.

Punto	Detalles
Definición operativa	Function calling conecta un LLM con herramientas externas mediante el ciclo pensar, actuar y observar.
Esquemas sin ambigüedad	Declara cada función con JSON Schema, tipos claros y restricciones explícitas de valores permitidos.
Orquestación como grafo	Modela dependencias multi-herramienta como DAG en lugar de cadenas lineales para paralelizar con seguridad.
Validación antes de ejecutar	Usa el modo VALIDATED para cualquier acción con efectos reales, nunca el modo AUTO sin comprobación.
Plataforma operativa	agent-swarm resuelve aislamiento, memoria compartida y checkpoints de fábrica frente a construirlos desde cero.

Tabla de contenidos

• Cómo funciona internamente el bucle del agente con function calling
• Cómo declarar herramientas con JSON Schema para minimizar errores
• Orquestar múltiples llamadas: dependencias, paralelismo y planificación
• Persistencia de estado y memoria para tareas de largo horizonte
• Cómo depurar y mantener sano un sistema de function calling en producción
• Cómo agent-swarm.dev implementa function calling a escala
• Modos de llamada a función: AUTO, VALIDATED, ANY y NONE
• Errores comunes en producción y cómo mitigarlos
• Ejemplos prácticos: del esquema a la respuesta reinyectada
• Manejo de excepciones y recuperación ante fallos
• Seguridad y permisos al dar herramientas a un agente
• Comparativa de frameworks y herramientas para function calling
• Descubre cómo agent-swarm resuelve la orquestación de function calling
• Fuentes
• Preguntas frecuentes

Cómo funciona internamente el bucle del agente con function calling

Cada llamada a función viaja dentro de una secuencia de mensajes con roles bien definidos. El patrón habitual es: user plantea la tarea, assistant responde con una propuesta de function_call, tool devuelve el resultado de la ejecución, y assistant retoma con la respuesta final o con una nueva llamada si hace falta encadenar pasos.

Un objeto de llamada típico incluye estos campos:

1. name: el identificador exacto de la función registrada, sin variaciones ni sinónimos.
2. arguments: un string JSON con los parámetros que el modelo decidió pasar, validado contra el esquema declarado.
3. id o tool_call_id: un identificador único que permite emparejar la respuesta de la herramienta con la llamada original, imprescindible cuando hay varias llamadas paralelas.
4. role: tool: el mensaje de retorno, que debe llevar el mismo identificador para que el modelo sepa a qué llamada corresponde el resultado.

Los modelos recientes permiten transmitir los argumentos en streaming, token a token, en lugar de esperar el objeto JSON completo. Esto reduce la latencia percibida en interfaces conversacionales, aunque complica la validación: hay que esperar a que el JSON esté completo y bien formado antes de ejecutar nada.

Consejo profesional: nunca ejecutes una función con argumentos parciales solo porque el streaming ya entregó suficiente texto para "adivinar" la intención. Espera el cierre del objeto JSON y valida contra el esquema antes de disparar cualquier efecto secundario.

Cómo declarar herramientas con JSON Schema para minimizar errores

Una declaración de función mal diseñada es la causa más común de llamadas fallidas o ambiguas. El modelo no puede inventar información que no tiene, así que cada herramienta necesita una definición completa y sin huecos.

Los elementos esenciales de cualquier declaración son:

• Nombre descriptivo y único, sin espacios ni caracteres que puedan confundirse con otra función similar.
• Descripción clara del propósito, escrita como si explicaras la función a otro desarrollador, no solo como metadato técnico.
• Parámetros tipados, indicando cuáles son obligatorios y cuáles opcionales.
• Restricciones de valores (enums, rangos, patrones) cuando el dominio de entrada es limitado.

JSON Schema es el estándar de facto para esta declaración: define tipos, formatos y validaciones de forma legible tanto por humanos como por máquinas. La mayoría de los frameworks de agentes generan el esquema automáticamente a partir de anotaciones de tipo en el código, lo que evita mantener dos fuentes de verdad desincronizadas.

Cuando el catálogo de herramientas crece, conviene restringir explícitamente qué funciones puede invocar el modelo en cada turno mediante una lista de allowed_function_names. Esto evita que un agente con acceso a treinta herramientas intente usar la incorrecta para una tarea muy específica, y reduce el espacio de búsqueda que el modelo tiene que razonar en cada decisión.

Orquestar múltiples llamadas: dependencias, paralelismo y planificación

Cuando una tarea requiere varias herramientas, ordenar las llamadas como una lista secuencial deja de ser suficiente. La investigación reciente sobre inferencia multi-herramienta propone modelar las tareas como grafos dirigidos acíclicos (DAG) en lugar de cadenas lineales, precisamente porque las dependencias reales rara vez son lineales.

Algunos patrones que funcionan en producción:

• Representa cada llamada como un nodo con sus dependencias explícitas: si la función B necesita el resultado de A, el grafo lo refleja antes de ejecutar nada.
• Paraleliza únicamente las llamadas sin dependencias entre sí. Consultar el inventario y el precio de un producto puede hacerse a la vez; reservar el producto no puede empezar hasta tener ambos resultados.
• Vigila las condiciones de carrera cuando dos llamadas paralelas escriben sobre el mismo recurso. El benchmark ToolBench expone justamente estos fallos de coordinación a gran escala.
• Diseña cada función para que sea idempotente: repetir la misma llamada con los mismos argumentos no debería duplicar efectos.

Consejo profesional: guarda un checkpoint después de cada nodo completado del DAG, no solo al final del flujo. Si el proceso falla en el paso siete de diez, reanudar desde el checkpoint cuesta una fracción del tiempo y los tokens de volver a empezar.

Persistencia de estado y memoria para tareas de largo horizonte

Un agente que ejecuta tareas de horas o días no puede depender de mantener todo el contexto en una sola ventana de prompt. Necesita una estrategia de memoria estructurada, no un historial creciente que se reinyecta sin criterio.

La memoria de un agente suele dividirse en tres capas:

1. Memoria de sesión: el contexto inmediato de la conversación actual, volátil y de corta duración.
2. Memoria episódica: el registro de eventos pasados relevantes, como qué herramientas se usaron y con qué resultado.
3. Memoria semántica o persistente: conocimiento consolidado que sobrevive entre sesiones, como preferencias del usuario o decisiones de arquitectura ya tomadas.

Inyectar todo el historial en cada prompt dispara el coste en tokens y degrada la calidad de las respuestas. La alternativa es comprimir mediante resúmenes incrementales y recuperar solo los fragmentos relevantes por consulta, en lugar de tratar la memoria como un archivo de registro que se repite sin filtrar.

En entornos multiusuario, la memoria también exige aislamiento estricto entre clientes o proyectos, además de mecanismos de failover: si el almacén de memoria falla, el agente necesita degradar con elegancia en vez de perder el estado por completo, tal como describe el enfoque de gestión de memoria de agentes de AWS para cargas de trabajo agénticas.

Cómo depurar y mantener sano un sistema de function calling en producción

Un agente en producción falla de formas distintas a las que se ven en pruebas locales, y casi siempre por acumulación: pequeñas ineficiencias que se multiplican en miles de sesiones diarias.

Los puntos de control más importantes son:

• Establece un límite máximo de iteraciones por subobjetivo. Sin ese tope, un agente atascado puede repetir la misma llamada indefinidamente sin darse cuenta de que no avanza.
• Define un umbral claro para escalar a intervención humana (HITL) cuando el número de reintentos supera lo razonable para esa tarea.
• Monitoriza latencia por llamada a herramienta, tokens consumidos por sesión y tasa de reintentos como métricas base de salud del sistema.
• Registra qué fragmentos de memoria se inyectaron en cada turno, no solo la respuesta final, para poder auditar por qué el agente tomó una decisión concreta.

Consejo profesional: si una función tarda sistemáticamente más de dos o tres segundos, considera moverla a ejecución asíncrona con notificación de resultado, en lugar de bloquear el turno del agente esperando la respuesta.

Cómo agent-swarm.dev implementa function calling a escala

agent-swarm aplica estos patrones con una arquitectura de agente líder que descompone objetivos complejos en tareas y las asigna a trabajadores especializados, cada uno ejecutando en un contenedor Docker aislado. Esto separa el razonamiento de alto nivel (qué hacer) de la ejecución concreta (cómo hacerlo), lo que reduce el riesgo de que un fallo en una herramienta contamine el resto del flujo.

La plataforma se integra con cientos de sistemas, incluyendo Slack, GitHub, Turso y OpenAI, y mantiene memoria compartida entre trabajadores para que el contexto se acumule en lugar de perderse entre tareas.

El valor real de una capa de orquestación no está en ejecutar una llamada a función aislada, sino en sobrevivir a la centésima llamada del día sin perder estado, sin duplicar efectos y sin que el coste en tokens se dispare.

Construir esta capa desde cero tiene sentido cuando el equipo necesita control total sobre cada decisión de arquitectura. Adoptar una plataforma como agent-swarm tiene sentido cuando el equipo prioriza tiempo de llegada a producción y necesita checkpoints, aislamiento y revisiones ya resueltos:

• Equipos con flujos recurrentes en varios departamentos (ingeniería, soporte, operaciones) que repiten patrones de orquestación.
• Organizaciones que necesitan control de permisos y trazabilidad desde el primer día, no como una capa añadida después.

Modos de llamada a función: AUTO, VALIDATED, ANY y NONE

No todas las llamadas a función deberían tener el mismo nivel de autonomía. La documentación de Google Cloud sobre function calling describe cuatro modos que controlan cuánta libertad tiene el modelo para decidir cuándo y qué función invocar.

En modo AUTO, el modelo decide libremente si necesita llamar a una función, a cuál y con qué argumentos, basándose únicamente en el contexto de la conversación. Es el modo más flexible y el más usado en asistentes conversacionales generales.

El modo ANY obliga al modelo a llamar a alguna función del catálogo disponible, sin darle la opción de responder solo con texto. Resulta útil cuando el flujo de trabajo exige una acción concreta y no admite que el agente "se escape" con una respuesta conversacional.

NONE desactiva por completo la capacidad de llamar funciones para ese turno, forzando una respuesta textual. Se usa para tramos de la conversación donde no quieres que el modelo ejecute ninguna acción, aunque tenga herramientas disponibles.

VALIDATED añade una capa de verificación antes de ejecutar: la llamada propuesta se contrasta contra el esquema declarado y, en implementaciones más estrictas, contra reglas de negocio adicionales antes de disparar el efecto. Este modo es el que corresponde usar en cualquier acción con consecuencias reales, como enviar un pedido, mover dinero o modificar una base de datos de producción.

La elección del modo no es una decisión estética. Un asistente en modo AUTO que puede modificar registros sin validación previa es un incidente esperando a ocurrir; el mismo asistente en modo VALIDATED, con comprobación de esquema y reglas de negocio antes de ejecutar, convierte un riesgo real en un flujo controlado.

Errores comunes en producción y cómo mitigarlos

La latencia acumulada es el problema más visible cuando un agente encadena varias llamadas a función de forma secuencial. Cada tool call añade una ida y vuelta de red, y si tres o cuatro llamadas dependen unas de otras, el usuario percibe segundos de espera donde esperaba una respuesta instantánea. La mitigación pasa por paralelizar lo que no tenga dependencias reales y por mover a ejecución asíncrona las operaciones que tardan más de lo razonable.

El coste en tokens crece de forma silenciosa cuando cada llamada reinyecta el historial completo de la conversación más el resultado de la herramienta anterior. En sesiones largas, esto puede multiplicar el gasto por diez sin que nadie lo note hasta ver la factura mensual. Comprimir el historial con resúmenes incrementales, en lugar de acarrear cada mensaje sin filtrar, es la corrección más efectiva.

Los bucles infinitos aparecen cuando el agente reintenta la misma llamada fallida sin cambiar de estrategia, o cuando dos funciones se llaman mutuamente sin condición de salida clara. Un límite explícito de iteraciones por subobjetivo, combinado con una política de reintento que cambie de enfoque tras el segundo fallo, corta este patrón antes de que consuma presupuesto o tiempo de cómputo.

Un cuarto error, menos discutido, es la desincronización entre el esquema declarado y la función real ejecutada: alguien actualiza el código de la herramienta pero olvida actualizar el esquema JSON que el modelo ve. Versionar esquemas junto al código, no por separado, evita este desfase.

Ejemplos prácticos: del esquema a la respuesta reinyectada

El flujo completo de una llamada a función real tiene tres momentos diferenciados, y vale la pena verlos con un ejemplo concreto: un agente que consulta el estado de un envío.

Paso 1: declaración del esquema. El sistema registra una función consultar_envio con un parámetro obligatorio numero_seguimiento de tipo string. El modelo recibe esta declaración junto con el resto de herramientas disponibles al inicio de la conversación.

Paso 2: propuesta de llamada. Cuando el usuario pregunta "¿dónde está mi pedido 4471?", el modelo no responde con texto genérico. Genera un objeto function_call con name: "consultar_envio" y arguments: {"numero_seguimiento": "4471"}. Este objeto se valida contra el esquema antes de tocar ningún sistema externo.

Paso 3: ejecución y reinyección. Un servicio externo al modelo ejecuta la consulta real contra el sistema logístico, obtiene el estado ("en tránsito, entrega estimada mañana") y lo envuelve en un mensaje role: tool con el mismo identificador de la llamada original. Ese mensaje se añade al historial y el modelo genera la respuesta final en lenguaje natural.

El punto crítico de todo el flujo es el tercer paso: el modelo nunca ejecuta código por sí mismo. Confía en que el sistema externo devuelva un resultado honesto, así que la responsabilidad de manejar errores, tiempos de espera y formatos inesperados recae en quien orquesta, no en el modelo. ToolCallingAgents ilustra este patrón generando exactamente un objeto JSON con name y arguments que un motor externo interpreta y ejecuta.

Manejo de excepciones y recuperación ante fallos

Una función puede fallar de más formas de las que un desarrollador anticipa en el diseño inicial: tiempo de espera agotado, argumentos que pasan la validación de esquema pero no tienen sentido de negocio, o un servicio externo que devuelve un error 500 justo en medio de una cadena de tres llamadas dependientes.

La primera línea de defensa es distinguir entre errores recuperables y no recuperables. Un tiempo de espera agotado suele ser recuperable con un reintento; un error de autorización casi nunca lo es, y reintentarlo solo desperdicia tiempo y tokens. El sistema de orquestación necesita esta clasificación para decidir automáticamente cuándo reintentar y cuándo escalar.

Cuando una llamada falla, el resultado que se reinyecta al modelo no debería ser un error críptico de la API subyacente. Traducir el fallo a un mensaje que el modelo pueda interpretar ("el servicio de inventario no respondió a tiempo, intenta de nuevo en unos segundos") le da al agente la información necesaria para decidir su siguiente paso, en lugar de quedarse atascado interpretando un código de estado HTTP.

Los reintentos automáticos necesitan un límite estricto y, preferiblemente, un backoff exponencial entre intentos. Sin ese límite, una función que falla de forma persistente puede convertirse en el bucle infinito que mencionábamos antes, consumiendo presupuesto sin que nadie lo note hasta revisar los logs. Registrar cada intento fallido con su causa concreta, no solo el resultado final, es lo que permite diagnosticar después si el problema fue transitorio o estructural.

Seguridad y permisos al dar herramientas a un agente

Cada función que un agente puede invocar es, en la práctica, un punto de acceso al mundo real. Diseñar el conjunto de herramientas sin pensar en seguridad es el equivalente a dar acceso de administrador a un script que todavía no has terminado de depurar.

El principio de menor privilegio aplica aquí con más fuerza que en cualquier otro sistema: un agente encargado de responder preguntas de soporte no necesita acceso a la función que borra cuentas de usuario, aunque técnicamente ambas vivan en el mismo backend. Separar las herramientas por nivel de riesgo y limitar qué agente puede ver cuáles, mediante listas explícitas de funciones permitidas, reduce la superficie de ataque de forma directa.

Las funciones que modifican datos o mueven dinero deberían pasar siempre por el modo VALIDATED descrito antes, nunca por AUTO. Esto añade una capa de verificación explícita entre la intención del modelo y la ejecución real, y es el punto donde conviene insertar reglas de negocio adicionales: límites de importe, ventanas horarias permitidas, o confirmación humana para operaciones por encima de cierto umbral.

La multitenencia añade otra capa de riesgo: si varios clientes comparten la misma infraestructura de agentes, un fallo en el aislamiento de memoria o de credenciales puede filtrar datos de un cliente hacia la sesión de otro. Ejecutar cada trabajador en un entorno aislado, con credenciales de alcance limitado a su tarea específica, es la mitigación más directa contra este escenario.

Comparativa de frameworks y herramientas para function calling

En un extremo están las bibliotecas ligeras orientadas a un único modelo, que exponen la función nativa de llamada a herramientas de un proveedor concreto con configuración mínima. Son rápidas de adoptar pero atan el proyecto a las particularidades de ese proveedor: cambiar de modelo suele implicar reescribir cómo se declaran los esquemas.

En el medio están los frameworks de agentes de propósito general, que añaden abstracciones sobre múltiples proveedores de modelos, gestión de memoria básica y algunas utilidades de orquestación. Ofrecen más portabilidad, pero suelen dejar en manos del equipo de desarrollo la parte más difícil: checkpoints robustos, aislamiento de ejecución y recuperación ante fallos en cadenas largas de llamadas.

En el otro extremo están las plataformas operativas completas, diseñadas para producción desde el inicio, con aislamiento de ejecución, memoria persistente entre tareas y paneles de control para auditar qué hizo cada agente y por qué. agent-swarm pertenece a esta categoría: en lugar de exponer solo la función de llamada a herramientas, coordina un agente líder y trabajadores especializados en contenedores aislados, con checkpoints y memoria compartida ya resueltos.

La elección correcta depende del horizonte del proyecto. Para un prototipo o una integración puntual, una biblioteca ligera es suficiente. Para un sistema que va a ejecutar miles de tareas encadenadas al día, con múltiples equipos dependiendo de su fiabilidad, el coste de construir esa capa operativa desde cero rara vez se justifica frente a adoptar una plataforma ya probada en ese escenario.

Checklist rápido para arrancar en una semana

Si tu equipo empieza ahora, prioriza dos o tres herramientas con esquemas JSON bien definidos, monta un sandbox con pruebas unitarias para cada tool call, y configura checkpoints básicos junto con métricas de coste desde el primer día.

— Ez.-

Descubre cómo agent-swarm resuelve la orquestación de function calling

Los patrones descritos (DAGs para dependencias, checkpoints para tareas largas, aislamiento por seguridad) son exactamente los que agent-swarm resuelve de fábrica en lugar de dejarlos como tarea pendiente del equipo de ingeniería.

Si tu equipo ya identifica los cuellos de botella típicos de construir esto desde cero (memoria que se pierde entre tareas, falta de aislamiento entre trabajadores, ausencia de checkpoints ante fallos), agent-swarm ofrece un sistema operativo de código abierto que reparte objetivos complejos entre un agente líder y trabajadores especializados, cada uno en su propio contenedor. Puedes revisar cómo se compara frente a construir tu propia orquestación en la comparativa de enfoques o explorar directamente la plataforma de agent-swarm para ver las integraciones con Slack, GitHub y OpenAI en funcionamiento.

Fuentes

• ¿Qué es la Llamada a Funciones? · Hugging Face
• Introducción a las llamadas a funciones | Gemini Enterprise Agent Platform | Google Cloud Documentation
• Agent memory and state management - Agentic AI Lens
• ICLR 2024 proceedings (ToolBench / multi-tool analysis)
• Survey on multi-tool agent inference paradigms (arXiv)

Preguntas frecuentes

¿Qué es function calling exactamente?

Es la capacidad de un modelo de lenguaje para detectar cuándo una tarea requiere una herramienta externa, generar argumentos estructurados en JSON y reinyectar el resultado en la conversación antes de responder.

¿Cuáles son los tipos principales de agentes de IA?

Suelen distinguirse por su nivel de autonomía y memoria: agentes reactivos simples, agentes basados en modelos internos, agentes orientados a objetivos, agentes basados en utilidad y agentes de aprendizaje, aunque las implementaciones prácticas mezclan varios de estos enfoques.

¿Qué agentes de IA se pueden usar para programar?

Existen agentes especializados en generación y revisión de código que se integran como trabajadores dentro de sistemas de orquestación más amplios; agent-swarm, por ejemplo, coordina trabajadores basados en Claude Code, Codex, pi-mono, Open Code y Devin AI dentro de contenedores aislados.

¿Cómo se hace una llamada a una función con inteligencia artificial?

El desarrollador declara la función con su esquema JSON, el modelo propone una llamada con argumentos concretos cuando la detecta necesaria, un sistema externo la ejecuta y el resultado se reinyecta como mensaje de tipo herramienta para que el modelo continúe la respuesta.

¿Cuándo conviene usar una plataforma como agent-swarm en lugar de construir la orquestación propia?

Cuando el equipo necesita checkpoints, aislamiento por contenedores y memoria compartida ya resueltos, en lugar de dedicar semanas de ingeniería a construir esa capa operativa desde cero.

Recomendación

• Agent Governance: The Engineering Team's Production OS Guide | agent-swarm.dev
• Multi-Agent Orchestration: The Production Architect's Guide | agent-swarm.dev
• Agentic Workflow Automation: A Practical Engineering Guide | agent-swarm.dev
• Agent Swarm Blog: Technical Deep Dives & Architecture Notes