Diseño de flujos de trabajo de IA: cinco patrones para procesos de agentes de varios pasos

Conclusiones clave

• Las llamadas a herramientas MCP a través de OpenAI alcanzaron 98 veces su nivel de enero en agosto de 2026, más que duplicándose solo en agosto (AAIF) — una única petición de usuario desencadena ahora un flujo de trabajo de muchas llamadas, lo que hace que el diseño de flujos, y no el diseño de prompts, sea la disciplina de producción.
• Gartner predice que los costes de inferencia de IA por flujo de trabajo agéntico aumentarán más de cinco veces hasta 2028 — los precios por token caen mientras los costes por flujo suben, porque los flujos de trabajo agénticos consumen órdenes de magnitud más tokens que el chat.
• La hoja de ruta de MCP convirtió Tasks en una extensión oficial (SEP-2663) y añadió Multi Round-Trip Requests (SEP-2322) para que los flujos de varios pasos sobrevivan en servidores sin estado — el protocolo ahora asume que el trabajo se ejecuta durante mucho tiempo y abarca varias rondas.
• OpenAI declara que sus monitores de desalineación pueden pausar "tareas en las que un agente se ejecuta durante un periodo prolongado", y las tareas de la API se detienen en lugar de reanudarse — un flujo de trabajo de producción debe ser reanudable desde estado durable, no desde un proceso vivo.
• Un módulo de RFQ de 38 herramientas ejecuta todos estos patrones en código — transiciones de estado aplicadas por guards, liberación idempotente de reservas con un TTL de 15 minutos, y snapshots de FX congelados al presupuestar.

Las llamadas a herramientas MCP de los usuarios de ChatGPT alcanzaron 98 veces su nivel de enero en agosto de 2026, según el análisis de uso de la Agentic AI Foundation — y las llamadas se más que duplicaron durante agosto alone. El tráfico MCP de Resend cuenta la misma historia desde el lado del proveedor: 106.719 llamadas en abril, 1.062.650 en agosto. Los propios mantenedores del protocolo extraen la conclusión operativa en el nuevo roadmap de MCP: "Las cargas de trabajo agénticas modernas ya no encajan en el patrón estándar de petición y respuesta. Los bucles pueden ejecutarse durante más tiempo, los servidores pueden enviar resultados en streaming y hay una necesidad clara de dirigir el trabajo en pleno vuelo."

El chat nunca fue la parte difícil. El flujo de trabajo lo es: el abanico de consultas a catálogos detrás de una RFQ, la aprobación que debe llegar antes de una escritura en el ERP, la API del proveedor que se agota a mitad de presupuesto, la tasa de divisa que no debe derivar entre el precio y la reserva. Gartner proyecta que los costes de inferencia por flujo de trabajo subirán más de cinco veces hasta 2028 incluso cuando los precios por token caen, porque los flujos de trabajo agénticos razonan, negocian y se vuelven a cuestionar a lo largo de muchas llamadas. Este artículo define los cinco patrones a nivel de flujo que deciden si un proceso de agente de varios pasos aguanta esa carga — fan-out, checkpoints, compensación, estado durable y ramificación medida — y ancla cada uno en una implementación de RFQ en funcionamiento que registra 38 herramientas MCP contra un backend GraphQL.

El flujo de trabajo es la unidad que diseñas. El diagrama siguiente comprime los cinco patrones en un minuto: el fan-out paralelo de lecturas, la columna vertebral serializada de escrituras con sus dos compuertas humanas, la compensación tipada ante un fallo y la regla de estado durable que los une.

Patrón 1: Fan-out de lecturas, escrituras en serie

La primera decisión de flujo es la forma del grafo de dependencias. La mayoría de los procesos de agentes de varios pasos son mayormente paralelos: una RFQ necesita tramos de precio de tres catálogos de proveedores, disponibilidad por lotes de cinco líneas de pedido y el segmento del cliente — nada de lo cual depende de los demás. Serializar esos pasos multiplica la latencia por el número de pasos y multiplica el radio de impacto de cualquier timeout. El valor por defecto correcto es lanzar en paralelo cada lectura independiente y serializar solo la cadena de escritura, donde cada paso consume la salida del paso anterior.

La cadena de escritura en un flujo de presupuestación está estrictamente ordenada por una razón de negocio, no técnica: petición confirmada → presupuesto creado → disponibilidad reservada → plazos programados. Nuestro motor de RFQ lo aplica con operation guards en código — un RequestOperationGuard se niega a crear presupuestos desde una petición no confirmada, y un QuoteOperationGuard rechaza modificaciones de líneas una vez que el presupuesto pasa su ventana editable. El patrón de flujo es el mismo en todos los sistemas: lecturas paralelas detrás de un batch loader, una espina serializada estrecha para las escrituras que cambian estado, y los guards en código en lugar del prompt. Un agente que "decide" el orden en cada ejecución es un flujo sin invariantes.

Patrón 2: Los checkpoints humanos son estados, no prompts

