Gobernanza multi-agent: coordinación, permisos y control de escalaciones

Idea en 30 segundos

Multi-agent governance es control de runtime para la coordinación entre agentes: quién es owner de una subtask, quién puede delegar y cuándo debe detenerse una cadena de handoff.

Cuándo se necesita:
cuando varios agentes trabajan en un mismo workflow y existe riesgo de acciones duplicadas, conflictos de rol o fan-out descontrolado.

Problema

Sin governance, un sistema multi-agent pasa rápido al caos: los agentes se delegan tareas entre sí, duplican llamadas y gastan presupuesto compartido sin progreso final. En demo esto suele verse "vivo". En producción se convierte en latencia, costos extra y resultado inestable.

Consecuencias típicas:

• una subtask tiene varios owners
• la cadena de handoff crece sin cierre
• el shared budget se consume en duplicados

Analogía: es como un equipo sin despachador. Todos están ocupados, pero hacen lo mismo, y las tareas críticas quedan atascadas en transferencias.

Y cada minuto sin reglas de coordinación aumenta el riesgo de falla en cascada entre agentes.

Solución

La solución es añadir una policy layer centralizada para la multi-agent orchestration en runtime. Cada delegación pasa validaciones: role ownership, handoff limits, shared budgets y approval gate para acciones riesgosas.

Runtime necesita un modelo único de outcomes:

• allow
• stop
• approval_required

Stop reasons típicas en el circuito multi-agent:

• ownership_conflict
• handoff_budget_exceeded
• delegation_depth_exceeded
• shared_budget_exceeded

Esto no es sugerencia del modelo, sino control de ejecución forzado antes de cada nueva delegación.

Multi-agent governance ≠ orchestration

Son capas distintas del sistema:

• Orchestration define el ruteo de tareas entre agentes.
• Governance limita ese ruteo con reglas policy.

Una sin la otra no funciona:

• sin orchestration no hay workflow gestionado
• sin governance, orchestration degenera fácil en duplicados, conflictos y loops

Ejemplo:

• orchestration: planner -> researcher -> writer
• governance: max_handoffs=8, max_depth=3, ownership_lock=true

Componentes de multi-agent governance

Estos componentes trabajan juntos en cada handoff entre agentes.

Ejemplo de alerta:

Slack: 🛑 Multi-Agent run run_742 stopped: ownership_conflict, handoff=planner -> researcher, task=refund_check.

Cómo se ve en la arquitectura

La multi-agent policy layer se ubica en el orchestrator runtime loop entre planificación y delegación de subtasks. Cada decisión (allow o stop) se registra en audit log. Es una capa policy lógica dentro de runtime, no un servicio separado.

approval_required para acciones write riesgosas se maneja en un approval flow separado sobre este circuito.

Cada handoff pasa por este flow antes de ejecutarse:

• orchestrator runtime forma la siguiente subtask
• policy verifica owner, handoff budget, delegation depth y shared budgets
• allow -> la subtask se delega a un agente específico
• stop -> orchestrator runtime pasa a fallback (single-agent o constrained mode)
• ambas decisiones se escriben en audit log

Ejemplo

planner delega refund_check a researcher, pero esta subtask ya tiene owner=billing_agent. Policy devuelve stop (reason=ownership_conflict).

Resultado:

• la delegación no se ejecuta
• el run no se expande en duplicados
• en logs se ve conflicto de owner y razón de stop

Multi-agent governance detiene el incidente antes del fan-out, no después de perder presupuesto.

En código se ve así

El esquema simplificado de arriba muestra el flujo principal. Punto crítico: la verificación debe correr de forma centralizada, si no los agentes pueden esquivar límites con handoffs paralelos.

Ejemplo de configuración policy:

multi_agent:
  max_agents_per_run: 4
  max_handoffs: 8
  max_delegation_depth: 3
  shared_max_usd: 30
  shared_max_tool_calls: 120
  require_approval_for:
    - billing.refund.create

task = orchestrator.next_task(state)
decision = multi_agent_policy.check(task, state)

