La falacia de la autonomía total: 7 patrones para diseñar agentes de IA

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.

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

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.

                ┌→ facturación   (prompt + herramientas de cobro)
entrada → router ┼→ soporte       (prompt + base de conocimiento)
                └→ ventas        (prompt + CRM)

Aquí entran 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.

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.

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

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

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.