El segundo patrón gobierna dónde se sitúa el humano. En un diseño basado solo en prompts, "pregunta al usuario antes de enviar" es una sugerencia que el modelo puede seguir o no. En un diseño de flujo, el checkpoint es un estado durable: el proceso se detiene en un estado con nombre, persiste todo lo necesario para continuar y solo una acción humana lo hace avanzar. La distinción se volvió operativamente urgente el 1 de septiembre, cuando OpenAI reveló que sus monitores de desalineación en producción pueden detener automáticamente actividad potencialmente no autorizada — y señaló honestamente el coste: las salvaguardas "pueden señalar ocasionalmente actividad legítima como posible mal uso cibernético... Esto puede incluir trabajo que no parece directamente relacionado con la ciberseguridad o tareas en las que un agente se ejecuta durante un periodo prolongado". En ChatGPT y Codex, se pide a los usuarios revisar la tarea pausada; en la API, la tarea se detiene.

Un flujo construido para ese mundo trata la pausa como un estado diseñado, no como una excepción: el registro de la ejecución muestra qué completó, qué está pendiente y cuál es el camino de reanudación. Las dos herramientas de conveniencia de nuestro motor de RFQ — confirm_request_and_create_quotes y confirm_quote_and_create_installments — existen precisamente porque la compuerta humana se sitúa entre ellas: un humano confirma, y luego el trabajo mecánico de varios pasos se ejecuta como una única llamada auditada. La encuesta de Camunda a 1.150 líderes sénior de TI encontró que el 71% de las organizaciones usan agentes de IA pero solo el 11% de los casos de uso llega a producción; los flujos que cruzan ese abismo son aquellos donde una aprobación es un estado en el que el sistema puede permanecer horas, no una frase en un system prompt. La mecánica de runtime para hacer cumplir los checkpoints vive en Loop Engineering: por qué el runtime del agente es el nuevo middleware; el patrón de flujo consiste en decidir, antes de que nada se publique, qué pasos se detienen ante un humano y desde qué estado se reanuda el proceso.

Patrón 3: Cada paso hacia adelante necesita un camino de compensación

El tercer patrón es el que los tutoriales omiten: qué deshace un paso. Los flujos de larga duración fallan en pleno vuelo — la API de un proveedor devuelve un error en la línea cuatro de cinco, una reserva expira mientras el agente presupuesta, un presupuesto se aprueba pero la programación del pago falla. Un flujo sin cadenas de compensación convierte cada fallo en limpieza manual. Un flujo con compensación convierte cada fallo en una operación inversa tipada e idempotente.

La implementación de presupuestación muestra la anatomía. Las reservas de disponibilidad expiran con un TTL de 15 minutos, y la superficie de fallo se enumera como errores tipados — HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT — cada uno mapeado a una recuperación distinta: re-verificar, re-adquirir o escalar a un humano. Liberar una reserva es idempotente, de modo que un reintento tras una partición de red no puede liberar dos veces, y confirmar una reserva nunca descuenta dos veces. Las llamadas a herramientas se envuelven en un decorador de reintentos con backoff exponencial, y el estado, la duración y el payload de cada llamada (descargado a almacenamiento de objetos por encima de 400KB) quedan en un registro de auditoría. Ese es el patrón generalizado: los pasos hacia adelante adquieren recursos; los pasos de compensación los liberan; cada compensación es segura de ejecutar dos veces. Si tu flujo no puede nombrar el deshacer de cada paso, no tiene un flujo de trabajo — tiene una demo que aún no se ha encontrado con una caída de proveedor.

Patrón 4: Protocolo sin estado, flujo de trabajo con estado

El cuarto patrón resuelve una contradicción aparente en la especificación MCP 2026-07-28. La especificación eliminó las sesiones a nivel de protocolo y el handshake de inicialización (SEP-2575, SEP-2567) para que los servidores escalen horizontalmente sin retener estado, y el roadmap convirtió Tasks en una extensión oficial (SEP-2663) mientras Multi Round-Trip Requests (SEP-2322) reemplazó las peticiones iniciadas por el servidor para que los flujos de elicitation sigan funcionando a mitad de tarea. El protocolo es sin estado; el flujo de trabajo es lo que transporta el estado. Concretamente: cada petición debe llegar autocontenida, y el estado del flujo vive en registros durables e inspeccionables — no en la memoria de un servidor.

Esa elección de arquitectura es la que hace sobrevivible el patrón anterior. En nuestro motor de RFQ, el hold_token y el hold_expires_at de la reserva están directamente en la línea del presupuesto, y la tasa de FX se congela con un timestamp fx_rate_locked_at al presupuestar — snapshots, no referencias vivas. Cualquier instancia de servidor puede tomar la siguiente petición; un proceso reiniciado se reanuda desde el registro, no desde la RAM. Y la advertencia de Astra hace de la reanudabilidad un requisito de interacción con la plataforma, no solo tolerancia a fallos: si la salvaguarda de un modelo frontera pausa tu ejecución desatendida de 38 horas, el flujo que sobrevive es el que mantuvo su estado fuera del proceso. Cubrimos la mecánica de despliegue de la especificación sin estado en El protocolo MCP sin estado: qué cambia para los despliegues B2B; a nivel de flujo, la regla es simple — diseña como si cualquier paso pudiera ser el último antes de una pausa, y haz que el siguiente paso sea reconstruible desde la pista de auditoría.

