Patrón de agente supervisor: control de políticas y riesgo

Esencia del patron

Supervisor Agent es un patron donde un agente separado controla la ejecucion: revisa acciones propuestas, aplica reglas y decide si se puede continuar.

Cuando usarlo: cuando acciones criticas deben aprobarse por politica antes de continuar.

En lugar de confiar ciegamente en el worker, Supervisor:

• revisa cada accion critica
• la compara con politicas
• devuelve decision: approve, revise, block o escalate
• registra la razon de la decision en logs

Problema

Imagina que un worker agent ejecuta una tarea en produccion y tiene acceso a herramientas.

Propone una accion tecnicamente valida que viola una politica:

• correo a audiencia equivocada
• SQL query con riesgo de modificar datos
• gasto por encima del presupuesto
• acceso a datos sensibles sin el access scope requerido

Un paso tecnicamente posible no siempre es permitido o seguro para el negocio.

Sin control separado, esto puede pasar directo a ejecucion.

Consecuencias:

• incidentes en produccion
• violaciones de seguridad y compliance
• perdidas financieras inesperadas
• auditoria debil y postmortem dificil

Ahi esta el problema: el worker puede proponer una accion que "funciona tecnicamente", pero es inaceptable por politica.

Solucion

Supervisor agrega una policy-control layer entre propuesta de accion y ejecucion.

Analogia: es como un technical review antes de lanzar a produccion. El worker propone un paso y el supervisor verifica si es seguro y permitido. Solo despues de eso la accion puede ejecutarse.

Principio clave: primero verificacion y decision del supervisor, despues ejecucion.

El worker propone una accion y supervisor-policy devuelve:

• approve
• revise
• block
• escalate

Proceso controlado:

1. Observe: recibir propuesta de accion del worker
2. Evaluate: revisar contra policy + execution runtime state
3. Decide: approve/revise/block/escalate
4. Enforce: ejecutar, devolver para revision o detener
5. Log: registrar decision y motivo

Esto da:

• menor riesgo de acciones inseguras antes de ejecutar
• imposibilidad de saltar la policy
• escalacion controlada a un humano
• auditoria transparente de decisiones

Funciona bien si:

• worker no tiene bypass directo de la execution layer
• policy revisa intent + runtime context
• las decisiones del supervisor realmente se aplican
• acciones high-risk no se auto-aprueban

El modelo puede "querer" ejecutar de inmediato, pero supervisor-policy es quien determina si la accion esta permitida.

Como funciona

Supervisor no ejecuta la tarea de negocio por si mismo.

Controla si el siguiente paso puede ejecutarse verificando:

• seguridad
• presupuesto
• permisos
• compliance
• stop conditions

En codigo se ve asi

proposal = worker.next_action(context)

decision = supervisor.review(
    action=proposal,
    budget_state=budget_state,
    policy=policy,
)

if decision.type == "approve":
    result = execute(proposal)
    context.append(result)
elif decision.type == "revise":
    context.append(f"Supervisor feedback: {decision.reason}")
elif decision.type == "escalate":
    wait_for_human_approval(proposal)
else:
    stop(reason=decision.reason)

Supervisor no reemplaza al Worker Agent. Agrega una verificacion entre planificacion y ejecucion.

Como se ve durante la ejecucion

Goal: procesar reembolso de cliente

Worker proposal:
- refund 5000 USD
- send confirmation email

Supervisor:
- policy check: auto-refund permitido solo hasta 1000 USD
- decision: escalate, se requiere confirmacion humana

Human approval (approve with changes):
- approved_refund_amount: 800 USD
- comment: "Apruebo reembolso solo dentro de 800 USD"

Ejecucion:
- refund 800 USD (monto desde decision humana)
- send confirmation email

Status: completado

Cuando encaja - y cuando no

Encaja

No encaja

Porque Supervisor agrega un paso adicional de revision y puede ralentizar la ejecucion.

Diferencia Frente A Guarded-Policy

En corto: Supervisor es una capa de supervision para decisiones complejas.

Guarded-Policy es una barrera automatica basada en reglas.

Cuando Usar Supervisor (vs Otros Patrones)

Usa Supervisor cuando se necesita supervision y policy-check antes del resultado final o de una accion riesgosa.

Prueba rapida:

• si necesitas "revisar politicas, compliance y riesgos" -> Supervisor
• si necesitas "solo gestionar orden de pasos" -> Orchestrator Agent
• si necesitas "bloquear/reescribir acciones automaticamente antes de ejecutar" -> Guarded-Policy Agent

Como combinar con otros patrones

• Supervisor + ReAct: Supervisor revisa cada paso Act antes de lanzar herramienta.
• Supervisor + Routing: se controla no solo la accion, sino tambien a quien se enruto la tarea.
• Supervisor + Orchestrator: politicas y limites se aplican a cada rama paralela, no solo al resultado final.

Resumen

Ventajas y desventajas

FAQ

Q: Supervisor reemplaza permisos de infraestructura (RBAC, ACL)?
A: No. Es control logico adicional. Restricciones tecnicas base deben quedarse en infraestructura.

Q: Que hacer si Supervisor bloquea demasiado acciones utiles?
A: Ajustar politicas: agregar excepciones, niveles de riesgo y reglas de human approval para escenarios grises.

Q: Supervisor puede ser single point of failure?
A: Si, si no existe fallback. Por eso normalmente se agregan timeout, safe default policy y graceful degradation.

Que sigue

Supervisor controla que agentes individuales no se salgan de limites de politica.

Pero que hacer cuando varios agentes deben colaborar entre si en una tarea compartida?