---
title: "La mayoría de los agentes de IA no deberían ser agentes"
description: "En unos pocos meses, reduje el número de agentes en mis flujos de trabajo de producción en unos cinco. Lo que los sustituyó: un modelo diminuto que enruta la solicitud, los pasos definidos en lugar de decididos en tiempo de ejecución y la memoria de la conversación cargada y almacenada manualmente. Aquí está el esquema."
date: 2025-10-29
language: es
canonical: https://gduv.club/es/articles/ai-workflows-instead-of-agents
source: gduv.club
---
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 99% de los agentes de IA no deberían existir. Haz esto en su lugar (+ fiable, más rápido, más barato)!](https://www.youtube.com/watch?v=BHdJFnx2wrc)

## 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 IA** (gpt-4.1, Modelo de chat: Modelo de chat de OpenAI (gpt-4.1); Memoria: Memoria simple; Herramienta: Consultar base de conocimientos (Solicitud HTTP. El agente redacta la consulta y decide cuándo llamarla))

_Cuatro nodos. Es realmente rápido de construir, que es la razón principal por la que esta estructura es tan común._

## 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.

| Step | What happens | Cost |
| :--- | :--- | ---: |
| Llega el mensaje | "hola" | 1 token |
| Entra el prompt del sistema completo | Cada descripción de herramienta, cada regla sobre cuándo llamar a qué | todo |
| El modelo grande decide | Decide no llamar a nada |  |
| El modelo grande responde | "Hola, ¿en qué puedo ayudarte hoy?" |  |

_Mi prompt aquí era ligero. Con cinco herramientas conectadas y el orden en que deben llamarse detallado, la fila central es donde reside la mayor parte de la factura._

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 anteriores** (Gestor de memoria, modo carga, Memory: Memoria simple) → **Enrutador de intención** (Clasificador de texto, dos categorías, Chat Model: Modelo muy pequeño (gpt-4.1-nano))

- _no se requiere recuperación de conocimiento_ → **Respuesta simple** (Cadena LLM básica con el mismo modelo diminuto)

- _se requiere recuperación de conocimiento_ → **Preparar consulta de recuperación** (Cadena LLM básica, gpt-4.1-mini) → **RAG vía Lookio** (Solicitud HTTP simple. Sin modelo en este paso) → **Escribir la respuesta final** (Cadena LLM básica, gpt-4.1. El único modelo grande en el lienzo)

**Responder al chat** → **Almacenar mensajes** (Gestor de memoria, modo inserción)

_Tres modelos en el lienzo, cada uno dimensionado para su propio paso. El grande se ejecuta exactamente en un nodo y solo en los mensajes que llegan a él._

### 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ó.

**El router necesita la conversación o interpretará mal los seguimientos**

"¿Y para el segundo punto?" requiere recuperación y, por sí solo, parece una charla trivial. Por eso, al prompt del clasificador se le añaden los mensajes anteriores, formateados como líneas `human:` y `ai:`, con la instrucción de centrarse en el nuevo mensaje y tratar el resto como contexto. Sin esto, las preguntas de seguimiento se dirigen a la ruta económica y el bot responde sin información.

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 turno** (Todas 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 una** (Si eliges por paso)

- Un clasificador, modelo diminuto
- Una reescritura, modelo pequeño
- Un modelo grande, y aquí es donde se justifica

_Solo la última se beneficia del modelo costoso; en la estructura de agente, las tres se ejecutan en él._

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.

| Step | What happens | Cost |
| :--- | :--- | ---: |
| Buscar mensajes anteriores | Gestor de memoria en modo carga, justo después del trigger | una vez |
| Cada prompt lo añade | El router, la respuesta simple y los dos pasos de recuperación reciben el historial | ×4 |
| Respond to Chat | La respuesta vuelve al usuario |  |
| Guardar mensajes | Gestor de memoria en modo inserción: el mensaje del usuario y la respuesta | una vez |

_Más cableado que un subnodo de memoria, pero el mismo búfer subyacente. A cambio, puedes ver, paso a paso, exactamente cuánto historial recibió cada etapa._

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

**Agente** (Decide 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ícitos** (Decidido 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

_La predictibilidad es lo que hace un año habría clasificado al final y ahora clasifico primero._

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.

## Fuentes

- [n8n: Nodo Text Classifier](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.text-classifier/)
- [n8n: Nodo Basic LLM Chain](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.chainllm/)
- [n8n: Nodo Chat Memory Manager](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.memorymanager/)
- [OpenAI: precios de modelos](https://openai.com/api/pricing/)