Un agente RAG que solo responde con lo que tienes en tus tablas de Databricks llega hasta cierto punto: en cuanto el usuario pide algo que depende de un sistema externo -el estado de un envío, el precio actual de un proveedor, disponibilidad en un CRM- el agente se queda sin respuesta. En el taller de Creación de Agentes Inteligentes con Databricks la sesión 4 resuelve justo eso: agentes modulares que deciden qué herramienta usar, incluyendo llamadas a APIs fuera de Databricks.
RAG resuelve lectura, no acción
Si ya armaste un agente RAG con LangChain y Databricks Vector Search -el patrón de la sesión 3-, tienes un agente que busca y responde con tus datos propios, pero que no puede hacer nada fuera de eso. La sesión 4 agrega una capa distinta: herramientas (tools) que el agente puede invocar cuando decide que las necesita, cada una con una descripción clara de qué hace y qué parámetros recibe. El modelo no ejecuta la herramienta directamente -decide cuál llamar y con qué datos, y tu código es el que de verdad hace la llamada HTTP, consulta la base externa o dispara el proceso.
Cómo se arma el agente modular
- ▸Defines cada herramienta como una función con nombre, descripción y esquema de parámetros -el modelo lee esa descripción para decidir cuándo usarla
- ▸El agente (con LangChain sobre un modelo servido en Databricks o del Marketplace) elige la herramienta y genera los argumentos
- ▸Tu notebook ejecuta la llamada real a la API externa y devuelve el resultado al agente
- ▸El agente decide si con eso ya puede responder o si necesita encadenar otra herramienta más
El detalle que más se descuida: si le das al agente una herramienta con una descripción vaga ("consulta datos"), la va a usar mal o ni la va a usar. Escribe la descripción como si se la explicaras a alguien que nunca vio tu sistema -con un ejemplo de cuándo sí aplica y cuándo no.
De notebook experimental a algo que puedes monitorear
Acá es donde entra MLflow, y no es un detalle menor. Cada vez que el agente corre, MLflow puede trackear qué herramienta usó, cuánto tardó, cuántos tokens consumió y si la respuesta final tuvo errores. Sin eso, un agente con varias herramientas es una caja negra: funciona en tus pruebas y cuando falla en producción no tienes forma de saber si fue la API externa, una mala decisión del modelo sobre qué herramienta usar, o un timeout. Con el tracking de MLflow puedes revisar la traza completa de una ejecución específica y ver exactamente dónde se rompió.
En la práctica, lo que registras en MLflow para un agente con herramientas no es muy distinto de lo que ya trackeas para un modelo clásico: parámetros de entrada, tiempo de ejecución, y métricas propias que definas (por ejemplo, cuántas veces el agente llamó a la herramienta equivocada en un set de pruebas). La diferencia es que acá la "predicción" es una secuencia de decisiones, no un único output, así que vale la pena loguear cada paso intermedio y no solo la respuesta final -es lo que te va a salvar cuando alguien del equipo pregunte por qué el agente contestó algo raro un martes a las 3pm.
Cuándo NO necesitas llegar hasta acá
No todo agente necesita herramientas externas, y meterlas por meterlas solo agrega puntos de falla. Si tu caso de uso es "responder preguntas sobre documentos internos" o "resumir reportes", el RAG de la sesión 3 ya resuelve el problema completo y agregar llamadas a APIs externas es complejidad que no se traduce en valor. La señal clara de que sí las necesitas es que el usuario te pida algo que depende de un dato que cambia fuera de Databricks -precio en tiempo real, estado de un sistema, disponibilidad- y que no tiene sentido sincronizar a una tabla porque cambia todo el tiempo.
Casos donde esto se usa de verdad
Un agente de soporte que consulta el estado de un pedido en un sistema de logística externo además de responder preguntas con el RAG sobre políticas de la empresa. Un agente de análisis que, además de consultar tus tablas, llama a una API de tipo de cambio o de clima cuando el análisis lo requiere. Un agente interno que dispara un webhook para crear un ticket en Jira cuando detecta un problema en los datos que está revisando. En los tres casos el patrón es el mismo: RAG para lo que ya tienes, herramientas para lo que no.
Qué cubre el taller completo
Son 4 sesiones y 11 horas: configuración del entorno en Databricks, agentes generativos con LLMs y LangChain, RAG con datos propios, y el bloque de agentes modulares con herramientas y APIs externas que acabamos de ver. Si quieres el recorrido completo de IA generativa en Databricks -Mosaic AI, Foundation Models del Marketplace y más tiempo de práctica- la Especialización en IA Generativa en Databricks cubre lo mismo con mucho más detalle.
Y si tu plan es construir una carrera sólida en agentes -no solo en Databricks, sino con LangGraph, AWS y Azure incluidos- la ruta de AI Agentic Engineer agrupa todo eso en un solo recorrido con progresión clara.
