Agent Verification

As agents produce more of the work, the scarce resource becomes knowing whether that work is correct. Posts from Oct 12–16 describe verification at three levels: checks the agent runs on itself, approval boundaries around consequential actions, and evaluation that keeps running after launch.

Part of Weekend Deep Dive #1: Agent-Scale Infrastructure.

---

What’s new this week

• Agentic verification (Addy Osmani, Elevate, Oct 14). Osmani argues that “the bottleneck has moved from writing code to knowing it’s correct,” and that the main lever is giving an agent checks it can run on its own: end-to-end tests, property-based tests and differential tests against an old system.
• Dynamic workflows (Latent Space, Oct 12). Richard MacManus reports on an Anthropic workshop at AI Engineer New York about “flows” for Claude Managed Agents, in which Claude writes the orchestration program that launches and coordinates its own subagents. Anthropic’s CJ Avilla framed the human as the bottleneck: engineers “sitting there in our GitHub trying to approve PRs.”
• Autonomy and safety in financial agents (Latent Space, Oct 14). A second report from the same conference covers talks by OpenAI, Two Sigma, Anthropic and Bloomberg on where to place controls and human judgement when agents act on financial data.
• A nine-stage evaluation framework (AWS Machine Learning Blog, Oct 16). An AWS operations team describes how it evaluates an internal multi-agent system for its field sales organisation, from defining quality to production canaries, built on Amazon Bedrock AgentCore Evaluations.

Why it matters. The code review post in this series describes the Claude Code team measuring success in human time per change rather than human reading. This week’s posts fill in what replaces line-by-line reading: evidence from checks that ran before anyone looked, approval reserved for consequential actions, and evaluations that catch quality drift no infrastructure alarm would see.

Key ideas

Before the change: checks the agent runs itself (Osmani)

• Feedback loop over model choice. Osmani writes: “I would always prefer a much better feedback loop to a slightly better model.” A self-verifying agent iterates against a check before any human sees the change.
• End-to-end tests define “done”. “Make this E2E test pass” is a target an agent can chase; a mock-based unit test can pass while agent and test share the same misunderstanding.
• Properties say what must not happen. Round-trip encoding, invariants, idempotency and equivalence force the agent to handle generated inputs, not only examples it picked itself.
• The old system is the oracle. For migrations, differential tests compare old and new outputs, with an explicit list of approved behaviour changes.
• Fast and deterministic, or the agent learns to retry. Per Osmani, flaky or slow suites teach an agent that rerunning beats fixing, and the resulting quality loss is invisible.

At the action boundary: propose, approve, trace (AI Engineer New York)

• Propose rather than act. Anthropic’s Keon Shahab described a “trust layer” of identity and permissions, a sandbox and approval layer, and ongoing checks. His trade-break agent proposes order amendments for human approval instead of making them.
• Avoid approval fatigue. Two Sigma’s John Feminella argued that approving everything both slows teams and adds risk. Auto-mode classifiers handle routine calls and send people only the requests most likely to matter; deterministic rules cover clear-cut cases.
• Controls outside the model. Bloomberg’s Andrey Rybka: “Check every call, log it, and keep a kill switch.” The control plane post maps the same layers.
• Traceability as a product feature. OpenAI’s Joseph Kim: “In finance, you need to be able to check where a number came from and understand the context around it.”

After launch: evaluation as a running system (AWS)

• Agents fail softly. Before launch, one sub-agent reported $410.08 of revenue as “$410.08 Million” while monitoring stayed green; the team writes that monitoring “told us the system had responded, not whether the answer was right.”
• A failure taxonomy drives the evaluators. Six failure types (metric swap, wrong period, wrong entity, hallucination, wrong symbols, unauthorised calculation) each get a custom evaluator, alongside built-in, third-party and deterministic checks.
• Gates, canaries and sampling. Checks run at every stage, from each staging deploy to 10 percent of live traffic, and the team reports detection time falling from days or weeks to under four hours.
• Orchestration needs its own guardrails. For dynamic workflows, Anthropic’s Harrison Stall said the model does not know its budget while running, so developers set a session budget; the Console graph shows what the lead agent passed to each subagent.

flowchart LR
    A["Agent change"] --> S["Self-checks<br/>E2E, properties, differential<br/>(Osmani, Oct 14)"]
    S --> R["Review by risk tier<br/>(Claude Code team, Oct 15)"]
    R --> B["Action boundary<br/>propose, approve, trace<br/>(AI Engineer NY, Oct 14)"]
    B --> P["Production evals<br/>gate, canary, online sampling<br/>(AWS, Oct 16)"]
    P -. "failures become tests and golden-set cases" .-> S

Composite of the sources above; not any one source’s diagram.

Analysis: the three levels share one move. Each turns a recurring human judgement into a check that runs without a person, and keeps people for the cases a check cannot settle. Osmani’s advice to write down every agent mistake “so it doesn’t happen twice,” AWS’s practice of promoting failures into the golden set, and the Claude Code team’s incident evals are the same feedback loop at different points in the lifecycle.

Open question: who verifies the verifiers? Osmani notes that generated tests need scrutiny of their own, and AWS relies partly on LLM-as-judge rubrics. None of the sources measures how often the checks themselves are wrong.

Reading list

• Agentic Verification — Addy Osmani, Elevate (Substack), Oct 14, 2026. A practical guide to the tests worth investing in when agents write code, with a starter path for property-based testing and a checklist for fast, deterministic loops. Short notes cover feature maps for driving a running app and formal models for concurrency.
• How Anthropic’s Dynamic Workflows Coordinate Claude Agents — Latent Space, Oct 12, 2026. A conference report on Claude Managed Agents flows: how the lead agent plans and writes an orchestration program, and an audience Q&A on agent counts, session budgets, subagent visibility and “dreaming” for memory consolidation. The post was later updated with the session video.
• Crossing the Threshold — Latent Space, Oct 14, 2026. Four perspectives on safe autonomy in finance: OpenAI’s “threshold of usefulness”, Two Sigma’s composable controls, Anthropic’s trust layer and Bloomberg’s incident-driven defences. It is a summary of talks, so details are brief.
• Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore — AWS Machine Learning Blog, Oct 16, 2026. The nine stages in detail, each with a production example, plus a table of metrics across tool, agent and multi-agent levels. AWS-specific in its tooling, but the stage questions (“Did I break something?”, “Is quality drifting in live?”) transfer to other stacks.
• How the Claude Code team does code review — claude.dev, Oct 15, 2026. Covered in the code review post. The review side of the same loop: risk tiers, findings verified by other agents and a cap on review rounds.

Background and prior art

• Building effective agents — Anthropic, Dec 19, 2024. Describes the evaluator-optimizer workflow, an early form of the generate-check-retry loop that Osmani’s post builds on.
• Harness Engineering — imrul-hasan.com, Dec 1, 2025. This blog’s earlier post on the harness around a model, where feedback loops like these live.
• What is property-based testing? — David R. MacIver, Hypothesis, May 14, 2016. A definition from the author of the Hypothesis library, one of the tools Osmani recommends.