Diseño de sistemas de agentes : componentes, trade-offs y patrones arquitectónicos

Empezar con un caso de uso estrecho

La mayoría de practitioners no empiezan con un grand design document. Empiezan con un problema desordenado, una API key y una idea aproximada. El capítulo construye un ejemplo: un agente de soporte ecommerce que, ante un email de cliente, decide qué herramienta invocar (issue_refund, cancel_order o update_address_for_order) y envía una confirmación breve.

   Cliente dice:           "Please cancel my order #B73973."
                           ↓
   Agente decide:          llamar cancel_order(order_id="B73973")
                           ↓
   Tool ejecuta:           cancelación en el backend
                           ↓
   Agente redacta:         "Tu pedido B73973 ha sido cancelado."

La versión con LangGraph son ~30 líneas: un @tool con cancel_order, un call_model que hace dos pasadas al LLM (decide tool call → ejecuta tool → genera confirmación), y un StateGraph con un único nodo assistant. Lo importante es la disciplina de scope: si el primer caso es solo “cancelar pedidos” (no “toda la atención al cliente”), las entradas son concretas, las salidas estructuradas y el feedback loop es rápido.

example_order = {"order_id": "B73973"}
convo = [HumanMessage(content="Please cancel order #B73973. I found a cheaper option elsewhere.")]

result = graph.invoke({"order": example_order, "messages": convo})

assert any("cancel_order" in str(m.content) for m in result["messages"]), \
    "Cancel order tool not called"
assert any("cancelled" in m.content.lower() for m in result["messages"]), \
    "Confirmation message missing"

print("✅ Agent passed minimal evaluation.")

Componentes núcleo de un sistema agentico

Cuatro bloques componen cualquier sistema agentico. Cada uno tiene su propio capítulo en el libro (memory → cap. 6, orquestación → cap. 5, multi-agente → cap. 8).

   ┌────────────┐    ┌────────────┐    ┌──────────────┐    ┌────────────┐
   │   Modelo   │    │ Herramientas│    │   Memoria    │    │Orquestación│
   └────────────┘    └────────────┘    └──────────────┘    └────────────┘
        ↑                   ↑                ↑                  ↑
        └────── todas se coordinan vía el componente de orquestación ──┘

Selección de modelo (extendido)

Además del criterio “qué modelo usar” del capítulo 1, aquí entran las decisiones de modalidad, openness, custom training y tamaño:

Herramientas: tres categorías

Memoria: corto plazo y largo plazo

• Short-term: ventana deslizante durante la tarea actual. Útil para mantener coherencia en una conversación o workflow. Implementación típica: rolling context window.
• Long-term: conocimiento persistente (preferencias del usuario, métricas históricas, fallos recurrentes). Implementación típica: bases de datos, knowledge graphs, modelos fine-tuned.

Memoria efectiva = organizar datos indexados + recuperar rápido + descartar outdated. Profundizado en 06-conocimiento-y-memoria.

Orquestación

La orquestación convierte capacidades aisladas en soluciones de extremo a extremo:

• Componer, schedule, supervisar una secuencia de skills hacia un objetivo.
• Evaluar secuencias posibles, predecir outcomes, elegir el path más probable.
• Monitorizar progreso y entorno, reroute cuando algo cambia.
• Construir el plan incrementalmente: ejecutar N pasos, reevaluar, continuar.

   Orquestador
       │
       ├─ ¿plan?            ───── build_plan() con LLM o rules
       │
       ├─ ¿tool a usar?     ───── select_tool()    ─┐
       │                                              │
       ├─ ejecutarla             run_tool()     ─┐   │
       │                                          │   │
       └─ ¿sigue el plan?        re_eval()    ───┘   │
                                                    │
                          feedback loop ─────────────┘

Profundizado en 05-orquestacion.

Trade-offs de diseño

Cuatro familias de trade-offs que toda decisión en un sistema agentico arrastra:

Performance: velocidad vs precisión

   Aproximación rápida          Refinamiento iterativo
   ────────────────          ──────────────────────
   "taxi más cercano"  →  "llegada + tráfico + precio"
   "responder en 200ms" → "pulir tono en segundo pase"

