Arquitectura agéntica: diseña agentes y sistemas multiagente

En la lección anterior vimos cómo es el examen CCAR-F: basado en escenarios de producción donde tú decides cómo resolver problemas reales. Ahora toca aprender una de las decisiones arquitectónicas más críticas: cuándo y cómo construir sistemas agénticos.

Un agente es muy diferente de un chatbot. Un agente percibe el contexto, toma decisiones autónomas, ejecuta herramientas y ajusta su estrategia según los resultados. Cuando escalas eso a múltiples agentes coordinados, la complejidad sube exponencialmente. En el examen te presentarán escenarios donde tienes que elegir el patrón correcto, identificar riesgos de confiabilidad y justificar por qué un agente es mejor (o peor) que un flujo determinista.

Esta lección te prepara para esas decisiones.

¿Agente o flujo determinista?

Lo primero que debes saber es que no todo requiere un agente. Es tentador, pero es un error costoso.

Usa un flujo determinista cuando:

El flujo de decisiones es predecible y finito (por ejemplo: validar formulario → guardar en BD → enviar email)
Los pasos siempre ocurren en el mismo orden
Los errores son excepcionales y manejables con reintentos simples
La latencia debe ser baja y predecible
El costo de inferencia importa mucho

Ejemplo: un sistema de facturación donde recibes una orden → validas → generas PDF → registras en contabilidad. Cada paso es determinista, el modelo LLM solo interviene en generar el PDF.

Usa un agente cuando:

El resultado deseado es claro, pero el camino no está definido a priori
El agente debe decidir qué herramientas usar y en qué orden
Hay múltiples estrategias válidas según el contexto
El agente debe "razonar" y adaptar su enfoque si algo falla

Ejemplo: un asistente de customer support que recibe un ticket complejo. El agente debe decidir si necesita buscar en la base de conocimientos, consultar historial del cliente, escalar a un humano, o generar una respuesta directa. Cada caso es distinto.

La pregunta clave del examen: "¿El sistema necesita autonomía y adaptabilidad, o es suficiente con una secuencia de pasos predefinida?" Si la respuesta es sí, agente. Si es no, evítalo.

Patrones de diseño agéntico

Hay tres patrones principales que dominarás en el examen:

Patrón orquestador-trabajadores (supervisor)

Un agente central (orquestador) recibe la solicitud y delega tareas a agentes especializados (trabajadores). El orquestador coordina, integra resultados y toma decisiones de alto nivel.

Cuándo usarlo:

Tareas complejas que se dividen naturalmente en subtareas independientes
Cada subtarea requiere experiencia diferente (un agente para análisis de datos, otro para redacción, otro para validación legal)
La latencia total es crítica: los trabajadores pueden ejecutarse en paralelo

Riesgo: Si el orquestador no está bien diseñado, puede convertirse en un cuello de botella o fallar a la hora de sincronizar resultados contradictorios.

Patrón encadenado (agentic loop secuencial)

Un único agente ejecuta un ciclo: observa estado → decide acción → ejecuta herramienta → observa resultado → decide siguiente acción. Continúa hasta alcanzar el objetivo o agotar intentos.

Cuándo usarlo:

Tareas donde cada paso informa al siguiente (investigación, debugging, navegación web)
No hay paralelización posible o no es necesaria
El agente debe "aprender" iterativamente sobre el problema

Ejemplo real: Un agente que investiga un incidente de seguridad. Lee logs → identifica patrón sospechoso → consulta sistemas relacionados → correlaciona datos → genera reporte.

Riesgo: Loop infinito si el agente entra en ciclos repetitivos, o drift (el agente se va del objetivo original). Siempre define criterios de parada.

Patrón enrutado (routing)

Un agente o función determinista examina la entrada y enruta hacia el agente más apropiado. Es un dispatcher inteligente.

Cuándo usarlo:

Múltiples dominios o flujos que requieren lógica agéntica pero diferente
Algunos casos son tan simples que no necesitan agente (caen en un flujo rápido)
Quieres controlar costos: solo los casos que lo necesitan usan agentes costosos

Ejemplo: En un sistema de soporte:

Si es pregunta sobre facturación → enruta a agente billing
Si es incidente de seguridad → enruta a agente security
Si es FAQ común → responde con búsqueda simple (no agente)

Riesgo: El enrutador puede misclasificar, enviando tickets al agente equivocado. Mitiga con un mecanismo de "escala" o re-enrutamiento.

Sistemas multiagente: coordinación y confiabilidad

Cuando tienes más de un agente, la arquitectura debe garantizar:

