La mayoría de los agentes de IA no deberían ser agentes
One agent
Large model
Every turn. Full system prompt, every tool description, whether or not it calls one.
Three steps
Cuando los agentes llegaron a n8n, construí muchos. Colocas un nodo de agente, le conectas tres herramientas y él decide cuál llamar. Parecía que todo se había vuelto sencillo.
En los meses siguientes, eliminé la mayoría. En los flujos de trabajo que debían escalar y ejecutarse realmente en producción, he reducido a aproximadamente una quinta parte los agentes que tenía.
No porque los agentes sean malos. Sino porque, en la mayor parte de lo que hacía, el agente decidía en tiempo de ejecución cosas que yo ya sabía en el momento del diseño, y me cobraba por ese privilegio en cada interacción.
El esquema que voy a analizar
Un chatbot de soporte. Un activador de chat, un agente basado en un modelo grande y una herramienta: una solicitud HTTP a un endpoint de recuperación que responde preguntas basadas en mis documentos. Alguien pregunta sobre el producto, el agente llama a la herramienta, lee la respuesta y redacta la contestación.
Agente de conocimiento de IA
- Cuando se recibe mensaje de chat
- Agente de conocimiento de IAgpt-4.1Modelo de chatModelo de chat de OpenAIgpt-4.1MemoriaMemoria simpleHerramientaConsultar base de conocimientosSolicitud HTTP. El agente redacta la consulta y decide cuándo llamarla
Alguien dice hola y te cuesta un modelo de vanguardia
Envía un “hola” a ese agente. Recibes una respuesta amable en unos 1,3 segundos, redactada por uno de los modelos más grandes disponibles.
No se llamó a ninguna herramienta. No se recuperó nada. Todo el prompt del sistema entró como tokens de entrada, incluyendo cada línea que describía herramientas que nunca se utilizaron.
- Llega el mensaje"hola"1 token
- Entra el prompt del sistema completoCada descripción de herramienta, cada regla sobre cuándo llamar a quétodo
- El modelo grande decideDecide no llamar a nada
- El modelo grande responde"Hola, ¿en qué puedo ayudarte hoy?"
El saludo es el caso más evidente, pero no es raro. En un chatbot, una gran parte de los mensajes no requieren recuperar ni buscar nada.
Lo mismo, pero definido paso a paso
Aquí está el sustituto. Tiene más nodos, y cada uno de ellos es una decisión que tomé una sola vez en lugar de una decisión que un modelo toma con cada mensaje.
Chatbot RAG inteligente y eficiente
- Cuando se recibe un mensaje de chat
- Buscar mensajes anterioresGestor de memoria, modo cargaMemoryMemoria simple
- Enrutador de intenciónClasificador de texto, dos categoríasChat ModelModelo muy pequeñogpt-4.1-nano
no se requiere recuperación de conocimiento
- Respuesta simpleCadena LLM básica con el mismo modelo diminuto
se requiere recuperación de conocimiento
- Preparar consulta de recuperaciónCadena LLM básica, gpt-4.1-mini
- RAG vía LookioSolicitud HTTP simple. Sin modelo en este paso
- Escribir la respuesta finalCadena LLM básica, gpt-4.1. El único modelo grande en el lienzo
- Responder al chat
- Almacenar mensajesGestor de memoria, modo inserción
Enrutar primero, con un modelo que no cuesta nada
La única función del Clasificador de Texto es decidir qué camino toma el mensaje. Dos categorías, cada una con una descripción:
- No requiere recuperación de conocimientos. Saludos, confirmaciones, charla trivial. Cualquier cosa que se pueda responder sin consultar nada.
- Requiere recuperación de conocimientos. El mensaje necesita información de los documentos antes de poder ser respondido.
La clasificación es una tarea ligera y un modelo pequeño es muy eficiente en ella. Es lo suficientemente rápido como para que el paso apenas afecte a la latencia total, y lo suficientemente barato como para que haya dejado de preocuparme.
La ruta económica es una cadena de LLM básica basada en ese mismo modelo diminuto con un prompt de sistema corto. Ahora el “Hola” tarda unos dos segundos en responder, se lee exactamente igual y utiliza un modelo que cuesta una fracción por token que el que sustituyó.
Un único nodo de modelo alimenta tanto al router como a la respuesta simple. Son tareas diferentes pero de la misma magnitud, y tener un solo lugar para cambiar el modelo significa que ocasionalmente pruebo uno distinto en lugar de editar dos nodos y olvidarme del segundo.
Configurar el trigger para responder desde un nodo
Un detalle menor que bloquea todo el diseño si se pasa por alto. Por defecto, un trigger de chat responde desde el último nodo, y este flujo de trabajo tiene dos rutas que necesitan responder.
Configura el modo de respuesta del trigger para que responda desde un nodo y, después, coloca un nodo Respond to Chat donde se unen las ramas. Sin él, no hay forma de tener una ruta económica y otra costosa que respondan, que es precisamente el objetivo del enrutamiento.
La ruta de recuperación en tres nodos
Observad lo que hizo el agente con una pregunta real. Se llamó al modelo grande, tardó 600ms y decidió llamar a la herramienta. Buena decisión. Pero lo que produjo con toda esa inteligencia es una cadena de consulta corta, básicamente una versión limpia de lo que el usuario acaba de escribir. Y para redactarla, se envió de nuevo todo el prompt de sistema.
Tareas del turnoTodas en el modelo grande
- Decidir que es necesaria la recuperación
- Escribir una consulta de búsqueda corta
- Escribir la respuesta final con los resultados
Lo que requiere cada unaSi eliges por paso
- Un clasificador, modelo diminuto
- Una reescritura, modelo pequeño
- Un modelo grande, y aquí es donde se justifica
Así que la ruta consiste en tres nodos en lugar de un agente.
Prepare retrieval query es una cadena de LLM básica en un modelo mini. Su prompt de sistema: a partir del mensaje del usuario, formula la consulta corta y concisa para enviar a la herramienta de recuperación de conocimientos y devuélvela directamente como una pregunta. En mis pruebas, el modelo pequeño escribió la misma consulta que el grande.
RAG via Lookio es una solicitud HTTP simple. La consulta va en el cuerpo; el ID del asistente y el modo son valores fijos que yo elegí en lugar de parámetros que un modelo pueda alterar. La mayoría de las herramientas que conectas a un agente son una API por debajo, y la plataforma suele darte el nodo listo para pegar.
Write the final response recibe el mensaje original y el contenido recuperado, etiquetados, y redacta la respuesta. Este paso se mantiene en el modelo grande, porque la redacción de la respuesta final es donde se nota la calidad.
Ahora la memoria corre de tu cuenta
Esta es la parte que el agente hacía por ti y la parte que tienes que reintegrar.
Un nodo de agente toma un subnodo de memoria y lo gestiona. Al dividir el agente en pasos, ya nada lo hace, por lo que la conversación se carga una vez al principio y se guarda una vez al final.
- Buscar mensajes anterioresGestor de memoria en modo carga, justo después del triggeruna vez
- Cada prompt lo añadeEl router, la respuesta simple y los dos pasos de recuperación reciben el historial×4
- Respond to ChatLa respuesta vuelve al usuario
- Guardar mensajesGestor de memoria en modo inserción: el mensaje del usuario y la respuestauna vez
Requiere más trabajo. También es el momento en que notas que un agente estaba metiendo toda la conversación en cada turno, y que un paso de reescritura de consultas necesita los dos últimos mensajes en lugar de los últimos veinte.
Lo que ganas a cambio
AgenteDecide en tiempo de ejecución
- Modelo grande en cada turno, sea saludo o no
- Prompt del sistema y descripciones de herramientas en cada llamada
- Puede saltarse una herramienta y responder basándose en su memoria
- Puede reordenar los pasos y te enteras en producción
Pasos explícitosDecidido en tiempo de compilación
- Modelo grande en un nodo de cada cinco
- Sin descripciones de herramientas en ninguna parte
- La recuperación siempre se ejecuta, porque es un paso
- El orden es el orden que has dibujado
Lo que más me importa es la tercera línea. Que un agente se salte una herramienta y responda basándose en lo que cree saber es el tipo de fallo que no puedes reproducir ni testear. Un flujo de trabajo no puede hacer eso. El nodo está ahí, se ejecuta.
Cuándo sigo recurriendo a un agente
Cuando realmente no conozco el orden. Investigaciones abiertas, donde la segunda consulta depende de lo que haya encontrado la primera. Cualquier caso donde el número de pasos no se pueda conocer de antemano.
Esa es la prueba que utilizo ahora: ¿puedo dibujar esto en un papel antes de que se ejecute? Si puedo, el agente me está costando un modelo para redescubrir mi dibujo en cada petición.
La misma pregunta, un nivel más arriba
Este es el hábito que se transfiere. Cuando estoy en Claude Code o Codex, mucho de lo que hago tiene la misma estructura que aquel bot de soporte, y las partes costosas son las mismas: todo el contexto volviendo a entrar para un paso que solo necesitaba una fracción, un modelo redescubriendo algo que yo ya sabía.
Saber cuánto cuesta una llamada a una herramienta, porque una vez conectaste una a mano y vigilaste el recuento de tokens, es lo que te permite verlo ocurrir dentro de un entorno que casi no te muestra nada.
Abre tus propios agentes y mira las ejecuciones. En cada una, pregúntate si podrías haber dibujado los pasos tú mismo antes de que se ejecutaran. En la mayoría de los míos, podría.