Function calling: cómo hacer que un LLM actúe, no solo responda

Un modelo de lenguaje, por sí solo, solo sabe hacer una cosa: generar texto. Es un conversador brillante y un ejecutor nulo. Pregúntale cuál es tu saldo bancario y, sin ayuda, va a inventar un número convincente — porque generar texto plausible es literalmente todo lo que hace. Function calling es el puente entre ese conversador y el mundo real. Es el mecanismo que transforma "IA que habla" en "IA que hace".

Si quieres construir agentes que resuelven — y no chatbots que empujan al cliente hacia el portal — necesitas entender esto a fondo.

Qué es, de verdad

Function calling (también llamado tool use) es la capacidad del modelo de, en medio de una conversación, decidir que necesita una herramienta externa y pedir usarla. El flujo es este:

1. Le dices al modelo qué herramientas existen (nombre, descripción, parámetros).
2. En la conversación, el modelo se da cuenta de que necesita una de ellas y, en lugar de responder texto, devuelve una llamada estructurada: buscar_pedido(id: "123").
3. Tu código ejecuta esa función de verdad — consulta la base de datos, llama la API — y devuelve el resultado al modelo.
4. El modelo usa ese dato real para continuar la conversación: "Tu pedido 123 salió para entrega hoy."

El punto que mucha gente falla: el LLM no ejecuta nada. Solo decide qué llamar y con qué argumentos. Quien ejecuta — y valida — eres tú. Esa separación es la columna vertebral de un agente seguro.

Por qué esto lo cambia todo

Sin tools, el techo de un LLM es dar información genérica y, en el peor de los casos, alucinar. Con tools, pasa a operar sobre la realidad de tu negocio: los datos reales del cliente, el stock real, el pago real. La conversación deja de ser sobre el problema y pasa a resolver el problema.

Es exactamente esa la diferencia que separa un agente de IA de un chatbot. El chatbot dice "para el duplicado, entra al portal". El agente llama gerar_segunda_via(cliente_id), recibe la factura y manda el PIX en la conversación. Misma pregunta, categorías de software completamente diferentes — y la diferencia es function calling bien hecho.

Cómo diseñar buenas herramientas

La calidad de tu agente depende más del diseño de las herramientas que del modelo. Principios que sigo:

Descripciones que el modelo entiende. La description de cada herramienta es un prompt. "Busca información" es malo; "Busca el estado de entrega de un pedido por el número del pedido" es bueno. El modelo elige la herramienta leyendo esto — sé específico.

Parámetros tipados y mínimos. Pide exactamente lo que la función necesita, con tipos claros. Menos parámetros, menos chance de que el modelo se equivoque al completarlos. Enums cuando los valores son fijos.

Herramientas atómicas, no navajas suizas. Una herramienta que hace cinco cosas dependiendo de un parámetro accion confunde al modelo. Prefiere abrir_chamado, consultar_chamado, fechar_chamado separados. Cada una hace una cosa bien.

Retornos que el modelo pueda usar. Devuelve datos estructurados y concisos. Un JSON gigante gasta contexto y confunde. Devuelve lo esencial para la próxima decisión.

Los errores que rompen en producción

Vi (y cometí) todos estos:

• Confiar en los argumentos del modelo sin validar. El LLM puede alucinar un cliente_id que no existe, o un valor negativo. Tu capa de ejecución valida todo antes de actuar. Regla innegociable.
• Herramientas irreversibles sin confirmación. transferir_dinheiro no puede llamarse solo porque el modelo pensó que era buena idea. Las acciones que cambian el mundo de forma irreversible exigen confirmación explícita del usuario y log.
• Loop infinito de tools. El modelo llama, el resultado lo hace llamar de nuevo, y entra en ciclo. Pon un límite de llamadas por turno y observabilidad para detectarlo.
• Sin log de las llamadas. Si no registras qué herramienta fue llamada, con qué argumentos y con qué resultado, no depuras nada cuando algo salga mal. Y va a salir mal.

La regla de oro

Lo resumo así: el LLM es el cerebro que decide; la capa de herramientas es el cuerpo que actúa con responsabilidad. El cerebro puede divagar, dudar, hasta alucinar. El cuerpo — tu código — no puede. Valida cada intención, confirma lo que es peligroso, ejecuta lo que es seguro, y registra todo.

Function calling es lo que hace que la IA salga de la pantalla y toque el negocio. Pero es también donde vive el riesgo. Hacer bien esta capa es la diferencia entre un agente en el que confías en producción y uno que no deberías haber encendido.

Construyo agentes de IA que actúan de verdad — con function calling seguro, integrado a los sistemas del negocio. Si quieres salir del chatbot y tener IA que ejecuta, conversemos.