--- slug: trusted-monitoring type: pattern summary: "One agent watches another work, verifies its claims against ground truth, and steers or escalates when the watched agent goes wrong." created: 2026-08-06 updated: 2026-08-06 related: steering-loop: relation: depends-on note: "The monitor supervises a steering loop from the outside and can inject a second stream of correction into it." agent-trace: relation: uses note: "The monitor reads the watched agent's trace as its primary evidence, then checks that trace's claims against ground truth." agentops: relation: depends-on note: "Monitoring runs on the telemetry, logs, and cost signals that AgentOps captures while agents run." human-in-the-loop: relation: related note: "The human is an optional router for the monitor's steering, ratifying its judgment before it reaches the working agent, not a required participant." llm-as-judge: relation: contrasts-with note: "A judge scores a finished output against a rubric; a monitor supervises a live process with its own tools and ground-truth access." generator-evaluator: relation: contrasts-with note: "Generator-Evaluator separates roles inside one construction loop; trusted monitoring is the out-of-band analog that watches the loop from outside it." code-review: relation: contrasts-with note: "Code review inspects a finished diff after the fact; monitoring watches the process that produces the diff while the work is still running." agent-teams: relation: related note: "A team of agents is a topology the monitor sits outside of, watching the collaboration without joining it." orchestrator-workers: relation: related note: "Orchestrator-Workers is one of the topologies a monitor supervises from outside the working session." --- # Trusted Monitoring > **Pattern:** A named solution to a recurring problem. *Trusted monitoring puts one agent in charge of watching another work: reading its transcript, checking its claims against ground truth, and steering or escalating when the watched agent goes wrong.* *Also known as: Agent-Supervises-Agent, Out-of-Band Supervision* > **📝 Where the name comes from:** The term comes from AI-safety research, where a *trusted* model is a weaker one you have reason to believe is aligned. It watches an *untrusted*, stronger model for suspicious actions. Agentic-coding practitioners borrowed the wiring but changed the threat model. > > Here, the watcher is usually the stronger model. It looks for fallibility rather than sabotage: a busy or cheaper orchestrator that misreads scope, stops converging, or keeps retrying a failure that needs a new approach. Same architecture, inverted capability direction. ## Understand This First - [Steering Loop](steering-loop.md) — the act-sense-decide-adjust cycle the watched agent runs and the monitor supervises. - [Agent Trace](agent-trace.md) — the execution record the monitor reads as its primary evidence. ## Context You now run more agent sessions than you can watch. Three are refactoring different modules. Another is grinding through a migration, while a fifth orchestrates a multi-step build with its own subagents. You can inspect any one session, attach to it, and answer its prompts. You can't hold all five transcripts in your head and notice when the migration has retried the same broken step for twenty minutes. Its problem is architectural. Another attempt won't fix it. At the **agentic** level, this is a supervision problem, and supervision doesn't have to be human. A monitor watches another agent's [trace](agent-trace.md), judges whether the work is progressing, and acts when it isn't. Session dashboards let a person inspect and attach to parallel work. Trusted monitoring goes further: the watcher reasons about what it sees when the person can't watch. ## Problem How do you keep a working agent on track when nobody can watch it, and its own [steering loop](steering-loop.md) can't tell a recoverable failure from a dead end? An agent inside its own loop is a poor judge of its convergence. It treats each iteration as fresh, missing that iteration nineteen repeats iteration four with different variable names. Its confident summary may not match what's on disk. A person could catch either failure, but watching five sessions in real time defeats the point of parallel work. Watching none lets a runaway loop burn a day's budget. ## Forces - **Attention is scarce and doesn't parallelize.** Splitting one person's attention across many live sessions means supervising none of them well. - **Narration isn't evidence.** A transcript may say "all tests pass" or "the file is updated." The repository, process table, and logs decide whether that's true. - **Some failures are outside the loop's reach.** A retry may clear a flaky test. It can't repair a task the agent has fundamentally misread. - **A watcher can corrupt the work it judges.** Writing into the working session's context may contaminate the evidence or let the watched agent argue against a correct finding. - **Capability costs money.** A strong model makes a better monitor, but running one over every session turns cadence and model tier into budget decisions. ## Solution **Stand up a separate, out-of-band agent that reads the working session's trace, verifies its claims against ground truth, and returns steering through an independent channel.** Here, ground truth means the repository, logs, processes, and other evidence the worker's narration doesn't control. Four structural choices make this work. **Keep the monitor out of band.** It reads the transcript and shared artifacts such as the repository, logs, and running processes. It can't write into the watched session's context. This separation keeps the work from contaminating its supervision and prevents a confused worker from arguing the monitor out of a correct call. **Verify; don't trust the narration.** When the trace says a gate passed, the monitor reruns the gate or reads its output. When it says a file was written, the monitor checks the repository state and artifact hash. The transcript is a claim; ground truth is the evidence. Without independent verification, the monitor is an expensive log viewer. **Classify the failure before you steer.** The monitor must distinguish a review loop that needs another pass from a non-converging *failure generator*. A loop tightening toward a fixed point is healthy. A loop repeating the same failure with cosmetic variation needs a different approach or a human decision, not encouragement to try again. **Choose the steering route.** For high-stakes work, a person can ratify the monitor's judgment before relaying it. Lower-stakes work may allow direct session-to-session steering. The monitor can also remain advisory and log its finding for later. Human ratification is one configuration, not part of the definition. Set two more parameters independently. **Capability direction** depends on the goal. Safety research runs a weaker trusted monitor over a stronger worker; quality supervision usually reverses that relationship, with a senior model watching a cheaper or busier one. **Cadence** can range from one consultation to a standing periodic check. A recurring instruction such as *every ten minutes, review the live development thread and steer as necessary* makes the monitor a loop of its own. The person sets its interval and authority once instead of watching every turn. > **💡 Tip:** Before a monitor can steer, define ground truth and give it direct access. A monitor that can run the same tests, read the same logs, and list the same processes can verify claims. One with only the transcript can notice when the story stops making sense, but it can't prove what happened. ## How It Plays Out A senior-model session supervises an orchestration thread driving a multi-step build. The transcript reports steady progress: proposals harvested, gates running, phases advancing. The monitor checks those claims against the repository. It confirms the proposal files, checks the gate processes, and matches the reported candidate hashes. Most review loops are converging, but one is spinning. The monitor scores the thread's implement-or-defer decisions and gives the operator a short steering prompt to ratify and relay. The operator makes one decision instead of performing the whole supervision pass. A team runs eight coding sessions overnight on separate services. A monitor checks the batch every fifteen minutes. Most checks report "all converging, no action." Twice, a session declares victory while the monitor's independent test run remains red. The monitor trusts the exit codes, not the summary, and flags both sessions for morning review. > **⚠️ Warning:** A monitor that shares the worker's blind spot manufactures false confidence. If a mocked-out test fools the worker and the monitor only reads "tests pass," both certify the same mistake. Independent verification must reach a source the worker didn't author. ## Consequences Trusted monitoring scales supervision past the number of sessions a person can watch. A monitor reads a full transcript quickly and doesn't lose focus on the fortieth iteration. Its separation and independent checks expose two failures workers hide well: a loop that isn't converging and a claim that isn't true. With human ratification, a full supervision shift becomes one decision at the moment judgment matters. A standing monitor adds its own token bill, so you'll revisit cadence and model tier. Its value also depends on access: with the transcript alone, you've built a summarizer, not a supervisor. The monitor can still be confidently wrong. High-stakes configurations should keep a person at the ratification step instead of wiring every judgment into the work. Supervising the supervisor doesn't disappear; it moves up a level and gets cheaper. ## Sources - The name and architecture come from AI-control research, most directly Ryan Greenblatt, Buck Shlegeris, and colleagues at Redwood Research in ["AI Control: Improving Safety Despite Intentional Subversion"](https://arxiv.org/abs/2312.06942) (2023), which defines trusted monitoring, untrusted monitoring, and trusted editing as control protocols and supplies the trusted/untrusted vocabulary this pattern borrows. Redwood's ongoing [AI control research](https://www.redwoodresearch.org/research/ai-control) develops the family further, including how monitors resist collusion. - OpenAI's work on detecting misbehavior in frontier reasoning models demonstrated a weaker model monitoring a stronger model's reasoning stream in production, catching reward-hacking in code, which is the practical precedent for running a monitor over a more capable worker rather than a less capable one. - The idea of a human operator as a feedback element inside a control loop, rather than an observer outside it, traces to Norbert Wiener's cybernetics; trusted monitoring generalizes that element from a human to an agent while keeping the human available as an optional insertion point. ## Further Reading - [Steering Loop](steering-loop.md) covers the inner, middle, and outer loops of agentic work and where human attention migrates as a harness matures; the monitor is a way to occupy the middle loop without a human sitting in it full time. --- - [Next: Feedforward](feedforward.md) - [Previous: Human in the Loop](human-in-the-loop.md)