Supervisor Agent Pattern: Policy Control and Risk Stops

Pattern essence

Supervisor Agent is a pattern where a separate agent controls execution: checks proposed actions, applies rules, and decides whether execution can continue.

When to use it: when critical actions must be separately approved by policy before continuing.

Instead of unconditionally trusting the worker, Supervisor:

• checks every critical action
• compares it with policies
• returns a decision: approve, revise, block, or escalate
• logs the reason for the decision

Problem

Imagine a worker agent is running a task in production and has access to tools.

It proposes a technically valid action that violates policy:

• email to the wrong audience
• SQL query with data-change risk
• spending above budget
• access to sensitive data without required access scope

A technically possible step is not always allowed or safe for the business.

Without separate control, this may go directly into execution.

Consequences:

• incidents in production
• security and compliance violations
• unexpected financial losses
• weak audit and difficult postmortem analysis

That is the problem: a worker can propose an action that "works technically", but is unacceptable by policy.

Solution

Supervisor adds a policy-control layer between action proposal and execution.

Analogy: this is like technical review before production release. The worker proposes a step, and the supervisor checks whether it is safe and allowed. Only after that can the action be executed.

Key principle: first supervisor verification and decision, then execution.

The worker proposes an action, and supervisor-policy returns:

• approve
• revise
• block
• escalate

Controlled process:

1. Observe: get action proposal from worker
2. Evaluate: check against policy + execution runtime state
3. Decide: approve/revise/block/escalate
4. Enforce: execute, return for revision, or stop
5. Log: record decision and reason

This gives:

• lower risk of unsafe actions before execution
• no way to bypass policy
• controlled escalation to a human
• transparent audit of decisions

Works well if:

• worker has no direct bypass of the execution layer
• policy checks intent + runtime context
• supervisor decisions are actually enforced
• high-risk actions are not auto-approved

The model may "want" to execute immediately, but supervisor-policy is what determines whether the action is allowed at all.

How it works

Supervisor does not execute the business task itself.

It controls whether the next step can be executed by checking:

• safety
• budget
• permissions
• compliance
• stop conditions

In code it looks like this

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 does not replace Worker Agent. It adds a check between planning and execution.

How it looks during execution

Goal: process customer refund

Worker proposal:
- refund 5000 USD
- send confirmation email

Supervisor:
- policy check: auto-refund allowed only up to 1000 USD
- decision: escalate, human confirmation required

Human approval (approve with changes):
- approved_refund_amount: 800 USD
- comment: "Approve refund only within 800 USD"

Execution:
- refund 800 USD (amount from human decision)
- send confirmation email

Status: done

When it fits - and when it does not

Fits

Does not fit

Because Supervisor adds an extra verification step and may slow execution.

How It Differs From Guarded-Policy

In short: Supervisor is an oversight layer for complex decisions.

Guarded-Policy is an automatic rules-based barrier.

When To Use Supervisor (vs Other Patterns)

Use Supervisor when oversight and policy-check are needed before final result or risky action.

Quick test:

• if you need to "check policies, compliance, and risks" -> Supervisor
• if you need to "only manage step order" -> Orchestrator Agent
• if you need to "automatically block/rewrite actions before execution" -> Guarded-Policy Agent

How to combine with other patterns

• Supervisor + ReAct: Supervisor checks each Act step before tool execution.
• Supervisor + Routing: not only action is controlled, but also to whom the task was routed.
• Supervisor + Orchestrator: policies and limits are applied to each parallel branch, not only to the final result.

In short

Pros and Cons

FAQ

Q: Does Supervisor replace infrastructure permissions (RBAC, ACL)?
A: No. This is an additional logical control. Basic technical restrictions should remain in infrastructure.

Q: What if Supervisor blocks useful actions too often?
A: Refine policies: add exceptions, risk levels, and human approval rules for gray scenarios.

Q: Can Supervisor become a single point of failure?
A: Yes, if no fallback path exists. Therefore, systems usually add timeout, safe default policy, and graceful degradation mode.

What next

Supervisor controls that individual agents stay within policy boundaries.

But what to do when multiple agents need to collaborate on one shared task?