Cada equipo que construye agentes de IA se topa con la misma pared.
Empiezas con un aviso y algunas herramientas.
Funciona.
Luego los requisitos crecen. Más casos extremos. Más equipos. Más riesgo.
De repente tu "agente" es un aviso de sistema de 3,000 palabras intentando hacer cinco trabajos a la vez.
La solución no es más ingeniería de avisos.
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 confiable
→ 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 codificar
Una tarea generalmente NO necesita un agente cuando el camino de entrada a salida es predecible.
Resumir. Clasificar. Extracción simple. Generación con plantillas.
Estas son más rápidas, más baratas y más confiables 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 aviso de sistema. Un conjunto limitado 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 del pedido, verifica el envío y crea un ticket si no puede resolver el problema — todo con 2-3 herramientas y un trabajo claro.
Úsalo cuando: la tarea está bien definida, el conjunto de herramientas es pequeño y un agente puede mantener el contexto completo sin confundirse.
Se rompe cuando: sigues añadiendo herramientas y el aviso de sistema crece más de una página. Esa es la señal de que necesitas un patrón diferente — no un aviso 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 flujo de revisión de contratos — un agente extrae obligaciones, el siguiente identifica riesgos, un tercero redacta el resumen para compras. 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 encuentre en medio del proceso. Los flujos secuenciales asumen que el camino es fijo — 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 vista única.
Ejemplo real: Un incidente de producción a las 2 a.m. Tres agentes investigan registros, métricas e implementaciones recientes al mismo tiempo — no uno tras otro — porque cada minuto cuenta durante una interrupción.
Ú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 cumpla 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 cumple con los estándares de calidad y reintenta si no lo hace — 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 confiable. Sin una, obtienes costos fuera de control 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 específicos y procesables.
Ejemplo real: Un informe generado es revisado por un agente "crítico" separado 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 comparte los mismos puntos ciegos que el generador. Un revisor entrenado con suposiciones 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 que supera la marca.
Ejemplo real: Un generador de textos de marketing que califica su propio borrador según las pautas de la marca y sigue reescribiendo hasta alcanzar una puntuación mínima de calidad — no solo una verificación de pasa/no pasa, sino una mejora graduada.
Úsalo cuando: la calidad de la 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 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 pide.
Ejemplo real: Los tickets de soporte se enrutan a especialistas en facturación, técnico, cuentas, envíos o fraude — cada uno con un contexto limitado en lugar de un solo agente que intenta saberlo todo.
Úsalo cuando: tienes tipos de solicitud 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.
PATRÓN 8 — Descomposición Jerárquica de Tareas
Un agente raíz descompone un objetivo complejo en subobjetivos más pequeños, los delega a trabajadores especializados y luego sintetiza todo en una respuesta.
Ejemplo real: "¿Qué 3 países deberíamos considerar para expandirnos el próximo año?" se descompone en análisis competitivo, investigación regulatoria, viabilidad logística y dimensionamiento del mercado — cada uno manejado por un especialista diferente, luego combinado.
Úsalo cuando: el problema es demasiado amplio para un solo paso de razonamiento pero se divide claramente en áreas de experiencia independientes.
Se rompe cuando: los subobjetivos no son realmente independientes. Si los flujos de trabajo necesitan informarse mutuamente en tiempo real, descomponerlos por adelantado 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 su perspectiva a lo largo de múltiples rondas antes de que un facilitador evalúe 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 encuentra en el camino.
Úsalo cuando: el camino hacia la respuesta genuinamente no se puede planificar de antemano — depende de lo que cada paso revela.
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 riesgosa o ambigua.
Ejemplo real: Aprobaciones de reembolsos — los casos de bajo riesgo y claros se automatizan. Los montos 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 total aún no es aceptable.
Se rompe cuando: tratas esto solo como una función de interfaz de usuario en lugar de una arquitectónica. Necesitas estado duradero, asignación de revisores, manejo de tiempos de espera y rutas de escalamiento — 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 el camino 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 desactualizado ejecutado ciegamente 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 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 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 codificadas. La elegibilidad, los permisos y los movimientos de dinero nunca deberían ser solo decisión del modelo.
PATRÓN 15 — Agente Impulsado por Eventos
El agente no espera a que le pidan. 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 en el instante en que se dispara un evento de transacción sospechosa — no cuando un ticket de soporte finalmente lo saca a la luz, momento en el cual 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 desencadenantes están mal definidas. Un flujo de eventos ruidoso con desencadenantes vagos se convierte en un sistema que constantemente da falsas alarmas — o peor, pierde la señal real.
Selección de patrón — iguala la incertidumbre, no el hype
El patrón correcto coincide con la forma de la incertidumbre en tu trabajo:
→ Incierto qué herramienta usar → Agente Único o ReAct
→ Incierto hacia dónde enrutar → Coordinador
→ Incierto sobre la calidad → Revisión y Crítica o Refinamiento Iterativo
→ Ruta de ejecución incierta → Planificar y Ejecutar o ReAct
→ Incierto cómo autocorregirse → Reflexión o Bucle
→ Incierto sobre el riesgo empresarial → Humano en el Bucle o Lógica Personalizada
→ Estructura del problema incierta → Descomposición Jerárquica o Enjambre
→ No puedes esperar una solicitud → Agente Impulsado por Eventos
Un enjambre no es más avanzado que un agente único si la tarea solo necesita una llamada a herramienta confiable.
Planificar y Ejecutar no es una mejora sobre ReAct si tu plan queda obsoleto para el paso tres.
Los sistemas de producción más confiables 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 agente único con contratos de herramientas limpios vence a un sistema multi-agente con contratos débiles.
- Escribe descripciones de herramientas como contratos. El modelo solo sabe lo que hace la herramienta por la descripción — no por tu intención.
- Limita las iteraciones, llamadas a herramientas y 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, la investigación de 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 caminos felices. La corrección del camino feliz es un prototipo. La corrección de casos extremos es un producto.
- Separa los avisos por responsabilidad antes de que el aviso de sistema se vuelva ilegible. "Pero no hagas X cuando Y" colándose en tu aviso 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 la validación determinista. Usa jueces para mejorar la calidad. Usa pruebas y comprobaciones de permisos para hacer cumplir la corrección.
- Prefiere el patrón más simple — no porque lo simple sea siempre mejor, sino porque el presupuesto de complejidad que ahorras se puede gastar en mejores herramientas, mejores avisos, mejor evaluación.
Esos son los 15.
La mayoría de los equipos no fallan porque eligieron el patrón equivocado.
Fracasan porque nunca se preguntaron qué incertidumbre estaban resolviendo realmente.
Elige el patrón. Iguala la forma del problema. No añadas autonomía donde no se gane su lugar.
Si esto fue útil:
→ Comparte para que llegue a cada ingeniero construyendo agentes en tu equipo
→ Sigue a @sairahul1 para más desgloses como este
→ Guárdalo en favoritos — volverás a él cada vez que empieces un nuevo proyecto de agentes
Escribo sobre IA, construcción de productos y sistemas que funcionan sin ti.
