¿Cómo descubre el LLM qué herramientas tiene disponibles y cuándo usarlas?

Cuando conectas herramientas a un agente LangChain — una que consulta disponibilidad en Google Calendar, otra que crea citas en el CRM, otra que busca en la base de datos — el LLM necesita saber dos cosas: que esas herramientas existen y cuándo invocarlas. ¿Cómo ocurre eso? No es magia: es texto. Específicamente, es la descripción que tú escribes para cada tool.

En LangChain, el decorador @tool registra la función como una herramienta disponible para el agente. El docstring de la función — su descripción — se convierte en el "prompt" que le dice al LLM cuándo y cómo invocarla. La calidad de esa descripción determina directamente la fiabilidad con la que el agente usará la herramienta.

La convención más efectiva para escribir descripciones de tools es empezar siempre con "Use this when…" seguido de las condiciones que deben cumplirse en el input del usuario. No describes lo que hace la función internamente — describes el intent del usuario que debería activarla.

from langchain.tools import tool

@tool
def check_availability(date: str, service_type: str) -> list[dict]:
    """Use this when the user asks about available appointment slots,
    wants to know when the doctor is free, or asks about scheduling
    availability for any service. Returns available time blocks.

    Args:
        date: Date in YYYY-MM-DD format (extract from user message)
        service_type: Type of service requested (e.g. 'general', 'surgery')
    """
    # Aquí va el código real: llamada a Google Calendar API, etc.
    return google_calendar.get_slots(date, service_type)


@tool
def book_appointment(date: str, time: str, pet_name: str, service: str) -> dict:
    """Use this when the user wants to book, schedule, reserve, or
    confirm an appointment. Only call this after confirming availability
    with check_availability.

    Args:
        date: Date in YYYY-MM-DD format
        time: Time in HH:MM format
        pet_name: Name of the patient's pet
        service: Type of service to book
    """
    return crm.create_appointment(date, time, pet_name, service)

El loop que sigue cuando el LLM recibe un mensaje con tools disponibles:

La diferencia entre una tool que el LLM invoca de forma fiable y una que ignora frecuentemente está casi siempre en la calidad de la descripción, no en la implementación técnica:

Una de las decisiones de diseño más poderosas (y menos conocidas) en sistemas multi-tool es que cada tool puede usar un LLM diferente internamente. El LLM que orquesta la conversación (el que decide qué tool llamar y cuándo) está completamente desacoplado del LLM que podría ejecutarse dentro de una tool específica.

Esto permite optimizar por caso de uso: un modelo rápido y económico para la extracción de slots en herramientas simples, un modelo más potente para el razonamiento principal de la conversación, y un modelo especializado para tareas que lo requieran (por ejemplo, un modelo con fine-tuning médico para clasificar síntomas en un bot veterinario).

El tool loop puede repetirse hasta 5 iteraciones porque el LLM no sabe qué va a devolver una tool hasta que la ejecuta. En algunos flujos complejos (por ejemplo, verificar disponibilidad → reservar → enviar confirmación → actualizar CRM), son necesarias varias rondas de tool calls secuenciales antes de poder generar la respuesta final.