title: "Agentes con LLM en n8n: cómo funcionan y qué hemos conseguido con ellos" slug: agentes-ia-llm-n8n-casos-uso-reales excerpt: "Hay mucha confusión sobre qué es un agente de IA. La mayoría de los 'agentes' que se venden son chatbots con prompts más largos. Un agente de verdad no solo responde, sino que decide y actúa. Aquí explicamos cómo funcionan en n8n y qué hemos implementado en producción." category: ia tags: [agentes, ia, llm, n8n, automatizacion, gpt] author: Flexum date: 2026-06-15

Agentes con LLM en n8n: cómo funcionan y qué hemos conseguido con ellos

Hay mucha confusión sobre qué es exactamente un agente de inteligencia artificial. La mayoría de los productos que se venden como "agentes" son chatbots con prompts más elaborados. Responden preguntas con más contexto, mantienen el hilo de una conversación más larga, acceden a información adicional. Pero siguen siendo reactivos: esperan una pregunta, generan una respuesta.

Un agente real hace algo distinto: decide y actúa.

La diferencia real entre un chatbot y un agente

Un chatbot recibe una pregunta y genera texto. El texto puede ser muy bueno, puede incluir información actualizada, puede parecer muy inteligente. Pero cuando el usuario dice "recuérdame que llame a Pedro el martes", un chatbot responde "anotado" y no hace nada más.

Un agente con las herramientas adecuadas puede crear una entrada de calendario, enviar un mensaje de WhatsApp el martes a la hora indicada, y actualizar el registro de Pedro en el CRM para que el equipo sepa que hay una llamada pendiente.

La diferencia no es de calidad del lenguaje. Es de capacidad de acción.

Cómo funcionan los agentes en n8n

n8n tiene un nodo específico de AI Agent que implementa el patrón de agente con herramientas. La arquitectura tiene cuatro componentes:

El modelo de lenguaje: el cerebro del agente. Recibe el objetivo, el historial de conversación, la descripción de las herramientas disponibles, y decide qué herramienta usar, en qué orden, y con qué parámetros. Habitualmente GPT-4o o Claude para tareas complejas, modelos más pequeños para tareas de clasificación o extracción simple.

Las herramientas: las acciones que el agente puede ejecutar. En n8n, cada herramienta es un nodo conectado al agente: un HTTP Request para llamar a una API externa, un nodo Postgres para consultar o escribir en base de datos, un nodo Code para lógica personalizada, un nodo de búsqueda en vector store para recuperar documentos relevantes.

La memoria: el historial de la conversación que el agente tiene disponible para mantener el contexto entre mensajes. Hay dos variantes con implicaciones distintas, que explicamos más adelante.

El system prompt: las instrucciones que definen el comportamiento del agente, su área de actuación, sus restricciones, y cómo debe usar cada herramienta. Este es el componente donde se invierte más tiempo y donde está la mayor parte de la calidad del agente.

Las herramientas que más usamos

Búsqueda y actualización de CRM: el agente puede buscar un cliente por nombre o email, consultar sus interacciones anteriores, y actualizar o crear registros. Fundamental para agentes de atención al cliente y de soporte.

Consultas de stock e inventario: el agente puede verificar disponibilidad en tiempo real antes de confirmar algo a un usuario, sin necesidad de acceder a un panel de administración.

Creación de registros: crear leads, tickets, tareas, citas. Aquí es donde el diseño conservador importa: las acciones irreversibles o difícilmente corregibles (como enviar un email a un cliente, cancelar un pedido, hacer un reembolso) deben tener una validación humana antes de ejecutarse, no ejecutarse directamente por el agente.

Base de conocimiento vectorial: el agente busca en una colección de documentos de la empresa (manuales, FAQs, políticas, casos resueltos) antes de responder. Esto es crítico para reducir las alucinaciones: en lugar de generar una respuesta plausible sobre la política de devoluciones, el agente busca el documento que describe esa política y basa su respuesta en texto real.

El problema de la memoria

El contexto de un modelo de lenguaje no es infinito. Si un agente mantiene conversaciones largas y acumula el historial completo en cada llamada al modelo, llega un punto en que la conversación no cabe en el contexto, el coste por conversación se dispara, y la latencia aumenta notablemente.

Hay dos aproximaciones principales:

Buffer memory: el agente solo conserva los últimos N mensajes de la conversación. Simple, predecible, barato. El problema es que el agente "olvida" lo que se discutió al principio de conversaciones largas.

Memoria en PostgreSQL con resúmenes periódicos: el historial completo de cada conversación se almacena en base de datos. Periódicamente (cada N mensajes o cada sesión) el modelo genera un resumen compacto de la conversación que se usa como contexto en lugar del historial completo. La conversación persiste entre sesiones: el agente recuerda lo que se habló hace 3 días. Más complejo de implementar, necesario para agentes que gestionan relaciones a largo plazo con usuarios específicos.

La elección entre uno y otro depende del caso de uso. Para soporte técnico donde cada sesión es independiente, el buffer memory suele ser suficiente. Para un agente de gestión de cuenta que mantiene relación continua con el mismo cliente, la memoria persistente en PostgreSQL es necesaria.

