Agentes multi-step: arquitectura de orquestación que sobrevive en producción

Onboarding completo de empleado, conciliación financiera, apertura de proceso regulatorio — estos son casos donde el agente ejecuta una cadena de 5–15 pasos con decisiones intermedias. Aquí vive el ROI más alto y la complejidad más traicionera.

Por qué multi-step es diferente

• Cada paso tiene latencia → el flujo total se alarga (10s–2min es común).
• Cada llamada externa puede fallar → manejo explícito requerido.
• El estado intermedio debe persistir → checkpoint obligatorio.
• Error en paso 4 puede exigir deshacer pasos 1–3 → patrón Saga.
• La decisión "próximo paso" es dinámica → planning real, no DAG fijo.
• La observabilidad simple no basta → trace estructurado.

Patrón de planning explícito

Antes de ejecutar, el agente declara el plan. En pseudocódigo:

1. Input: "abrir proceso regulatorio X"
2. Plan generation: Gemini 2.5 Pro produce JSON con pasos previstos
3. Validation: schema + dependencia + permiso por paso
4. Execution loop: para cada paso, execute → validate → checkpoint
5. On failure: replan (decide próximo paso con contexto de falla)
6. On success: report + audit log

Por qué importa: el planning explícito permite (a) revisión humana antes de ejecución en casos de riesgo, (b) replaneamiento en lugar de loop infinito, (c) auditoría de lo que el agente intentó hacer.

Idempotencia por defecto

Cada tool y cada paso debe ser idempotente — re-ejecutar con los mismos parámetros no crea efecto doble.

Cómo garantizarlo:

• Claves de idempotencia en creación de recurso (UUID v4 derivado de intención + step).
• Verificar antes de crear: "si ya existe ticket para este caso, vincular en vez de crear".
• Operaciones PUT/upsert en vez de POST cuando sea posible.
• Retry con misma idempotency key.

Sin esto, el retry tras timeout duplica registros — pesadilla en ERP/CRM.

Patrón Saga (compensación)

Cuando el paso N falla después de que los pasos 1..N-1 tuvieron efecto real, el agente debe deshacer en orden inverso. Cada paso declara su compensación correspondiente.

Ejemplo de onboarding de empleado:

Si el paso 4 falla, el agente corre compensación 3 → 2 → 1 y reporta. Estado consistente, sin "usuario huérfano".

Checkpoint de estado

Persistir estado tras cada paso completado permite (a) retomar tras falla sin rehacer todo, (b) continuar tras reinicio del proceso, (c) auditar progreso en tiempo real.

Patrón: tabla agent_executions en Firestore/Spanner con:

• execution_id, agent_name, user_id, started_at.
• plan_json (versionado).
• steps[] con status, input, output, timestamp, latency.
• compensations[] ya ejecutadas.
• final_status, final_output.

Cloud Workflows también sirve para orquestación explícita; en casos con lógica dinámica, mantenga en código + estado propio.

Observabilidad: trace, no solo log

En multi-step, el log lineal no basta. Use:

• Trace distribuido (OpenTelemetry → Cloud Trace): cada paso es un span, con padre = ejecución.
• Atributos: tool llamada, modelo, tokens in/out, latencia, costo.
• Eventos (no logs sueltos): "plan_generated", "step_started", "step_failed", "compensation_started".
• Dashboards por agente: latencia p50/p95/p99 por paso, tasa de falla por tool, costo por ejecución.
• Alertas: latencia > X, tasa de falla > Y, costo promedio sobre baseline.

Decisión dinámica: ReAct vs DAG

DAG fijo: pasos determinados en design time. Más predecible, más auditable, menos flexible. Bueno para procesos estables (KYC, onboarding estándar).

ReAct (reason-act loop): el agente decide el próximo paso en cada iteración, basado en el resultado anterior. Más flexible, menos predecible, exige guardrails de loop y costo.

Patrón Autenticare: comience con DAG. Migre a ReAct solo donde los casos justifiquen alta variabilidad. El híbrido funciona — esqueleto DAG con sub-agente ReAct en puntos definidos.

Límites de loop

ReAct sin límite se convierte en agente en loop infinito (o "agent loop" gastando tokens). Siempre:

• Max iterations hard cap (ej.: 12 pasos).
• Max tool calls por ejecución.
• Max costo por ejecución (token budget).
• Detección de loop: si el mismo tool con el mismo parámetro 2x, alerta + escalación.

Hand-off humano

En cualquier paso, si la confianza es baja o la ambigüedad alta, el agente debe poder pausar y pedir input humano:

• Persistir estado completo.
• Notificar humano (Slack, e-mail, cola).
• Esperar respuesta con timeout.
• Retomar o cancelar según decisión.

Es lo que separa "agente que intenta todo" de "agente con madurez para pedir ayuda".

Stack que usamos en proyectos Autenticare

• Vertex AI Agent Builder: definición del agente + tools.
• Cloud Run jobs: orquestación estable de larga duración.
• Firestore: estado de ejecución.
• Pub/Sub: hand-off asíncrono y notificación.
• Cloud Trace + Looker: observabilidad.
• BigQuery: análisis histórico y auditoría.

Errores comunes

1. Sin idempotencia → retry duplica registro.
2. Sin compensación → estado inconsistente.
3. Sin max iterations → loop infinito.
4. Sin checkpoint → reejecuta todo tras falla de infra.
5. Sin hand-off → agente "se traba" en decisión fuera de alcance.
6. Sin trace → el debug se convierte en arqueología en log.

Un agente que pide ayuda es más maduro que un agente que intenta todo. El hand-off humano en caso de baja confianza no es debilidad — es arquitectura.

Lea también

• Case KYC banco mediano (8 pasos)
• Case triage aseguradora
• RAG corporativo