Patrones de diseño para soluciones agénticas: guía práctica de arquitectura y orquestación
Las soluciones agénticas pueden resolver tareas que exigen interpretación, planificación, uso de herramientas y adaptación. Sin embargo, esa flexibilidad no elimina la necesidad de una estructura. Cuando un agente se construye únicamente con un prompt extenso y acceso indiscriminado a varias herramientas, el resultado suele ser difícil de probar, costoso de operar y poco confiable.
Los patrones de diseño para soluciones agénticas ofrecen formas reutilizables de organizar el razonamiento, las acciones, el estado y la colaboración entre componentes. No son recetas rígidas ni dependen de un proveedor específico. Su valor está en ayudar a seleccionar el nivel de autonomía adecuado para cada problema.
La recomendación general es comenzar con el patrón más simple que cumpla el objetivo y avanzar hacia patrones más dinámicos solo cuando las evaluaciones demuestren que son necesarios.
1. Cadena secuencial de tareas
El patrón secuencial divide un proceso en pasos conocidos que se ejecutan en un orden definido. La salida de una etapa se convierte en la entrada de la siguiente.
flowchart LR
A[Entrada] --> B[Clasificar]
B --> C[Recuperar información]
C --> D[Generar resultado]
D --> E[Validar]
E --> F[Entregar]
Es apropiado cuando el procedimiento es estable y cada etapa puede describirse con claridad. Por ejemplo, una solución documental puede extraer datos, verificar campos, consultar una política y redactar una respuesta.
Ventajas
- Control predecible del flujo.
- Facilidad para probar cada etapa.
- Menor riesgo de bucles o decisiones innecesarias.
- Buena trazabilidad y estimación de costos.
Limitaciones
- Menor flexibilidad frente a tareas abiertas.
- Puede requerir múltiples variantes cuando cambian las rutas.
- Un error temprano puede propagarse a las etapas posteriores.
Este patrón debería considerarse antes de implementar un agente autónomo, especialmente cuando el proceso ya está bien definido.
2. Enrutamiento inteligente
El patrón de routing utiliza un clasificador, reglas o un modelo para dirigir una solicitud hacia el agente, flujo, modelo o herramienta más adecuado.
flowchart TD
A[Solicitud] --> R[Enrutador]
R --> B[Agente de soporte]
R --> C[Agente documental]
R --> D[Agente transaccional]
R --> E[Escalamiento humano]
Es útil cuando existen categorías claramente diferenciadas. Un centro de atención puede separar consultas informativas, reclamos, solicitudes operativas y casos de alto riesgo.
El enrutador debe devolver una salida estructurada y un nivel de confianza. Cuando la confianza sea insuficiente, la solicitud debe enviarse a una ruta segura o solicitar información adicional.
3. Paralelización o fan-out/fan-in
En este patrón, varias tareas independientes se ejecutan simultáneamente y luego se combinan sus resultados.
flowchart LR
A[Objetivo] --> B[Análisis técnico]
A --> C[Análisis financiero]
A --> D[Análisis de riesgos]
B --> E[Agregador]
C --> E
D --> E
E --> F[Resultado consolidado]
Puede reducir la latencia cuando las tareas no dependen entre sí. También permite obtener perspectivas especializadas sobre un mismo problema.
El componente agregador debe resolver contradicciones, normalizar formatos y evitar que una respuesta extensa de un subproceso domine el resultado. En sistemas críticos, puede aplicar reglas de prioridad o exigir evidencia para cada conclusión.
4. Orquestador con trabajadores especializados
Un agente orquestador interpreta el objetivo, descompone el trabajo y delega subtareas a agentes o herramientas especializadas. A diferencia de una cadena fija, el plan puede variar según el caso.
flowchart TD
U[Objetivo] --> O[Agente orquestador]
O --> A[Agente de investigación]
O --> B[Agente de análisis]
O --> C[Agente de redacción]
A --> O
B --> O
C --> O
O --> R[Resultado final]
Este patrón es adecuado para tareas complejas cuya secuencia no puede determinarse completamente de antemano. El orquestador debe tener límites de delegación, presupuesto, tiempo y cantidad de iteraciones.
Una mala implementación permite que el coordinador cree subtareas indefinidas o delegue repetidamente sin mejorar el resultado. Por ello, debe existir una condición de finalización verificable.
5. Handoff o transferencia entre agentes
En un handoff, un agente transfiere el control completo a otro cuando detecta que la tarea pertenece a una especialidad diferente.
Por ejemplo, un agente general de atención puede transferir una consulta de facturación a un agente financiero, conservando únicamente el contexto necesario. El agente receptor continúa la interacción y puede devolverla o escalarla.
Este patrón funciona bien en experiencias conversacionales y procesos con dominios separados. Requiere contratos claros sobre qué información se transfiere, quién conserva la responsabilidad y cómo se evita un ciclo de transferencias.
6. Agentes como herramientas
En lugar de transferir el control, un agente principal puede invocar a otro agente como si fuera una herramienta. El agente principal mantiene la conversación y utiliza el resultado especializado para completar su respuesta.
La diferencia es importante:
- En un handoff, cambia el responsable de la interacción.
- En agentes como herramientas, el coordinador conserva el control.
Este patrón permite encapsular capacidades complejas, como investigación jurídica o generación de consultas, sin exponer toda la lógica al agente principal. También facilita aplicar permisos distintos a cada especialista.
7. ReAct: razonar y actuar en un ciclo controlado
ReAct combina razonamiento, selección de herramientas, observación de resultados y nuevos pasos hasta alcanzar una condición de finalización.
flowchart TD
A[Objetivo] --> B[Razonar / decidir siguiente paso]
B --> C[Ejecutar herramienta]
C --> D[Observar resultado]
D --> E{¿Objetivo cumplido?}
E -- No --> B
E -- Sí --> F[Respuesta final]
Es uno de los patrones fundamentales de los agentes. Resulta útil cuando el sistema debe decidir dinámicamente qué información consultar o qué acción realizar.
El ciclo debe estar limitado por:
- Número máximo de pasos.
- Tiempo de ejecución.
- Presupuesto de tokens o costo.
- Lista permitida de herramientas.
- Condiciones explícitas de éxito o abandono.
Sin estos límites, un agente puede entrar en ciclos, repetir búsquedas o consumir recursos sin progreso real.
8. Planificar y ejecutar
El patrón plan-and-execute separa la creación del plan de la ejecución. Un modelo o componente de mayor capacidad diseña una secuencia de tareas y otro ejecutor realiza cada paso.
Esta separación permite revisar el plan antes de actuar, aplicar políticas y asignar modelos diferentes según la complejidad. También facilita que una persona apruebe planes que involucren cambios relevantes.
El plan no debe tratarse como una verdad inmutable. La ejecución puede descubrir información que obligue a revisarlo. Por eso, conviene incluir puntos de replanificación controlada y evitar rehacer todo el plan ante cada pequeño cambio.
9. Generador y crítico, o maker-checker
Un componente genera una propuesta y otro la evalúa contra criterios definidos. Si encuentra problemas, devuelve observaciones para una nueva versión.
flowchart LR
A[Requisitos] --> B[Generador]
B --> C[Crítico / verificador]
C --> D{¿Cumple criterios?}
D -- No --> B
D -- Sí --> E[Resultado aprobado]
Este patrón es útil para documentos, código, análisis y respuestas donde existen criterios verificables. El crítico debe trabajar con una rúbrica clara; de lo contrario, puede limitarse a opiniones generales o mantener un ciclo sin final.
Se recomienda establecer un máximo de iteraciones y guardar la razón de cada rechazo. En procesos de alto impacto, la aprobación final puede corresponder a una persona.
10. Reflexión o autocorrección
El agente revisa su propio resultado, identifica posibles omisiones y produce una versión mejorada. Es más simple que utilizar un crítico separado, pero puede compartir los mismos sesgos del generador.
La reflexión es útil para mejorar estructura, cobertura o consistencia, aunque no debería utilizarse como único mecanismo de verificación factual. Para datos críticos se necesitan fuentes, reglas o validadores independientes.
11. Recuperación aumentada y uso de conocimiento
Un agente con RAG recupera información relevante antes de responder o actuar. El patrón básico incluye consulta, recuperación, filtrado, construcción de contexto y generación.
En sistemas agénticos, el agente puede decidir cuándo buscar, reformular la consulta, combinar varias fuentes y evaluar si la evidencia es suficiente. Esta flexibilidad mejora la cobertura, pero exige controles sobre permisos, procedencia y calidad de los documentos.
La salida debería incluir referencias internas o evidencia trazable cuando el caso lo requiera. También conviene separar hechos recuperados de inferencias generadas.
12. Memoria de corto y largo plazo
La memoria permite conservar contexto entre pasos o sesiones. Debe distinguirse entre:
- Memoria de trabajo para la ejecución actual.
- Resumen de conversación.
- Preferencias autorizadas del usuario.
- Historial operativo.
- Conocimiento empresarial compartido.
No toda conversación debe almacenarse. La memoria persistente requiere reglas de consentimiento, retención, actualización y eliminación. Un dato antiguo o incorrecto puede afectar decisiones futuras si el agente lo trata como vigente.
13. Human-in-the-loop
Este patrón incorpora una decisión humana en puntos específicos. No se trata de que una persona revise cada respuesta, sino de asignar intervención donde el impacto, la incertidumbre o la excepción lo justifiquen.
Puede utilizarse para:
- Aprobar transacciones de alto valor.
- Confirmar cambios irreversibles.
- Resolver baja confianza.
- Revisar contenido sensible.
- Autorizar acceso temporal a información.
- Gestionar excepciones no contempladas.
La interfaz de aprobación debe mostrar la propuesta, la evidencia, el impacto y las alternativas. Pedir aprobación sin contexto convierte la supervisión humana en un trámite poco efectivo.
14. Saga agéntica para procesos distribuidos
Cuando un agente coordina operaciones en varios sistemas, puede adaptarse el patrón Saga. Cada paso tiene una acción y, cuando sea posible, una compensación.
Por ejemplo, reservar un recurso, crear una orden y emitir una notificación pueden formar una transacción distribuida. Si falla la creación de la orden, el sistema debe liberar la reserva. El agente puede decidir el flujo, pero la consistencia debe implementarse mediante mecanismos confiables de software.
Este patrón es especialmente importante porque los modelos y las redes pueden provocar reintentos. Las operaciones deben usar claves de idempotencia, estados persistentes y manejo explícito de compensaciones.
Cómo elegir el patrón adecuado
La selección puede basarse en estas preguntas:
- ¿El flujo es conocido o debe descubrirse dinámicamente?
- ¿Las tareas son secuenciales o independientes?
- ¿Existen especialidades claramente separadas?
- ¿Se necesita mantener una conversación con un responsable único?
- ¿El resultado puede validarse con una rúbrica?
- ¿La acción tiene impacto financiero, legal o operativo?
- ¿Se requiere recuperación ante fallos distribuidos?
- ¿Cuánto costo y latencia puede tolerar el proceso?
Una cadena determinista suele ser mejor para procesos estables. Un enrutador es apropiado para categorías claras. Un orquestador resulta útil cuando el plan cambia. El patrón maker-checker aporta control de calidad, mientras que human-in-the-loop es esencial cuando el riesgo supera la autonomía permitida.
Antipatrones que conviene evitar
Entre los errores frecuentes se encuentran:
- Crear múltiples agentes sin responsabilidades diferenciadas.
- Permitir conversaciones abiertas entre agentes sin límite.
- Utilizar un modelo para validaciones que deberían ser reglas.
- Compartir todo el contexto con todos los agentes.
- Exponer herramientas administrativas al agente general.
- Confundir reflexión con verificación objetiva.
- Mantener estado únicamente dentro del historial del modelo.
- No definir condiciones claras de éxito, fallo y escalamiento.
Conclusión
Los patrones de diseño permiten controlar la complejidad de las soluciones agénticas. La autonomía debe introducirse donde aporta valor, mientras que el código, los workflows y las políticas conservan el control sobre seguridad, estado y consistencia.
No existe un patrón universal. Una solución madura puede combinar routing, ejecución secuencial, RAG, maker-checker y aprobación humana. La decisión correcta es aquella que alcanza la calidad requerida con la menor complejidad operativa posible.