# La falacia de la autonomía total: 7 patrones para diseñar agentes de IA > Se venden agentes de IA que lo hacen todo solos. En producción, el bucle libre es caro, difícil de auditar y propenso a no terminar. Siete patrones de control, del más simple al agente autónomo, y por qué casi siempre gana el más simple que resuelve el problema. - Fuente canónica: https://www.ricardovelit.com/blog/p/patrones-de-diseno-de-agentes-de-ia - Nivel: intermedio · Lectura: 8 min · Publicado: 2026-09-23 - Etiquetas: agentes, arquitectura, patrones, workflows, produccion - Conviene leer antes: [agentes-de-inteligencia-artificial](https://www.ricardovelit.com/blog/p/agentes-de-inteligencia-artificial.md) - Relacionados: [temperatura-y-muestreo](https://www.ricardovelit.com/blog/p/temperatura-y-muestreo.md), [que-son-los-embeddings](https://www.ricardovelit.com/blog/p/que-son-los-embeddings.md), [sistemas-multiagente](https://www.ricardovelit.com/blog/p/sistemas-multiagente.md) - Contiene componentes interactivos que solo funcionan en la versión web. --- ## La promesa y la factura El discurso sobre agentes de inteligencia artificial tiene una dirección única: más autonomía es mejor. Un agente que planifica, ejecuta, se corrige y termina sin que nadie lo toque. La demo es impresionante. La factura llega después, y tiene tres partidas: - **Coste.** Cada vuelta del bucle reenvía todo el contexto acumulado. En un bucle de *n* pasos, los tokens de entrada no crecen como *n* sino aproximadamente como *n²*: la vuelta 10 relee las nueve anteriores. La caché de prompts abarata la factura, pero no acorta el contexto. - **Terminación.** Un agente que no encuentra la salida no lo sabe. Reintenta la misma herramienta con argumentos casi idénticos, o alterna entre dos estrategias, hasta que lo para un límite. Si no hay límite, lo para la tarjeta de crédito. - **Auditoría.** Cuando algo sale mal, "el modelo decidió llamar a esta herramienta en el paso 14" no es una explicación que acepte un auditor, un cliente o un juez. La falacia no es que los agentes no funcionen. Es tratar la autonomía como un **objetivo** cuando es un **coste**: algo que se paga en dinero, latencia y control, y que solo compensa cuando no hay otra forma de resolver el problema. ## El principio: el patrón más simple que funcione El mejor resumen de esto lo publicó Anthropic en *Building effective agents* (diciembre de 2024), a partir de lo que vieron en decenas de equipos: los sistemas que funcionaban no usaban los marcos más complejos, sino **patrones simples y componibles**. Y separaban dos cosas que el mercado mezcla: Un **workflow** es un sistema donde los modelos y las herramientas se orquestan por caminos que escribiste de antemano. Un **agente** es un sistema donde el modelo dirige su propio proceso y decide qué herramientas usar y cuándo. El workflow cambia flexibilidad por previsibilidad; el agente, al revés. La regla es subir de escalón solo cuando el escalón anterior demostradamente no basta. Estos son los siete escalones, en orden de autonomía creciente. ## 1. El LLM aumentado Una sola llamada a un modelo que puede usar herramientas, recuperar información y leer una memoria. No hay bucle: el modelo recibe, quizá llama a una herramienta, y responde. ```text entrada → [modelo + herramientas + recuperación] → salida ``` **Cuándo basta:** muchas más veces de las que parece. Clasificar un ticket, extraer campos de una factura, responder con [RAG](/p/rag-recuperacion-aumentada). Si una llamada bien diseñada lo resuelve, todo lo que viene después es sobreingeniería. ## 2. Encadenamiento de prompts (prompt chaining) La tarea se parte en pasos fijos, y la salida de cada uno es la entrada del siguiente. Entre paso y paso puede haber una **compuerta**: una comprobación en código que detiene la cadena si algo no cuadra. ```text borrador → [¿cumple el formato?] → traducción → [¿longitud dentro del límite?] → publicación ``` **Cuándo:** la tarea se descompone limpiamente en subtareas que siempre son las mismas. Cada llamada es más fácil que una sola gigante, y por eso más fiable. **Coste:** latencia, una llamada por paso. **Ventaja decisiva:** cada eslabón se prueba por separado. ## 3. Enrutamiento (routing) Un primer paso clasifica la entrada y la manda al camino especializado que le corresponde: su propio prompt, sus propias herramientas, incluso un modelo distinto. ```text ┌→ facturación (prompt + herramientas de cobro) entrada → router ┼→ soporte (prompt + base de conocimiento) └→ ventas (prompt + CRM) ``` Aquí entran los [embeddings](/p/que-son-los-embeddings). Hay dos formas de construir el router: | Router | Cómo decide | A favor | En contra | | --- | --- | --- | --- | | **Por LLM** | Un modelo lee la entrada y elige una categoría | Entiende matices y casos raros | Una llamada más, y no determinista | | **Por embeddings** | Se compara el vector de la entrada con el vector medio de ejemplos de cada categoría | Milisegundos, barato, siempre da lo mismo | Solo ve parecido, no razona | El router por embeddings es la misma operación que la búsqueda semántica: similitud coseno. Y como en la búsqueda, lo importante es el **umbral**: si la entrada no se parece lo bastante a ninguna categoría, no se fuerza la más cercana; se deriva a un camino por defecto o a una persona. Un router sin umbral siempre elige algo, también cuando no debería. **Cuándo:** entradas de tipos claramente distintos que se tratan mejor por separado. Además permite mandar lo fácil a un modelo pequeño y barato, y lo difícil a uno grande. ## 4. Paralelización Varias llamadas a la vez sobre la misma entrada, y un paso final que combina. Tiene dos variantes: - **Por secciones:** cada llamada hace una parte distinta. Una responde al usuario mientras otra comprueba si la pregunta es un intento de manipulación. - **Por votación:** varias llamadas hacen la misma tarea y se toma la mayoría. Cinco revisiones independientes de un fragmento de código encuentran más que una. **Cuándo:** subtareas independientes, o decisiones donde conviene más de una opinión. **Coste:** más tokens, misma latencia. ## 5. Orquestador y trabajadores Un modelo orquestador recibe la tarea, **decide en tiempo de ejecución** en qué subtareas partirla, se las reparte a trabajadores y combina los resultados. La diferencia con la paralelización es que las subtareas no están escritas de antemano. Tiene un primo más predecible, el **planificador-ejecutor**: el modelo escribe primero el plan completo, un humano o una comprobación lo valida, y después se ejecuta paso a paso sin volver a planificar salvo que algo falle. Planificar una vez en lugar de en cada vuelta ahorra llamadas y, sobre todo, deja un plan escrito que se puede auditar antes de que nada toque el mundo. **Cuándo:** tareas cuya estructura depende de la entrada, como un cambio de código que afecta a un número de archivos que no conoces hasta mirar. ## 6. Evaluador y optimizador Un modelo genera; otro evalúa contra criterios explícitos y devuelve comentarios; el primero corrige. Se repite hasta que el evaluador aprueba o se acaba el presupuesto. ```text generador → borrador → evaluador → ¿aprobado? → sí: salida ↑ │ └──── comentarios ────────┘ no (máximo 3 vueltas) ``` **Cuándo:** hay criterios claros de calidad y la iteración mejora el resultado de forma medible. Es un bucle, pero un bucle con juez y con salida garantizada. Es la semilla de los agentes con verificador que desarrollo en [sistemas multiagente](/p/sistemas-multiagente). ## 7. El agente autónomo El bucle abierto: el modelo decide cada paso, usa las herramientas que quiere y termina cuando cree que ha terminado. Es el único patrón donde ni la estructura ni la duración están escritas en ningún sitio. **Cuándo:** problemas abiertos donde es imposible prever cuántos pasos hacen falta, el entorno da una señal objetiva de éxito en cada vuelta, y un intento fallido es barato. Los agentes de programación son el ejemplo canónico: el compilador y los tests le dicen al agente, en cada paso, si va bien. **Cuándo no:** casi todo lo demás. ## La tabla que conviene tener delante | Patrón | Quién decide el siguiente paso | Coste | Predecible | Auditable | | --- | --- | --- | --- | --- | | LLM aumentado | Nadie: no hay siguiente paso | Muy bajo | Alta | Alta | | Encadenamiento | Tu código | Bajo | Alta | Alta | | Enrutamiento | Tu código, tras una clasificación | Bajo | Alta | Alta | | Paralelización | Tu código | Medio | Alta | Alta | | Orquestador | El modelo, una vez | Medio-alto | Media | Media | | Evaluador-optimizador | El evaluador, con tope | Medio-alto | Media | Alta | | Agente autónomo | El modelo, en cada vuelta | Alto y variable | Baja | Baja | Los cuatro primeros son workflows. Nota dónde cae la línea: en la columna "predecible" todos dicen "alta". Por eso resuelven la mayoría de casos reales. ## El no determinismo dentro de un bucle Un modelo no elige su respuesta: la **muestrea**. Lo explico en [temperatura y muestreo](/p/temperatura-y-muestreo). En una llamada aislada, esa varianza es un matiz. Dentro de un bucle es otra cosa, porque cada decisión cambia el contexto de la siguiente: una elección distinta en el paso 2 lleva a una herramienta distinta en el paso 3 y a un camino entero distinto en el paso 10. Dos ejecuciones del mismo agente con la misma entrada pueden no parecerse en nada. La tentación es bajar la temperatura a 0. No alcanza, por dos motivos: 1. **Temperatura 0 no es determinismo real.** Con el mismo prompt, la infraestructura que sirve el modelo puede producir diferencias numéricas mínimas que cambian un token, y un token distinto al principio del bucle es un camino distinto al final. 2. **En los modelos más recientes ya no puedes tocarla.** Como cuento en el artículo de temperatura, Opus 5 y Sonnet 5 no aceptan el parámetro: lo que se ajusta es el esfuerzo de razonamiento. La conclusión es de diseño, no de parámetros: **la previsibilidad tiene que venir de la estructura**. Cada paso que fijas en código es un paso que no se sortea. Esa es la razón técnica, y no solo de coste, por la que un workflow sobre raíles es más fiable que un agente libre. ## Pruébalo: un router en una llamada El patrón 3 en su forma más pequeña. Cambia la petición del cliente y mira si la categoría cambia con ella. Luego prueba con una petición que no encaje en ninguna: ese es el caso que un router sin umbral resuelve mal. > **[Componente interactivo: PromptPlayground]** — playground de prompts: ejecuta un prompt contra un modelo real o simulado. Solo en la versión web: https://www.ricardovelit.com/blog/p/patrones-de-diseno-de-agentes-de-ia ## Si al final necesitas un agente: gobiérnalo Llegar al escalón 7 no significa soltar el volante. Los agentes que están en producción comparten las mismas reglas de gobierno: - **Presupuesto de pasos y de tokens.** Un máximo duro de vueltas y de gasto por tarea. Al agotarse, el agente se detiene y lo dice. - **Lista cerrada de herramientas.** Solo las que la tarea necesita. Cada herramienta de más es una decisión de más que el modelo puede tomar mal. - **Aprobación humana para lo irreversible.** Leer, libre. Escribir, borrar, pagar o enviar, con confirmación. - **Detección de bucles.** Si el agente llama a la misma herramienta con los mismos argumentos dos veces seguidas, algo va mal. - **Trazas completas.** Cada decisión, con su contexto, su herramienta y su resultado. Sin trazas no hay auditoría, y sin auditoría no hay cliente serio. ## Para llevarte - La autonomía de un agente de IA es un coste, no una virtud. Se paga en tokens, latencia y control. - Hay siete patrones entre una llamada y un agente libre. Los cuatro primeros son workflows y resuelven la mayoría de casos reales. - En un bucle, el no determinismo del muestreo se acumula. La previsibilidad se consigue con estructura, no con la temperatura. - Sube de escalón solo cuando el anterior falle de forma demostrable, y si llegas al último, ponle límites.