audit.log(
    run_id,
    phase="pre_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    from_agent=task.from_agent,
    to_agent=task.to_agent,
    depth=state.delegation_depth,
)

if decision.outcome == "approval_required":
    # approve/resume flow se loguea como paso separado:
    # approval_required -> approval_granted -> allow
    return stop("approval_required")

if decision.outcome == "stop":
    return stop(decision.reason)

result = orchestrator.delegate(task)

shared_budget.consume(
    usd=result.cost_usd,
    tool_calls=result.tool_calls,
)

post_budget_decision = shared_budget.check()
if not post_budget_decision.ok:
    audit.log(
        run_id,
        phase="post_handoff",
        decision="stop",
        reason=post_budget_decision.reason,
        owner=decision.owner,
        handoff_status=result.status,
    )
    return stop(post_budget_decision.reason)

audit.log(
    run_id,
    phase="post_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    handoff_status=result.status,
)

return result

Cómo se ve durante la ejecución

Escenario 1: ownership conflict

1. planner forma delegación refund_check.
2. Policy ve que owner de subtask ya está bloqueado en otro agente.
3. Decisión: stop (reason=ownership_conflict).
4. Handoff se bloquea antes de ejecutar.
5. Conflicto se registra en audit log.

Escenario 2: handoff budget exceeded

1. El run ya hizo 8 transferencias de subtasks.
2. La siguiente delegación supera max_handoffs.
3. Decisión: stop (reason=handoff_budget_exceeded).
4. Runtime cambia a fallback mode.
5. El sistema no entra en delegation loop infinito.

Escenario 3: handoff normal gestionado

1. Runtime forma nueva subtask con owner válido.
2. Policy revisa todos los límites: todo dentro de rango.
3. Decisión: allow.
4. Delegación se ejecuta y devuelve resultado.
5. Eventos pre_handoff y post_handoff se escriben en audit trail.

Errores típicos

• ejecutar varios agentes sin role ownership map
• permitir handoff sin límite de profundidad y cantidad
• contar presupuestos por agente en vez de shared por run
• no tener fallback al stop
• loguear solo resultado final sin historial de delegaciones
• mezclar reglas de orchestration y governance dentro del prompt

Resultado: el sistema parece escalable, pero bajo carga pierde control rápido.

Autoevaluación

Chequeo rápido de multi-agent governance antes de lanzar a producción:

FAQ

P: ¿Cuándo se justifica realmente un enfoque multi-agent?
R: Cuando las subtasks son realmente independientes y requieren expertise distinta. Si el workflow es corto y lineal, un solo agente suele ser más simple y fiable.

P: ¿Quién debe tomar la decisión final: orchestrator o un agente aparte?
R: Mejor un orchestrator/policy layer responsable único. Si no, aumenta el riesgo de conflictos y ping-pong entre agentes.

P: ¿Los agentes pueden delegar directo sin policy check?
R: En producción, no. Cada handoff debe pasar validación centralizada de ownership, límites y presupuesto.

P: ¿Cómo contar presupuesto en un multi-agent run?
R: Como shared budget para todos los agentes en conjunto. Si no, cada agente queda "en límite" pero el run total se pasa.

P: ¿Multi-agent governance reemplaza step limits y rate limiting?
R: No. Los complementa: gobierna coordinación entre agentes, mientras step/rate controls gobiernan comportamiento de ejecución.

Dónde encaja Multi-Agent Governance en el sistema

Multi-agent governance es la capa de Agent Governance para equipos de agentes orquestados. Junto con RBAC, budget controls, approval, rate limiting y audit forma un runtime controlado para workflows complejos.

Páginas relacionadas

Siguiente sobre este tema:

• Resumen de Agent Governance — modelo base de governance en producción.
• Step limits — cómo parar loops antes de incidentes.
• Rate limiting para agentes — cómo controlar picos de llamadas externas.
• Human approval — cómo aprobar acciones riesgosas.
• Audit logs para agentes — cómo reconstruir cadenas de decisiones de handoff.