Patrón 5: Ramifica con datos medidos, no con juicio del modelo

El quinto patrón gobierna las ramas condicionales. Un flujo de varios pasos contiene puntos de decisión — ¿es esta línea suficientemente rentable para presupuestar, este lote se mueve lo bastante lento para marcarlo, este segmento de cliente desbloquea un tramo de descuento. Dejar que el modelo improvise esas ramas reintroduce varianza en el único lugar donde el comportamiento determinista importa. La respuesta del flujo son compuertas medidas: los datos llevan las banderas, y la rama las lee.

En el motor de RFQ, cada línea de presupuesto lleva guardrail_price_per_uom y slow_move_item cargados del registro por lotes — así la rama "presupuestar a precio de lista" frente a "marcar para revisión de margen" lee dos campos en lugar de pedirle al modelo que estime el margen. Las reglas de descuento se componen de cuatro ámbitos jerárquicos (global, segmento, artículo, artículo de proveedor) como datos, no como pasos de razonamiento. Aquí es también donde el diseño de flujo se encuentra con el coste: el análisis de inferencia de Gartner advierte que "dirigir una tarea a un modelo de razonamiento agéntico aumenta los costes de inferencia del proveedor al menos cinco veces" frente a una interacción básica, y recomienda "estratificación, enrutamiento y orquestación de inferencia altamente optimizados". Un flujo que ramifica sobre banderas almacenadas reserva el razonamiento del modelo para los pasos que lo necesitan — juicio de precios, interpretación de excepciones, redacción de negociación — y deja que los datos tipados decidan el resto. La misma disciplina aparece en las plataformas de datos, donde el trabajo de contexto de orquestación de Dagster trata los eventos de materialización como el contexto operativo que un flujo consume en lugar de re-derivar.

Los cinco patrones, en una línea cada uno

Fan-out de lecturas, escrituras en serie — la forma es un invariante de negocio, así que codifícala como guards. Los checkpoints son estados en los que el sistema puede permanecer, porque la propia plataforma te pausará. La compensación es un paso de primera clase para cada paso hacia adelante, idempotente por construcción. El estado vive en registros durables, no en el protocolo ni en el proceso. Las ramas leen banderas medidas, reservando el razonamiento del modelo para los pasos que lo pagan. Ninguno de estos patrones requiere una migración de framework; todos requieren decidir, por paso, quién lo posee — el modelo, el runtime o un humano.

Una construcción representativa

Un operador turístico de mercado medio que gestiona 200 RFQs de reserva de grupo por semana entre hoteles, vuelos y actividades reconstruyó su flujo de presupuestación sobre estos patrones. Las lecturas se lanzan en paralelo — cinco catálogos, disponibilidad por lotes, tramos de precio — a través de un único módulo MCP que expone 38 herramientas en 11 mixins de dominio, con el esquema de cada herramienta tipado y cada llamada auditada. La espina de escritura se serializa: petición confirmada, presupuesto ensamblado con FX congelado al presupuestar, reservas adquiridas con un TTL de 15 minutos y liberación idempotente, planes de plazos programados. Dos compuertas humanas se sitúan donde se compromete el dinero — confirmación de petición y confirmación de presupuesto — y cada compuerta es un estado persistido en el que el proceso puede esperar horas. Cuando la API de un proveedor se agota a mitad de presupuestación, el error tipado enruta la línea a re-verificación en lugar de corromper el presupuesto. El plazo de presupuesto pasó de tres días de búsquedas manuales a menos de cuatro horas, con cada escritura aprobada por humanos. El resultado es capacidad de presupuestación para un equipo reducido, no reemplazo de plantilla.

Lectura relacionada

• Arquitectura de Agentes de IA: Cinco Decisiones que Determinan si tu Agente Llega a Producción — las decisiones estructurales (número de agentes, propiedad del loop, enrutamiento de modelos, fronteras, coordinación emergente) que enmarcan qué patrones de flujo necesitas
• Loop Engineering: por qué el runtime del agente es el nuevo middleware — la mecánica de runtime detrás de los patrones 2 y 5: aprobaciones, reintentos y verificación con rúbricas aplicadas en el loop
• Patrones de agentes de larga duración: manteniendo agentes vivos durante horas y días — el detalle de persistencia y checkpointing detrás del patrón 4, incluido el nuevo riesgo de pausa por salvaguardas en ejecuciones prolongadas

---

Un equipo que puede dibujar su flujo de trabajo — el fan-out, las compuertas, las compensaciones, el estado — ya sabe qué construir. Un equipo que no puede descubrirá el diseño una caída de proveedor cada vez.

Solicita una construcción con alcance definido. Discovery de una semana. Obtienes un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — tanto si construyes con nosotros como si no.