Escalabilidad: GPUs, allocation y elasticidad

Los GPUs son el cuello de botella y el coste principal. Estrategias clave:

Fiabilidad: tolerancia a fallos + consistencia

• Fault tolerance: detectar fallos (red, hardware) y recuperar con gracia. Redundancy en componentes críticos.
• Consistencia: el mismo input → el mismo output, en el rango de variabilidad permitido por el modelo.
• Robustez: no solo ideal, también edge cases, inputs adversarios, stress tests.

Alcanzar fiabilidad exige:

   - Testing exhaustivo  ── unit + integration + adversarial
   - Monitoring en producción
   - Feedback loops   ── el agente aprende y se corrige

Costes: desarrollo + operación + valor

Patrones arquitectónicos

Dos patrones principales. El libro los expande en 08-de-un-agente-a-muchos-parte-a.

Single-agent

   User ───→ [ Agent ] ───→ Tools / Memory / Models
                 │
              Output

• Ideal para: tareas bien definidas y narrow (FAQs, tracking de pedidos, entry de datos).
• Pros: simple, fácil de diseñar/desplegar/diagnosticar.
• Contras: no escala a problemas multi-dominio.

Multi-agent

   Coordinator
      ├── Agent A (data collection)
      ├── Agent B (data processing)
      └── Agent C (user interaction)

Buenas prácticas

Diseño iterativo

   MVP
     ↓ feedback
   Iteración 1
     ↓ feedback
   Iteración 2
     ↓ feedback
   ...

Beneficios:

• Detección temprana de issues antes de que sean arquitectónicos.
• Diseño user-centric: feedback continuo de stakeholders.
• Escalabilidad por capas: añadir features en cada vuelta, tested incrementalmente.

Tres reglas operativas:

1. Prototipos rápidos — feature mínimo que entrega valor.
2. Testear + recoger feedback después de cada iteración.
3. Refinar + repetir.

Estrategia de evaluación

Cobertura mínima:

   Funcionalidad     ── correctness, edge cases, métricas de dominio
   Generalización     ── comportamiento en tareas fuera de training
   User experience    ── NPS, CSAT, completion rates, feedback explícito
   Operacional        ── latencia, throughput, tasa de error
   HITL               ── human-in-the-loop para validación de alta-precisión
   E2E environment    ── simulaciones de producción reales

Tres señales que importa recoger:

• Explícitas: thumbs up/down, ratings.
• Implícitas: patrones de fallo (delays, sentiment, misinterpretations).
• Human-in-the-loop: expertos revisan muestras para calibrar métricas auto.

Real-world testing

Más allá del laboratorio: deploy en condiciones reales con phased rollout.

   Fases de rollout
   ────────────────
   Canary (5% tráfico)    ─→ 15% → 50% → 100%
       ↓
   Monitor (KPIs en vivo)
       ↓
   Recoger feedback de usuarios
       ↓
   Iterar

KPIs típicos: response time, accuracy, user satisfaction, system stability.

[!quote> Toma de cierre del capítulo “No necesitas 30 páginas de plan para empezar a construir un buen sistema agentico — pero algo de foresight ayuda.”

Resumen del capítulo

• Empieza por un caso de uso estrecho y concreto (como “cancelar pedidos”) — no por el “agente completo de soporte”.
• Los cuatro componentes núcleo son modelo, herramientas, memoria, orquestación — todos se coordinan vía el orquestador.
• Los trade-offs de diseño se agrupan en cuatro ejes: performance (velocidad↔precisión), escalabilidad (GPU allocation), fiabilidad (tolerancia a fallos, consistencia), coste (desarrollo + operación).
• Elige single-agent hasta que tengas razón para multi-agent. La regla no es “qué tan cool”, es “qué tan claro el paralelismo”.
• Diseño iterativo + evaluación robusta + real-world testing son el proceso que convierte prototipo en sistema en producción.

Próximos pasos

Con agentes y orquestación en mente, el siguiente paso natural es cómo el usuario interactúa con el sistema agentico: la UX de agentes se trata en 03-diseno-de-experiencia-de-usuario-para-sistemas-agenticos.