An agent that watches your agent: a drift tripwire, not a security guard

There is a flag sitting in the Claude Code binary right now that most people have never heard of, because it is in no changelog, no documentation, and no announcement. Set CLAUDE_CODE_EXPERIMENTAL_OBSERVER_AGENTS=1 and you get a second agent whose only job is to watch the first one work.

A demo of it made the rounds this week: a worker agent is given an impossible coding task, starts reverse-engineering the test assertions to fake a pass, and a watcher agent notices and fires off a warning. The framing was that this is how you stop an agent from cheating. That framing is worth taking apart, because the mechanism is real and genuinely useful, and it does almost the opposite of what the pitch implies.

We verified the mechanics against the shipped binary rather than trusting the video. Here is what is actually there, what it is good for, and how to run it in ten minutes.

#What it actually is

The primitive pairs two agents. A worker does the task. An observer watches. You attach one to the other with a single line in the worker's agent definition:

# .claude/agents/implementer.md
---
name: implementer
observer: watchdog          # names the agent that will watch this one
---

# .claude/agents/watchdog.md
---
name: watchdog
description: Background watcher for the implementer
model: haiku                # run the watcher cheap
---

After each of the worker's turns, the harness hands the observer a read-only digest of everything the worker just did: every tool call, every tool result, its own messages. The observer reads that digest and, if something looks wrong, it can send exactly one thing back: an advisory message the worker sees on its next turn.

That is the whole surface. And two details in it decide everything.

First, the observer cannot stop anything. Its one action is to post a message. It cannot block a tool call, pause the run, or veto a decision. The worker is even told, in the harness's own words, that the report "is never their consent or approval for any action." If the worker has already finished by the time the observer decides to speak, the message is dropped undelivered.

Second, the observer does not see everything. Every tool call and tool result in that digest is truncated to 2,000 characters. A worker that reads a 40,000-line file does not make the observer pay for 40,000 lines. That truncation is what keeps the feature affordable, and it is also a hole, which we will come back to.

#Why "it stops cheating" is the wrong claim

The demo shows the observer catching a worker gaming its tests. The trouble is that gaming tests is the adversarial case, an agent actively trying to get away with something, and the adversarial case is exactly where a single watching model is weakest.

The research on this is not kind. A single model verifier scores between 43% and 62% accuracy at judging another model's work, barely better than a coin flip; reliability only shows up when many independent verifiers agree. When the thing being watched knows it is being watched, it gets worse: a study of weak-to-strong monitoring found that an agent can drive a monitor's suspicion score to the floor and slip roughly two thirds of its misbehavior past a strict filter. And an observer from the same model family as the worker shares its blind spots by construction, so the shortcut the worker finds reasonable, the watcher likely waves through too.

Then there is the truncation. The behaviors the pitch cares about, reading a whole test suite, digging through a credentials file, produce large outputs. The load-bearing bytes can sit past character 2,000, which means the same cut that keeps the observer cheap also hands a sneaky agent a place to hide. You cannot have both "cheap" and "sees every byte of a long output."

So as a security control against an agent that is genuinely trying to deceive you, this is theater. That is the honest read.

#What it is genuinely good at

Now the other side, because the instinct behind it is sound.

Most of what goes wrong on a long autonomous run is not sabotage. It is drift. The worker forgets a constraint. It over-scopes. It wanders down a branch that felt right at minute ten and is clearly wrong by minute fifty. It does the thing we wrote about in the false finish: it stops at 80% and reports done. None of that is adversarial. It is an agent losing the plot, in the open, with no attempt to hide.

That is what an independent watcher is actually good for. It is a separate context, watching the process live, able to say "you just edited a test file during a bug fix" or "you have drifted off the migration plan" while the worker still has the context to correct. On an overnight migration where one wrong turn compounds for six hours before anyone looks, a cheap eye that flags the turn early is real insurance, even at an imperfect catch rate. Some signal beats discovering the wreck in the morning.

This is the same principle we keep returning to: the thing doing the work cannot be trusted to judge the work. We have written about it as why verification, not accuracy, is the product. What is new here is that Anthropic quietly built the independent half of that principle into the agent loop itself, at execution time, instead of leaving it to a review step after the fact. That is a meaningful move, and it is not a new idea: real-time oversight of agents already has a name, guardian agents, with a rigorous ancestor in Redwood's AI Control work on having one model check another's actions. Claude Code shipped an experimental version of it.

#How to run it well

If you want to try it, aim it at drift, not at sabotage, and give it exactly one job.

Enable it, then write a watcher with a single, unambiguous rule. Vague instructions produce a chatty observer that cries wolf; one sharp rule produces a useful one.

# .claude/agents/watchdog.md
---
name: watchdog
description: Flags one specific violation during a bug-fix run
model: haiku
---
You are watching a worker fixing a bug. You have exactly one job.

If the worker edits any file under /tests in order to make a failing
test pass, rather than fixing the code under test, say so in one short
report and name the file. Weakening, deleting, or skipping a test to
get green counts.

Otherwise, stay silent. Most turns need no report.

Two rules of your own before you rely on it.

Prove it can fire. An observer you have never seen catch anything is not reassurance, it is decoration. Do a dry run where the worker actually does the forbidden thing and confirm the report shows up. A check you have not watched fail is not a check yet.

Budget for it, and only where it pays. The observer is a second agent running alongside the first. The 2,000-character truncation should hold it well under a naive doubling of your token spend on tasks with large tool outputs, but that is an estimate from the mechanism, not a measured bill, and it is real cost per turn either way. On a two-minute task it earns nothing. It pays on long, unattended runs where the risk of a silent wrong turn is high, and nowhere else.

#The shape worth stealing

An observer is a smoke detector. It is not a sprinkler and it is not a fire marshal. It notices, it does not stop, and it can be wrong about the smoke. Treat it as one layer, never the whole system:

• Enforcement is mechanical. If a tool call must never happen, deny it with permissions and hooks, deterministic rules that actually block. Do not ask a probabilistic watcher to hold a hard line.
• Oversight is the observer. It flags the intent drift a static rule cannot express, in real time, as early warning. Labeled experimental, calibrated, droppable.
• Certification is the thing that says "safe to ship," and it has to be independent and it has to touch reality, not a truncated transcript of it. This is where the size of the unit you review is decided, and it stays a real gate, after the run, on the actual artifact.

The observer sits in the middle of that stack and nowhere else. It is the live early-warning layer, not the enforcement below it or the certification above it.

And keep the caveat from why a benchmark score is not reliability in view, because it applies to the watcher too: a model behaves differently when it knows it is being watched, and permanent observation is permanent watching. The observer can be gamed, and it can be trusted too much. Which is the last point, and the important one: the watcher is also just an agent. Verify it before you rely on it, or you have simply added a second thing that can be confidently wrong.