VIII · Safety & ControlEmerging★

Supervisor-Plus-Gate

also known as Validating Supervisor, Gated Supervisor

Supervisor controller that validates and gates LLM outputs against deterministic checks before they commit to side-effects.

This pattern helps complete certain larger patterns —

  • specialisesSupervisor★★— Place a coordinating agent above a set of specialised agents and route work to them.

Context

A multi-agent system has a supervisor that dispatches work to sub-agents and collects their outputs. The system needs to enforce policy or quality constraints that the LLMs may violate. Treating the supervisor as just a router lets bad outputs through.

Problem

A plain supervisor routes work without checking the legitimacy of returned outputs. Sub-agent results pass through to side-effects (commits, sends, writes) on the supervisor's authority. When a sub-agent's output violates a policy invariant, there is no checkpoint between 'output produced' and 'effect committed'. Distinct from a plain supervisor by mandating a hard reject signal on policy violation.

Forces

  • Sub-agent outputs are often unstructured and hard to validate generically.
  • Adding validation latency at every supervisor hop can balloon end-to-end time.
  • A 'best-effort' supervisor pattern lets soft violations through without explicit decision.

Example

A payment-approval multi-agent system has a supervisor dispatching to credit-check, fraud-check, and limit-check sub-agents. Each sub-agent returns a structured verdict. The Gate runs `approved AND fraud_score<0.3 AND amount<=daily_limit` before forwarding to the commit step. A sub-agent returning `approved=true` with no fraud field is rejected by the gate's schema check, not silently passed through.

Diagram

Solution

Therefore:

Co-locate a Gate next to the Supervisor. The Gate receives the sub-agent output, runs deterministic checks (schema validity, policy-as-code, allow-list, threshold), and emits one of {accept, reject, escalate}. Only accepted outputs flow to side-effects. Rejections produce structured errors that surface to retries or human review. Pair with supervisor, policy-as-code-gate, and typed-refusal-codes.

What this pattern forbids. No sub-agent output flows to a side-effect without passing the gate; the supervisor cannot bypass the gate on its own authority.

And the patterns that stand alongside it, or against it —

  • complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
  • complementsTyped Refusal Codes★— Define a single source of truth for machine-readable refusal codes across all guard surfaces, so refusals can be triaged mechanically rather than by string-grepping ad-hoc human-readable messages.
  • complementsStochastic-Deterministic Boundary (SDB)★— Formalize the seam between an LLM proposal and a system action as a four-part contract — proposer, verifier, commit step, reject signal — so the contract itself, not the agent's good intent, gates side-effects.
  • complementsInput/Output Guardrails★★— Validate inputs before they reach the model and outputs before they reach the user.
  • complementsPipeline Triad Pattern★— Staff each pipeline stage with a triad — Creator generates an artifact, Critic finds flaws, Arbiter makes a binding PASS/FAIL/PARTIAL decision — with four explicit human gates between stages.
  • complementsScatter-Gather Plus Saga★— Distribute tasks across worker agents and aggregate results while maintaining distributed-transaction semantics via compensating actions on partial failure.
  • complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU the agent Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance