Cada equipo que construye agentes de IA se topa con el mismo muro.
Empiezas con un prompt y unas cuantas herramientas.
Funciona.
Luego los requisitos crecen. Más casos límite. Más equipos. Más riesgo.
De repente, tu "agente" es un prompt de sistema de 3000 palabras intentando hacer cinco trabajos a la vez.
La solución no es más ingeniería de prompts.
Es elegir el patrón correcto.
Aquí están los 15 patrones con los que se construye todo sistema agéntico en producción — y exactamente cuándo usar cada uno.
Antes de elegir un patrón
No toda tarea necesita un agente.
Una tarea justifica un agente cuando:
→ Una sola llamada al modelo no puede producir un resultado fiable
→ El modelo debe elegir entre herramientas o fuentes de datos en tiempo de ejecución
→ La tarea necesita planificación, validación o refinamiento iterativo
→ El flujo de trabajo tiene una incertidumbre real que no se puede hardcodear
Una tarea normalmente NO necesita un agente cuando el camino de entrada a salida es predecible.
Resúmenes. Clasificación. Extracción simple. Generación con plantillas.
Estas son más rápidas, más baratas y más fiables como llamadas directas al modelo.
Envolverlas en un agente solo añade latencia y puntos de fallo sin ningún beneficio.
PATRÓN 1 — Agente Único
El punto de partida más simple y común.
Un modelo. Un prompt de sistema. Un conjunto acotado de herramientas.
El modelo decide qué herramienta llamar, observa el resultado y continúa hasta tener suficiente para responder.
Ejemplo real: Un agente de atención al cliente que consulta el estado de un pedido, verifica el envío y crea un ticket si no puede resolver el problema — todo con 2 o 3 herramientas y un trabajo claro.
Úsalo cuando: la tarea está bien definida, el conjunto de herramientas es pequeño y un solo agente puede mantener el contexto completo sin confundirse.
Se rompe cuando: sigues añadiendo herramientas y el prompt de sistema crece más de una página. Esa es la señal de que necesitas un patrón diferente — no un prompt más largo.
PATRÓN 2 — Multi-Agente Secuencial
Agentes especializados se ejecutan en un orden fijo. La salida de cada uno alimenta la entrada del siguiente.
Ejemplo real: Un pipeline de revisión de contratos — un agente extrae las obligaciones, el siguiente identifica los riesgos, un tercero redacta el resumen para adquisiciones. La secuencia nunca cambia.
Úsalo cuando: el flujo de trabajo tiene etapas claras y repetibles, y cada etapa produce exactamente lo que la siguiente necesita.
Se rompe cuando: el orden realmente necesita variar según lo que se descubre a mitad del proceso. Los pipelines secuenciales asumen que la ruta es fija — si no lo es, necesitas algo más dinámico.
PATRÓN 3 — Multi-Agente Paralelo
Subtareas independientes se ejecutan simultáneamente y luego se combinan en una sola vista.
Ejemplo real: Un incidente de producción a las 2 a.m. Tres agentes investigan logs, métricas y despliegues recientes al mismo tiempo — no uno tras otro — porque cada minuto importa durante una caída.
Úsalo cuando: las subtareas son genuinamente independientes y la velocidad importa.
Se rompe cuando: las tareas realmente dependen de los resultados de otras. Forzar trabajo dependiente a ejecución paralela solo crea condiciones de carrera y contexto incompleto.
PATRÓN 4 — Bucle
Repite una secuencia de pasos hasta que se cumple una condición de salida.
Ejemplo real: Un agente de limpieza de datos que perfila datos CSV desordenados, propone un plan de limpieza, verifica si pasa los estándares de calidad y lo reintenta si no es así — hasta un número máximo de rondas.
Úsalo cuando: la tarea necesita múltiples intentos y puedes definir una condición de parada clara y verificable.
Se rompe cuando: no hay una condición de salida fiable. Sin ella, obtienes costes descontrolados y un sistema que quizás nunca termine.
PATRÓN 5 — Revisión y Crítica
Un agente juez revisa la salida de otro agente, la critica y da comentarios accionables específicos.
Ejemplo real: Un informe generado es revisado por un agente "crítico" independiente que señala afirmaciones débiles, evidencia faltante o secciones poco claras antes de que llegue a un humano.
Úsalo cuando: la calidad importa más que la velocidad y quieres una segunda opinión integrada en el sistema, no añadida después.
Se rompe cuando: el agente crítico tiene los mismos puntos ciegos que el generador. Un revisor entrenado con supuestos similares no detectará los mismos errores.
PATRÓN 6 — Refinamiento Iterativo
Un bucle de retroalimentación con un umbral de puntuación de calidad. El generador sigue refinando hasta superar la barrera.
Ejemplo real: Un generador de textos de marketing que puntúa su propio borrador contra las directrices de la marca y sigue reescribiendo hasta alcanzar una puntuación mínima de calidad — no solo una comprobación de aprobado o suspenso, sino una mejora gradual.
Úsalo cuando: la calidad de salida es genuinamente variable y "suficientemente bueno" tiene un umbral medible.
Se rompe cuando: la función de puntuación es vaga o manipulable. Si el modelo puede inflar su propia puntuación sin una mejora real, el bucle solo quema tokens.
PATRÓN 7 — Coordinador
Un agente de enrutamiento central dirige las solicitudes a agentes especializados según lo que realmente se pregunta.
Ejemplo real: Los tickets de soporte se enrutan a especialistas en facturación, técnico, cuentas, envíos o fraude — cada uno con contexto reducido en lugar de un solo agente intentando saberlo todo.
Úsalo cuando: tienes tipos de solicitudes genuinamente diferentes que necesitan contexto, herramientas o lógica de decisión distintos.
Se rompe cuando: el propio enrutamiento se vuelve ambiguo. Si las solicitudes no encajan claramente en una categoría, el coordinador se convierte en un nuevo cuello de botella y fuente de desvíos incorrectos.
PATRÓN 8 — Descomposición Jerárquica de Tareas
Un agente raíz divide un objetivo complejo en subobjetivos más pequeños, los delega a trabajadores especializados y luego sintetiza todo en una respuesta.
Ejemplo real: "¿A qué 3 países deberíamos expandirnos el próximo año?" se divide en análisis competitivo, investigación regulatoria, viabilidad logística y dimensionamiento de mercado — cada uno manejado por un especialista diferente, luego se combina.
Úsalo cuando: el problema es demasiado amplio para un solo pase de razonamiento pero se divide limpiamente en áreas de especialización independientes.
Se rompe cuando: los subobjetivos no son realmente independientes. Si los flujos de trabajo necesitan informarse entre sí en tiempo real, descomponerlos al principio pierde esa interacción.
PATRÓN 9 — Enjambre
Múltiples agentes especialistas contribuyen a una discusión compartida, desafían las suposiciones de los demás y un facilitador sintetiza una recomendación final.
Ejemplo real: ¿Debería la empresa lanzar un nivel de suscripción? Los agentes de investigación, ingeniería, finanzas y soporte argumentan cada uno su perspectiva a lo largo de múltiples rondas antes de que un facilitador sopese las compensaciones.
Úsalo cuando: no hay una única respuesta "correcta" — necesitas una decisión bien razonada moldeada por puntos de vista genuinamente contrapuestos.
Se rompe cuando: necesitas una respuesta rápida y determinista. Los enjambres son deliberadamente lentos y exploratorios — herramienta equivocada si necesitas velocidad.
PATRÓN 10 — ReAct (Razonar y Actuar)
El agente alterna entre razonamiento y acción: decide qué investigar, llama a una herramienta, observa el resultado, decide si ya hay suficiente evidencia.
Ejemplo real: "El procesador de colas parece atascado" — el agente busca en la documentación, verifica el estado del servicio, correlaciona los hallazgos y solo entonces sugiere una solución. La ruta de investigación no está predefinida; depende de lo que encuentre en el camino.
Úsalo cuando: la ruta hacia la respuesta genuinamente no se puede planificar de antemano — depende de lo que revele cada paso.
Se rompe cuando: las investigaciones se alargan sin converger. Siempre limita el número de ciclos de razonamiento-acción, o corres el riesgo de una exploración infinita.
PATRÓN 11 — Humano en el Bucle
El agente investiga y recomienda, pero un humano toma la decisión final sobre cualquier cosa arriesgada o ambigua.
Ejemplo real: Aprobaciones de reembolsos — los casos de bajo riesgo y claros se automatizan. Los importes altos, señales de fraude o excepciones de política se pausan para revisión humana antes de finalizar cualquier cosa.
Úsalo cuando: la decisión conlleva un riesgo financiero, legal o de reputación real y la automatización completa aún no es aceptable.
Se rompe cuando: tratas esto solo como una característica de interfaz en lugar de algo arquitectónico. Necesitas estado durable, asignación de revisores, manejo de tiempos de espera y rutas de escalado — no solo un botón de "pausa".
PATRÓN 12 — Planificar y Ejecutar
Un agente planificador crea un plan estructurado completo por adelantado — revisable y modificable — antes de tomar cualquier acción. Luego un ejecutor recorre los pasos.
Ejemplo real: "Redimensionar el grupo de workers de 10 a 20 instancias, verificar que la cola se vacíe, actualizar el runbook." El plan completo es visible antes de que comience la ejecución, a diferencia de ReAct donde la ruta surge paso a paso.
Úsalo cuando: quieres que el plan sea revisable o aprobable antes de que ocurra cualquier acción — importante para operaciones con consecuencias reales.
Se rompe cuando: el entorno cambia más rápido de lo que el plan puede ejecutarse. Un plan obsoleto ejecutado a ciegas es peor que ningún plan.
PATRÓN 13 — Reflexión
El agente evalúa sus propios fallos, reflexiona sobre lo que salió mal y lleva esa memoria al siguiente intento.
Ejemplo real: Un agente de generación de código escribe un script, falla en tiempo de ejecución, el agente analiza el error real, registra qué corregir y lo reintenta — volviéndose más inteligente con cada intento en lugar de repetir el mismo error.
Úsalo cuando: los fallos son informativos y la autocorrección mejora genuinamente el siguiente intento.
Se rompe cuando: los modos de fallo son aleatorios o no están relacionados entre sí. La reflexión solo ayuda cuando hay un patrón real del que aprender.
PATRÓN 14 — Lógica Personalizada
Un híbrido: el código determinista maneja las reglas que nunca deben fallar, mientras que el modelo maneja el juicio, la redacción y el manejo de excepciones.
Ejemplo real: Un flujo de trabajo de reembolsos donde la verificación de compra y las comprobaciones de fraude se ejecutan como reglas deterministas estrictas — nunca delegadas al modelo — mientras que redactar la respuesta al cliente y las recomendaciones de enrutamiento siguen siendo agénticas.
Úsalo cuando: el flujo de trabajo tiene lógica de ramificación real con consecuencias legales o financieras, y necesitas ser preciso sobre qué es determinista versus qué es flexible.
Se rompe cuando: los equipos difuminan la línea y dejan que el modelo tome decisiones que deberían ser reglas hardcodeadas. La elegibilidad, los permisos y los movimientos de dinero nunca deberían ser solo decisión del modelo.
PATRÓN 15 — Agente Dirigido por Eventos
El agente no espera a que le pregunten. Se suscribe a un flujo de eventos y actúa en el momento en que se activa una condición.
Ejemplo real: Un agente de detección de fraude que reacciona al instante cuando se dispara un evento de transacción sospechosa — no cuando un ticket de soporte finalmente lo saca a la luz, momento en el que el daño ya está hecho.
Úsalo cuando: el tiempo importa más que cualquier otra cosa, y esperar una solicitud humana significa perder la ventana para actuar.
Se rompe cuando: las condiciones de activación están mal definidas. Un flujo de eventos ruidoso con disparadores vagos se convierte en un sistema que grita "al lobo" constantemente — o peor, que pierde la señal real.
Selección de patrón — empareja la incertidumbre, no el hype
El patrón correcto se ajusta a la forma de la incertidumbre en tu trabajo:
→ Incierto sobre qué herramienta usar → Agente Único o ReAct
→ Incierto sobre dónde enrutar → Coordinador
→ Incierto sobre la calidad → Revisión y Crítica o Refinamiento Iterativo
→ Incierto sobre la ruta de ejecución → Planificar y Ejecutar o ReAct
→ Incierto sobre cómo autocorregirse → Reflexión o Bucle
→ Incierto sobre el riesgo de negocio → Humano en el Bucle o Lógica Personalizada
→ Incierto sobre la estructura del problema → Descomposición Jerárquica o Enjambre
→ No puedes esperar una solicitud → Agente Dirigido por Eventos
Un enjambre no es más avanzado que un agente único si la tarea solo necesita una llamada fiable a una herramienta.
Planificar y Ejecutar no es una mejora respecto a ReAct si tu plan queda obsoleto para el paso tres.
Los sistemas de producción más fiables no son los más autónomos.
Ponen la autonomía exactamente donde crea valor — y la restringen en todos los demás lugares.
10 reglas para sistemas agénticos en producción
- Empieza con el patrón más pequeño que funcione. Un solo agente con contratos de herramientas limpios vence a un sistema multi-agente con contratos débiles.
- Escribe las descripciones de las herramientas como contratos. El modelo solo sabe lo que hace la herramienta por la descripción — no por tu intención.
- Limita las iteraciones, las llamadas a herramientas y el gasto por solicitud. Un agente sin límites de presupuesto es un pasivo esperando aparecer en una factura.
- Registra el rastro completo de acciones. Llamadas a herramientas, argumentos, salidas, decisión final. Sin esto, investigar incidentes es adivinar.
- Mantén las acciones irreversibles detrás de comprobaciones deterministas o aprobación humana. Nunca dejes que un modelo sea la única puerta antes de un movimiento de dinero o un cambio en producción.
- Evalúa con casos de fallo reales, no solo con caminos felices. La corrección en el camino feliz es un prototipo. La corrección en casos límite es un producto.
- Separa los prompts por responsabilidad antes de que el prompt de sistema se vuelva ilegible. "Pero no hagas X cuando Y" colándose en tu prompt significa que el agente está haciendo dos trabajos.
- Trata los sistemas multi-agente como sistemas distribuidos. Fallo parcial, tiempos de espera, reintentos y observabilidad no son opcionales.
- La revisión del modelo no sustituye a la validación determinista. Usa jueces para mejorar la calidad. Usa pruebas y comprobaciones de permisos para garantizar la corrección.
- Prefiere el patrón más simple — no porque simple sea siempre mejor, sino porque el presupuesto de complejidad que ahorras se puede gastar en mejores herramientas, mejores prompts, mejor evaluación.
Esos son los 15.
La mayoría de los equipos no fracasan porque eligieron el patrón equivocado.
Fracasan porque nunca se preguntaron qué incertidumbre estaban resolviendo realmente.
Elige el patrón. Ajústalo a la forma del problema. No añadas autonomía donde no se gane su lugar.
Si te fue útil:
→ Compártelo para que llegue a cada ingeniero de tu equipo que construya agentes
→ Sigue a @sairahul1 para más análisis como este
→ Guárdalo en marcadores — volverás a él cada vez que empieces un nuevo proyecto de agentes
Escribo sobre IA, creación de productos y sistemas que funcionan sin ti.