Casos reales en producción

Agente de cualificación de leads por WhatsApp

El contexto: un equipo comercial de 4 personas recibiendo leads de distintas fuentes (formulario web, campañas de anuncios, referidos). El problema: la mayoría del tiempo del equipo iba a llamadas con leads que no tenían el perfil o el presupuesto adecuado.

El agente recibe el mensaje de WhatsApp del lead (via API de WhatsApp Business), mantiene una conversación de 4-5 preguntas de cualificación (sector, tamaño de empresa, problema que quiere resolver, plazo para implementar, presupuesto aproximado), y al final de la conversación crea un registro en Pipedrive con todos los datos recogidos y una puntuación de cualificación calculada según las respuestas.

El equipo comercial solo recibe notificación y realiza llamadas cuando un lead supera el umbral de cualificación. Los leads por debajo del umbral quedan en el CRM para seguimiento automatizado posterior.

Resultado después de tres meses: el equipo habla con el 40% de los leads que antes. Cierra el mismo número de contratos. El tiempo liberado va a nurturing de leads cualificados y a preparación de propuestas.

Agente de consulta de documentación interna

El contexto: un equipo de operaciones que hace constantemente las mismas preguntas sobre procedimientos internos, políticas de la empresa, y configuraciones de sistemas. Las respuestas están en documentos dispersos en Google Drive y en la cabeza de las personas con más antigüedad.

El agente recibe preguntas por Slack en lenguaje natural, busca en un vector store alimentado con los documentos de la empresa (manuales de proceso, políticas, FAQs internas, notas de proyectos anteriores), y responde citando la fuente específica. Si no encuentra respuesta relevante, responde explícitamente que no tiene esa información, sin inventar nada.

Esta última parte es crítica y requiere instrucciones explícitas en el system prompt: el agente debe estar programado para decir "no lo sé" cuando no tiene información fiable, no para generar una respuesta plausible que puede ser incorrecta.

Resultado: ahorro de aproximadamente 2 horas semanales por persona en el equipo de operaciones, reducción de interrupciones a personas clave para preguntas repetidas, y base de conocimiento que se actualiza cuando se añaden nuevos documentos al vector store.

Agente de soporte técnico interno

El contexto: una empresa con un equipo de IT reducido que recibe un volumen alto de tickets de soporte interno, la mayoría sobre los mismos problemas recurrentes.

El agente tiene acceso a una base de conocimiento vectorial con los tickets resueltos anteriormente, la documentación técnica de los sistemas, y las FAQs del equipo. Cuando llega un ticket nuevo, busca soluciones similares anteriores y propone la solución al usuario. Si el usuario confirma que la solución funcionó, el ticket se cierra. Si no resuelve el problema, el agente escala al equipo de IT con un resumen de la conversación y los pasos ya intentados.

El equipo de IT solo recibe los tickets que el agente no ha podido resolver, con todo el contexto de la interacción anterior. No empiezan de cero.

Resultado: el agente resuelve el 65% de los tickets sin intervención humana. El 35% que escala llega al equipo con suficiente contexto para resolver más rápido.

Los límites reales

El agente toma decisiones equivocadas

Puede usar la herramienta incorrecta para una petición, malinterpretar la intención del usuario, o encadenar pasos en el orden equivocado. Esto es tolerable en conversaciones de bajo riesgo donde el error es detectable y corregible. En flujos con acciones irreversibles (enviar emails masivos, hacer reembolsos, modificar datos críticos), el diseño debe incluir un paso de confirmación antes de ejecutar.

La latencia

Cada llamada al modelo tarda entre 1 y 4 segundos. Cada llamada a una herramienta externa añade más latencia. Un agente que hace 3 llamadas secuenciales a herramientas antes de responder puede tardar entre 10 y 15 segundos en dar una respuesta. En contextos conversacionales esto es perceptible. El usuario debe saber que el agente está "pensando", no asumir que algo ha fallado.

El coste por conversación

Los agentes consumen más tokens que los chatbots simples: el contexto de la conversación, las descripciones de las herramientas disponibles, los resultados de las herramientas usadas. En aplicaciones con alto volumen de conversaciones, el coste puede ser significativo y debe tenerse en cuenta en el análisis de rentabilidad.

El system prompt es el trabajo real

El 70% de la calidad de un agente viene de la calidad del system prompt. Las instrucciones sobre cuándo usar cada herramienta, cómo manejar casos ambiguos, cómo responder cuando no se tiene información, cómo mantener el tono adecuado para el contexto de uso, cuándo escalar a un humano.

Los primeros prompts nunca funcionan bien. La refinación del system prompt requiere tiempo y pruebas reales con casos de uso del contexto específico. No hay forma de acortar ese proceso: la calidad del agente es directamente proporcional al tiempo invertido en diseñar y refinar sus instrucciones.

Un agente con un sistema de herramientas técnicamente bien implementado pero con un system prompt genérico va a decepcionar. Un agente con herramientas más simples pero con un system prompt muy bien trabajado para su contexto específico va a funcionar notablemente mejor.

No hay atajos ahí.