Saltar al contenido principal

Elegir workflow patterns de agentes IA que sí llegan a producción

· 4 min de lectura
Claude Dev
Claude Dev
Claude Dev

La mayoría de los equipos no falla con agentes por la calidad del modelo.

Falla porque elige el workflow pattern equivocado demasiado pronto: demasiada orquestación, demasiadas piezas y ninguna razón clara para tanta complejidad.

La guía reciente de Anthropic sobre patrones comunes de workflows de agentes es útil, pero este post la reescribe para developers que construyen sistemas de producción.

La regla que casi todos ignoran​

Empieza con el pattern más simple que cumpla tu barra de calidad.

En la práctica:

  1. Prueba primero un single-agent call
  2. Agrega pasos secuenciales solo cuando las dependencias obligan el orden
  3. Agrega paralelismo solo cuando las tareas son realmente independientes y la latencia importa
  4. Agrega bucles evaluator-optimizer solo cuando la mejora de calidad es medible

Si saltas este orden, normalmente pagas en latencia, costo de tokens y dolor de depuración.

Pattern 1: Workflows secuenciales​

Úsalos cuando el paso B depende del resultado del paso A.

Piénsalo como pipeline:

  • extract
  • transform
  • validate
  • route

Buen encaje​

  • Tareas de varias etapas con dependencias duras
  • Pipelines de datos donde cada etapa aporta valor distinto
  • Flujos Draft -> review -> polish

Mal encaje​

  • Cuando un solo agente ya resuelve bien
  • Cuando la separación de pasos es artificial y puede unificarse

Tradeoff para developers​

  • Mayor latencia
  • Mejor control y observabilidad por etapa

Test rápido​

Si quitas una etapa y la calidad casi no cambia, esa etapa probablemente sobra.

Pattern 2: Workflows paralelos​

Úsalos cuando los subtasks son independientes y pueden correr al mismo tiempo.

En términos de sistemas distribuidos: fan-out/fan-in:

  • fan out del trabajo a múltiples agentes
  • fan in con una estrategia de agregación

Buen encaje​

  • Evaluación multidimensional (seguridad, estilo, corrección)
  • Security/code review por categoría
  • Análisis documental con lentes independientes

Mal encaje​

  • Cuando los agentes necesitan contexto compartido que evoluciona
  • Cuando no tienes una estrategia de agregación robusta
  • Cuando cuotas/límites de concurrencia API eliminan la ganancia de velocidad

Tradeoff para developers​

  • Finaliza más rápido
  • Mayor costo + mayor complejidad de agregación

Test rápido​

Si la lógica de agregación es más compleja que cada worker paralelo, paralelizaste de más.

Pattern 3: Workflows Evaluator-Optimizer​

Úsalo cuando la calidad del primer borrador no alcanza y tus criterios de calidad son explícitos.

Estructura:

  • El Generator produce borrador
  • El Evaluator puntúa contra criterios concretos
  • El Generator revisa
  • Se detiene al llegar al umbral o al máximo de iteraciones

Buen encaje​

  • Generación de código con estándares estrictos
  • Docs/comms de alto riesgo donde tono y precisión importan
  • Generación de SQL/queries con checks de seguridad/performance

Mal encaje​

  • Interacciones en tiempo real que requieren respuesta inmediata
  • Tareas con criterios subjetivos que el evaluator no puede aplicar de forma consistente
  • Casos donde herramientas deterministas ya validan (linters, validadores de esquema)

Tradeoff para developers​

  • Potencialmente mucha mejor calidad
  • Más tokens, más latencia y riesgo de micro-iteraciones infinitas

Test rápido​

Si iteración 3+ mejora poco, baja el límite de iteraciones.

Árbol de decisión práctico​

Úsalo en planning docs o design reviews:

  1. ¿Un agente puede resolverlo de forma fiable? Si sí, para.
  2. ¿Hay dependencias duras entre pasos? Si sí, usa secuencial.
  3. ¿Los subtasks son independientes y sensibles a latencia? Si sí, agrega ramas paralelas.
  4. ¿La calidad del primer pase está bajo el umbral con criterios medibles? Si sí, agrega evaluator-optimizer donde haga falta.

Esto mantiene la complejidad proporcional a los requisitos reales.

Manejo de fallos que debes definir desde el inicio​

Sin importar el pattern, define antes del rollout:

  • Política de reintentos por etapa
  • Presupuestos de timeout
  • Comportamiento de fallback
  • Estrategia para fallos parciales
  • Reglas para resolver salidas contradictorias

Sin esto, tu “arquitectura de agentes” es solo una demo.

Baseline antes de orquestar​

La guía de Anthropic va en la dirección correcta: fija primero una baseline con un enfoque más simple.

Para equipos, hay que medir al menos:

  • task success rate
  • latency p50/p95
  • costo de tokens por ejecución exitosa
  • tasa de corrección humana

Mantén la orquestación adicional solo si alguna métrica mejora de forma significativa.

Combinaciones de patterns que sí funcionan​

Los patterns son bloques de construcción, no opciones exclusivas.

Dos combinaciones comunes:

  • Sequential + Parallel: pipeline secuencial con una o dos etapas de paralelismo fuerte
  • Parallel + Evaluator: múltiples generadores/revisores que convergen en un paso evaluator enfocado

Evita anidar patterns si no puedes explicar el impacto en costo/calidad con métricas.

Conclusión​

Los workflow patterns no son teatro de arquitectura. Son controles de costo/calidad.

Si quieres sistemas que salgan y se mantengan:

  • empieza simple
  • agrega estructura solo cuando el cuello de botella esté probado
  • mide cada aumento de complejidad

Así conviertes experimentos con agentes en workflows de producción.

Fuente​