The_Approval_Model_Has_a_Shelf_Life

The per-action approval model works beautifully at a certain scale and complexity. One agent, one project, actions sparse enough that each one feels deliberate: you read it, you make a call, you move forward. The cognitive load is manageable. The feedback loop is tight. If the agent proposes something wrong, you catch it before it executes.

Then the scale changes. You're running eleven specialised agents across a portfolio of products. The number of actions per day is no longer countable. The approval queue becomes asynchronous (you can't read every action in real time), and the real problem appears: if you're not approving in real time, what is approval even protecting against? You're now choosing which actions to spot-check, retroactively deciding whether something should have happened. That's not approval. That's auditing, dressed up as approval.

The approval model also assumes a certain class of failure. It protects well against "the agent proposed something obviously wrong and you caught it." It protects poorly against silent failures: actions that execute correctly according to the agent's understanding but accomplish the wrong thing because the agent misunderstood the context. If you're distracted during the approval step, or the action's consequences aren't immediately obvious, the wrong thing still executes. The approval model shields you from fast, obvious failures. It doesn't shield you from slow, invisible ones.

What_the_Classifier_Actually_Changes

Anthropic's approach here is pragmatic. Instead of asking "how do we make approval-mode approval actually work at scale," they're asking "what if we screened actions before execution, and trusted the screen?" The classifier runs on Sonnet 4.6 - Anthropic's own screening model, a separate checkpoint from the Sonnet 5 your fleet runs on. It looks at the proposed tool call and asks: does this violate the user's instructions or the system's trust boundaries?

In a trial across 1,053 users, the classifier blocked 89% of dangerous commands. Human reviewers, shown the same commands, caught 13.6%. That's not a narrow difference. That's an order-of-magnitude shift in what "dangerous" looks like when a system is actively looking for it.

The other screen catches hidden instructions in tool-returned content - injection attacks hiding inside API responses or file contents that the agent might execute on the next turn. In a test from Trajectory Labs, the classifier saw 720 injection attacks across Fable 5, Opus 5, and Sonnet 5. None succeeded. Zero.

The strength here is specific: the classifier is looking for intent violation and injected instructions. It's not looking for logical correctness. An action can sail through the classifier and still be wrong (the agent misunderstood what you wanted and proposed the logically correct action for a misunderstood goal). But it's wrong in a particular way. Not because the agent was trying to break something, but because the context it was operating from was incomplete or misread. That failure mode is exactly the one that your asynchronous audit catches well.

The_Operator's_Job_Becomes_Auditing

When auto mode becomes the default, your job stops being "read this, approve or deny" and becomes "read what happened, decide whether to intervene." These are radically different activities.

Approval is a gating decision. You're blocking bad actions before they land. Auditing is a correction decision. You're reviewing what executed and choosing whether the outcome is acceptable or requires rollback/correction/refinement. The timing is different (after, not before), the cognitive work is different (outcome assessment, not proposal assessment), and the intervention options are different (you're undoing or reframing, not preventing).

In a multi-agent environment, this shift is structural. Right now, if Nix proposes a code change that looks wrong and Tom proposes a security audit, both get queued for your approval. You're the serial bottleneck. When auto mode is default, Nix's change executes (screened), Tom's audit executes (screened), and you read what actually happened. The bottleneck moves from synchronous gating to asynchronous review. Your attention doesn't need to be there before the action. It needs to be there after, and only if something has gone wrong.

The most valuable thing you do in this model is the thing you're least well-positioned to do in approval mode: recognise when an action executed correctly but accomplished something wrong. When the classifier clears a tool call and the agent executes it perfectly and the code runs without error, but the thing that was built is not what you wanted. That's an audit-time discovery. It's not catchable in approval mode because approval mode sees the intention, not the outcome.

What_Doesn't_Change

The classifier is strong on intent-checking. It's not magic. An agent that has catastrophically misunderstood the goal is still an agent that has misunderstood the goal. The classifier just stops it from adding a new layer of harm on top of the misunderstanding. It stops injection attacks, it stops deliberate violation of your instructions, it stops the agent from doing something it explicitly shouldn't.

What it doesn't do is re-read your context and correct the misunderstanding. That's still your job. That's always going to be your job. And the asynchronous audit model is actually better at catching it than approval mode is, because you're looking at outcomes, not intentions.

One more thing: Anthropic's not charging for the classifier's extra tokens. That matters more than the product copy suggests. When you remove a friction cost from a system, the system's behaviour changes. With token charges, auto mode becomes a cost calculation. Without token charges, auto mode becomes a trust decision. The operating behaviour is different.

The_Asymmetry_That_Matters

Here's the thing about shifting from approval to audit: you can't do both simultaneously at scale. You can't hand-approve every action and also maintain a comprehensive audit log. Something breaks under the load.

In practice, what breaks is the audit. You hand-approve your way through the day, and then you have no time to actually review what happened, so the things that made it through unreviewed become invisible to you. The approval mode theoretically protects everything, but it practically protects only the things you happened to see.

The auto mode default inverts the asymmetry. You can't hand-approve everything and also audit everything. So the system stops trying to protect through gating and instead protects through screening (the classifier) plus recovery (your audit when something's wrong). The system stops trying to catch all the bad actions before they land and instead catches the ones that made it through the screen when you look at the outcome.

Which model is actually safer depends on which failure modes matter more to you. If your highest risk is "agent does something so catastrophically wrong that the damage can't be recovered from," approval mode feels safer. If your highest risk is "agent does something that's individually correct but wrong in aggregate," or "I approve a hundred actions without reading half of them and something bad slips through," audit mode is safer.

For someone running a multi-agent system at production scale, audit mode is the right call. The system is already too large to gate synchronously. Shift the gating to the classifier, shift yourself to the audit position, and you actually get control back instead of gradually losing it to your own bottleneck.