Comunicación explícita

Los agentes no deben compartir estado implícitamente. Define claramente:

Qué información pasa de un agente a otro (contexto compartido)
Qué formato tiene esa información
Quién es responsable de validarla

En el examen, buscarán si reconoces problemas como "dos agentes leyeron datos stale en paralelo y tomaron decisiones conflictivas".

Aislamiento y tolerancia a fallos

Si un agente falla, el sistema debe:

No afectar a otros agentes (aislamiento)
Tener una estrategia clara: reintentar, escalar, o descartar el resultado
Registrar qué pasó para auditoría

Patrón recomendado: Cada agente tiene un timeout, un número máximo de intentos, y un manejador de errores que decide si reintentar o fallar explícitamente.

Consistencia de decisiones

En algunos dominios, dos agentes no pueden tomar decisiones contradictorias sobre el mismo recurso. Por ejemplo, en e-commerce, el agente de inventario y el de pagos deben estar sincronizados.

Soluciones:

Usar una BD transaccional centralizada (costoso en latencia)
Implementar un agente "árbitro" que valida y resuelve conflictos
Diseñar idempotencia: si un agente repite su acción, el resultado es el mismo

Observabilidad y trazabilidad

En producción, necesitas saber:

Qué razonamiento hizo cada agente
Qué herramientas llamó y con qué parámetros
Por qué tomó esa decisión

Isto es crítico para debugging y cumplimiento normativo. Usa logging estructurado en cada paso del agentic loop.

Diseño para la fiabilidad agéntica

Aquí están los principios que el examen espera que domines:

1. Criterios de parada explícitos

Todo agente debe saber cuándo parar:

¿Alcanzó el objetivo? → Éxito
¿Agotó intentos? → Fallo
¿Timeout? → Fallo con estado parcial
¿Detección de loop? → Fallo

2. Validación en cada frontera

Cuando un agente pasa información a otro o a un sistema externo, valida:

Tipo y formato correcto
Valores en rango esperado
Permisos: ¿tiene autoridad para hacer eso?

3. Herramientas con garantías

Cada herramienta que un agente puede usar debe:

Ser atómica o tener rollback
Devolver resultados en formato estricto
Ser idempotente (si es posible)
Tener límites claros (máximo N registros, máximo costo)

4. Priorización y backpressure

Si los agentes generan trabajo más rápido de lo que pueden ejecutarlo, el sistema debe:

Encolar solicitudes
Priorizar según importancia
Rechazar explícitamente si la cola crece demasiado

5. Fallback a humano

Hay situaciones donde el agente debe admitir "no puedo resolver esto solo". Define:

Cuándo escalar a humano
Qué contexto pasar
Cómo el humano puede regresar la decisión

Para el examen

En los escenarios del CCAR-F, espera preguntas como:

Análisis de patrón: "Te describen un caso de uso. ¿Qué patrón agéntico usarías y por qué?" Debes justificar en función de los criterios: ¿es parallelizable? ¿iterativo? ¿hay enrutamiento?
Identificación de riesgos: "Esto es un sistema multiagente. ¿Qué puede fallar?" Buscan que identifiques race conditions, inconsistencia de estado, loops infinitos, fallos de escalabilidad.
Mejoras de confiabilidad: "El sistema actual falla a veces. Propón 2-3 cambios arquitectónicos." Aquí brillan el timeout, la validación, los criterios de parada.
Costo vs complejidad: "¿Vale la pena usar un agente aquí?" Reconocer cuándo un flujo determinista es mejor te diferencia de los candidatos que ven agentes como la solución a todo.

Lo clave: Domina la matriz de decisión:

Flujo predecible y lineal → determinista
Múltiples caminos, decisión adaptativa → agente
Varios dominios especializados → orquestador-trabajadores
Un problema que evoluciona iterativamente → encadenado
Entrada que se clasifica hacia distintos flujos → enrutado

Para recordar

No uses agentes por defecto. Un flujo determinista bien diseñado es más eficiente, más predecible y más barato. Los agentes son para cuando la adaptabilidad es crítica.
Elige el patrón según la estructura del problema. Orquestador-trabajadores para paralelismo, encadenado para iteración, enrutado para clasificación. El examen premia el pensamiento estructurado.
Fiabilidad multiagente = comunicación explícita + validación + aislamiento + observabilidad. Sin esto, un sistema multiagente es un riesgo de producción.
Define límites y criterios de parada desde el inicio. Timeout, máximo de intentos, condiciones de éxito/fallo, escalada a humano. Son las guardarraíles que evitan sorpresas en producción.