Supervisory Agents: The Mesh That Watches the Mesh

A planner-executor mesh we reviewed last year had been running for six weeks without a single unhandled exception, which the team had taken as evidence that it was working well. It wasn't. One of the executor agents had settled into a pattern where it re-attempted a failing tool call with slightly reworded arguments an average of four times per task before giving up and falling back to a degraded path — technically successful, technically within its retry budget, and quietly burning four times the token cost and wall-clock time the task should have taken, for six weeks, invisible to every alert the team had configured, because nothing about the pattern was an error. It was a policy problem wearing the shape of normal operation, and normal-operation monitoring will never catch it, because there's nothing abnormal in any single call.

This is the gap that a supervisory agent layer exists to close, and it's worth being precise about why it's a distinct architectural layer rather than just "better monitoring" bolted onto the existing mesh.

Why this isn't a job for better logging

Traditional observability answers questions about individual calls and services: did this request succeed, how long did it take, did it throw. A mesh of agents making autonomous decisions about which tools to call, in what sequence, to accomplish a goal, fails in ways that are invisible at that granularity — drift, where an agent's behavior slowly diverges from its intended policy without any single step being wrong; loops, where agents alternate work back and forth without converging, each individual handoff looking like legitimate task progress; and boundary violations, where an agent technically has access to a tool or a piece of data it shouldn't be using for the current task, and uses it anyway because nothing in its immediate context flags that as wrong. None of these produce an error. All three require watching the mesh's behavior over a window of time and across multiple agents simultaneously, which is a different kind of observer than the one built into each agent's own execution loop — an observer that isn't a participant in the task, and isn't the same code that could be causing the problem it's meant to catch.

What a supervisory agent actually does

We build this as a genuinely separate agent — different prompt, different model in some deployments, and critically, no ability to directly act on the client's systems, only to flag, throttle, or escalate. It watches three things continuously: task-level progress against expected shape (is this planner-executor cycle converging toward completion at a rate consistent with similar past tasks, or has it exceeded the step count or time budget that 95% of comparable tasks complete within, which is the drift signal that caught the retry-loop case above); cross-agent policy conformance (is any agent in the mesh invoking a tool or accessing data outside the scope defined for its current task, checked against the actual policy definition rather than against what the agent's own prompt claims its scope is, because a prompt-level constraint is not a security boundary); and resource and cost trajectory (is this task's token spend, tool-call count, or external API cost tracking within the range that similar tasks have historically required, flagged before it completes rather than reconciled afterward in a monthly bill).

The part that matters architecturally is that the supervisory agent's authority is narrow and specific — it can pause a task, escalate to a human, or throttle an agent's rate of action, but it does not have the same tool access as the agents it's watching, and it cannot silently correct their behavior on its own. That asymmetry is deliberate: a supervisory layer that can itself take arbitrary action on the client's systems is just another agent in the mesh with extra privileges, and it inherits the same drift and loop risks it was built to catch, except now with less visibility, because who's watching the watcher becomes an unanswered question the moment it starts acting instead of just flagging.

Where this is genuinely distinct from human review

Human review catches things a supervisory agent structurally can't — judgment about whether an outcome is actually good for the business, context a policy definition didn't anticipate, the kind of "this is technically fine but wrong" call that requires understanding intent, not just conformance. A supervisory agent catches things a human structurally can't at the volume and speed multi-agent systems operate at — nobody is going to notice a retry pattern burning 4x cost across forty concurrent tasks by reading logs, and nobody should have to. The two layers aren't substitutes; the supervisory agent's real job is triage, surfacing the small number of cases where its narrower, faster pattern-matching suggests a human's broader judgment is actually needed, so that human attention gets spent on the handful of cases that warrant it instead of being asked to watch everything and inevitably watching nothing closely.