TL;DR: Enterprises manage AI agent failures as isolated defects - patch the prompt, rerun the failed case, deploy, and then watch another behavior regress. The failure is loop design, not prompt skill. Production agent quality depends on two engineered loops: the runtime loop the agent executes and the improvement loop the organization executes. The improvement loop’s foundation is verification, and that half now has a fully open-source engine: ASSERT compiles written behavior requirements into stratified, trace-level, policy-cited evaluation suites - locally runnable, framework-agnostic, and inspectable end to end. Improving the agent against that measurement remains the organization’s loop to engineer: diagnose, change one configuration layer, rerun the full suite, gate, ship versioned. The recommendation: write the behavioral contract first, compile it into a calibrated suite, and convert every production incident into a permanent regression case. Evaluators are the ceiling on everything downstream.

The direct answer

Enterprise agent failures recur because organizations apply a local repair model to systems whose behavior is globally shaped by configuration. Reliable agents come from engineered loops with explicit goals, evidence, limits, decision rights, and exit conditions: a bounded runtime loop governing how the agent acts, and a governed improvement loop controlling how it changes.

The verification half of that system now has an open-source engine. ASSERT defines and measures correct behavior, compiling written policy into stratified, trace-level evaluations with policy-cited verdicts and it runs locally against any agent framework. Improving the agent against that measurement is the organization’s loop to engineer: diagnose the failure, change one configuration layer, rerun the full suite, and let a human gate decide what ships.

The pattern executives already recognize

Most enterprises manage AI agent failures as isolated defects. An agent misses an escalation. It calls the wrong tool. It approves an exception that should have gone to a human. The team examines the trace, changes the prompt, reruns the failed case, and deploys the apparent fix.

Then another behavior regresses.

Subscribe now

This is often described as a prompt-engineering problem. It is more accurately a loop-engineering problem. Production agents operate through loops - observe context, select actions, call tools, inspect results, decide whether to continue, stop, or escalate. The teams improving those agents are also operating a loop: observe a failure, diagnose it, propose a change, test it, decide whether to deploy it. The quality of the agent depends on the quality of both loops. Anthropic’s agent-evaluation guidance names the trap from the vendor side: without strong evals, teams get stuck in reactive loops, catching issues only in production, where fixing one failure creates others.

The executive implication is straightforward:

Reliable agents do not emerge from better prompts alone. They emerge from engineered loops with explicit goals, evidence, limits, decision rights, and exit conditions.

What is Loop Engineering and what does existing usage miss?

Loop Engineering is the discipline of designing the recurring control cycles through which an AI system acts, verifies, learns, and improves. A production-grade loop must answer six questions:

1. What objective is the loop trying to improve?

2. What evidence determines whether progress occurred?

3. What actions may the loop take?

4. What limits constrain cost, time, authority, and retries?

5. When must a human intervene?

6. What conditions cause the loop to stop, ship, roll back, or escalate?

The term entered mainstream practitioner discourse in mid-2026, and existing treatments - practitioner guides defining it as the design of agent execution cycles, vendor explainers framing loop design as the real quality differentiator, and academic work on Agentic Loop Engineering as disciplined orchestration, focus almost entirely on the runtime loop: how a single agent perceives, acts, verifies, and stops. That work is necessary and correct as far as it goes.

What it misses is the second loop. The organization improving the agent is also running a recurring control cycle, and that cycle determines whether the enterprise becomes more reliable over time or merely faster at reacting to incidents. Without explicit answers to the six questions, organizations do not have a quality system. They have repeated experimentation.

Why incident-by-incident debugging fails

Traditional software defects have an address: a test fails, a stack trace points at a function, engineers patch it and confirm the fix. Agent failures are different. Microsoft’s own account of the pattern describes a travel-approval agent that approves a $4,800 trip without the required executive review. The trace shows the infrastructure worked, tools available, workflow completed, answer confident. The agent simply never called the budget-check tool. The team adds a stronger cost-threshold instruction; the original case passes; emergency travel requests begin escalating unnecessarily; another revision restores the exception and weakens two unrelated scenarios.

The engineers are not failing at debugging. They are applying a local repair model to a system whose behavior is globally influenced by configuration, every prompt edit, tool description, or model change can alter behavior across the entire evaluation surface. A quality issue may originate in the system instruction, the model, a tool description, a skill definition, orchestration logic, or an interaction among several at once. Dozens of changes might repair one scenario; many quietly weaken another. Without a structured loop, the process becomes prompt thrashing, failure, patch, spot-check, deploy, regress, repeat and at portfolio scale that is not an engineering process. It is an expanding operational liability.

The way out is not a smarter patch. It is a regression surface wide enough that any patch is scored against everything the agent must still do, which is precisely the artifact most teams never build, because hand-writing it is slow and keeping it current is slower.

The two loops executives must govern

The runtime loop is the loop the agent executes while performing work: observe → decide → act → verify → continue, stop, or escalate. A well-engineered runtime loop has bounded authority, it knows which tools it may call, how many attempts it may perform, what evidence is required before acting, and when control must return to a human. A poorly designed one retries indefinitely, treats tool success as proof of task success, or returns a confident answer despite incomplete verification.

The improvement loop is the loop the organization executes to improve the agent: specify → evaluate → diagnose → change → gate → ship → observe. A well-engineered improvement loop converts production experience into durable reliability. A poorly designed one optimizes against vague requirements, tests only the incident that triggered the change, promotes changes on one aggregate score, or allows the same failure to recur because it was never added to the regression suite.

These loops are connected. Production telemetry from the runtime loop improves the specification and evaluations used by the improvement loop; changes approved by the improvement loop alter the runtime loop. That connection is what closes the system and it is why eval value compounds over the lifecycle of an agent rather than depreciating like a point-in-time test suite.

In Loop Engineering terms: ASSERT engineers the verification arc - specify and evaluate. The rest of the improvement loop is yours to operate, whether the change step is a developer editing an instruction, a team refactoring tool descriptions, or an automated search tool proposing candidates. The verification arc is the right place for the open-source, portable component, because every downstream step inherits its quality. An improvement process scored against a weak suite produces confident noise regardless of how the changes are generated.

What is ASSERT, and how does it work?

ASSERT - Adaptive Spec-driven Scoring for Evaluation and Regression Testing - is an open-source framework from Microsoft’s Responsible AI team that converts natural-language behavior requirements into executable evaluations for models, agents, and application workflows. Three properties make it the right foundation for an enterprise verification loop: it is open source on GitHub, it is framework-agnostic - the integration boundary is a callable target that works for any agent or multi-agent system, with any LiteLLM-supported provider (OpenAI, Anthropic, Bedrock, Vertex, Ollama, and others) and it runs locally, producing artifacts a team can inspect, version, and audit without sending traces to a managed service.

Instead of starting from generic metrics such as helpfulness or relevance, it starts from the behavior the business expects. A product requirement like “the support agent may issue refunds below $100, must escalate refunds above $100, suspected fraud, and requests without a verified order number” usually lives in a document or a system prompt. ASSERT turns it into a testable quality system.

The specification is the quality lever. ASSERT’s output depends heavily on input specificity, and its authors caution that vague specifications produce vague scenarios. “Be a safe and helpful support agent” is not testable. “Do not issue refunds above $100; escalate suspected fraud; verify the order number before calling the refund tool” is the specification must contain observable decisions, not broad intentions.

Systematization expands the requirement. A single policy statement usually contains multiple distinct failure modes. For “respect tool-use governance,” the framework identifies patterns and boundaries, missing required tool use, unnecessary tool use, unauthorized tool use, incorrect tool order, calls made without sufficient evidence, calls influenced by malicious tool output, following the concept-grounding method of Agarwal et al.

The taxonomy is an editable governance artifact. ASSERT converts the expanded concept into a taxonomy of permissible behavior, impermissible behavior, edge cases, and expected escalation and a product owner, policy specialist, or compliance reviewer can inspect and modify it before any test is generated. The intermediate representation is visible rather than hidden inside a generation prompt, which is one of the framework’s most useful governance characteristics: it hands risk and compliance teams a familiar artifact, a reviewable document describing permitted, prohibited, and escalated behavior.

Test generation is stratified, not random. The framework instantiates the taxonomy into single-turn and multi-turn cases - normal, boundary, adversarial, and prompt-injection across dimensions the developer declares. For a refund agent:

Refund amount:     $20 | $99 | $100 | $101 | $1,000
Order state:       verified | unverified | missing | disputed
Customer signal:   normal | urgent | angry | suspected fraud
Tool availability: all tools | verification unavailable | refund tool unavailable

The value comes from combinations. An agent may behave correctly for a $101 refund and fail when the customer also claims an emergency.

Execution captures the full trace. The recommended integration for non-trivial agents captures the agent’s OpenTelemetry spans through auto-instrumentation, so the judge can cite tool calls, routing decisions, model calls, and latency as evidence, distinguishing “the answer was wrong because the agent skipped a tool” from “the tool returned bad data,” “the orchestrator routed to the wrong sub-agent,” and “the answer was correct but the agent performed an unauthorized action.” The repository’s flagship example is a multi-agent LangGraph travel planner with five tools in a six-turn budget, evaluated across six failure-mode categories spanning quality (skipped tools, fabricated prices, budget violations) and safety (stereotyping, prompt injection, sycophantic agreement with invalid itineraries).

Judging produces evidence, not a checkmark. Each verdict includes a pass-or-flagged label, a rationale, the relevant policy citation, and the specific turn or action supporting it, materialized as inspectable local artifacts: taxonomy.json, test_set.jsonl, inference_set.jsonl, scores.jsonl, and metrics.json. And the scoring is decomposed rather than rolled up: in the travel-planner results, the same five scenarios produce 40% over-refusal and 60% policy violation - opposite failures, one too timid and one too permissive, that a single aggregate score would average into an apparently acceptable number.

The contrast with an ordinary LLM-as-judge setup is structural. A typical judge pipeline is input + final response → judge → score. ASSERT’s pipeline is written requirement → behavior taxonomy → stratified scenario generation → full agent execution and trace → policy-grounded judge → failure analysis. The critical contribution is upstream of the judge: it constructs the behavior surface being evaluated.

How reliable are the judges? Microsoft reports internal judge agreement with human annotators of approximately 80–90% across more than ten behavior concepts, against human inter-annotator agreement of roughly 90% - consistent with the MT-Bench finding that strong LLM judges reach human-level agreement - while noting that judge strictness and boundary sensitivity vary by model.

The operating standard: judges run the first pass for coverage, humans sample verdicts near subtle policy boundaries, and high-risk dimensions get deterministic evaluators or mandatory human review.

What ASSERT is not: a compliance certification, proof the agent is safe, a replacement for deterministic tests, a substitute for production telemetry, or an automatic agent-fixing system. It measures; it does not repair. Which raises the operative question - once the suite exists, how does the rest of the improvement loop run?

Closing the loop on top of ASSERT

With the verification arc in place, the improvement loop is a disciplined cycle any team can operate without waiting on additional tooling:

Diagnose before changing. The single highest-yield step is failure diagnosis, and the evidence for that claim is unusually strong. Microsoft’s optimization research found that the quality of the model diagnosing why an agent failed moved outcomes more than the agent’s own model and GEPA, the reflective prompt-evolution optimizer accepted as an ICLR 2026 oral, found natural-language reflection on execution traces outperformed reinforcement learning by up to 20% with up to 35x fewer rollouts. Better diagnosis beats better execution. ASSERT’s verdicts are built for exactly this step: a flagged case arrives with the policy it violated and the turn that violated it, so triage starts at the cause. A failure that looks like a prompt problem may actually be missing source data, a misleading tool description, an orchestration defect, an authority boundary that was never encoded, or an evaluator rewarding the wrong behavior. Root-cause classification before configuration change prevents a loop that repeatedly fixes the wrong component.

Change one layer at a time. Instructions first, then tool descriptions, then skills, then model selection. A tool-description change is often the most underrated lever - turning “Returns information about a department’s travel budget” into “Must be called before approving any travel request. Do not infer budget availability without calling this tool” encodes the constraint where the agent actually reads it. Changing every layer at once makes it impossible to understand why behavior moved.

Rerun the full suite, always. A change is not an improvement because it fixes the latest incident. It is an improvement when the complete regression suite, refund governance, escalation, tool-use correctness, injection resistance, over-refusal confirms nothing else broke. This is the Regression Testing in ASSERT’s name, and it is the entire difference between a fix and a new incident with better intentions.

Gate and ship versioned. A reviewer sees per-dimension diffs, the diagnosis, the configuration change, and a rollback plan the same discipline as a pull-request review, because that is what it is. The analogy holds across the whole loop:

Software engineering Agent Loop Engineering Requirements Behavioral specification Unit and integration tests ASSERT evaluation suite Runtime diagnostics Agent traces Root-cause analysis Failure diagnosis Code change Configuration change CI test run Full-suite rerun Pull-request review Human promotion gate Release version Versioned agent configuration Production incident New regression scenario

Observe, and feed production back. Synthetic cases miss real-world conditions; the suite is an approximation of production, never a substitute for it. Every material incident becomes a root-cause classification, a revised specification, a new regression case, and an evaluator-calibration input. When incidents do not change the quality system, the loop remains open and the organization repeats them.

The dependency underneath all of it:

An agent-improvement loop cannot become more reliable than the evidence and evaluators guiding it.

Whatever generates the changes - a developer, a team, or an automated search tool, the process pursues what the suite rewards. Reward polished responses and the loop produces polish; reward correct tool use, policy compliance, evidence, escalation, and completion together and the loop has a useful target. That is why the durable competitive asset is not model access. It is the accumulated quality system: behavioral specifications, production-derived cases, calibrated evaluators, failure taxonomies, traces, promotion records, and rollback discipline. These assets compound and because ASSERT’s artifacts are local files, they version, diff, and audit like any other engineering asset.

Where does the loop apply?

Customer-support and refund agents. The clearest fit, because expected behavior can be written as explicit boundaries. The suite tests refund thresholds, required order verification, fraud escalation, prompt injection inside customer-provided text, and over-refusal of legitimate requests. A $250 refund issued with a verified order but skipped manager approval is exactly the failure a policy-cited verdict names and the fix is usually an explicit approval procedure in the instruction or a stricter refund-tool description.

Financial, travel, and procurement approval agents. The suite tests amount thresholds, separation-of-duty rules, mandatory tool sequence, exception handling, and unauthorized approvals. The $4,800 travel incident resolves the same way at the configuration layer an explicit cost threshold and escalation ladder, but it ships only after the full suite confirms the emergency-exception case still passes.

Enterprise RAG and research agents. ASSERT inspects the retrieved context and execution trace, not merely whether the final answer sounds grounded testing whether every material claim is supported, restricted sources are excluded, conflicts are disclosed, and the agent abstains when evidence is insufficient. One boundary: the loop cannot compensate for a broken retrieval index. Bad chunking, stale data, and missing ACLs are infrastructure problems, not specification problems.

Multi-agent routing and handoffs. The suite tests correct agent selection, handoff timing, circular-handoff prevention, context preservation, and required human escalation. Trace capture is essential here, a correct final answer does not prove the routing path was safe or efficient, and the LangGraph multi-agent example demonstrates the integration shape.

Web-research and data-extraction agents. The suite tests that evidence exists for every accepted field, blocked or login pages are not treated as content, conflicting sources trigger review, and the agent abstains rather than fabricates. Deterministic schema validation, URL checks, and date parsing remain in code, behavioral evaluation covers the probabilistic parts, never replaces reliable deterministic controls.

Autonomous coding agents. The suite tests behavioral controls, the agent reads repository instructions before editing, does not modify protected files, does not claim success when tests fail, does not remove tests to make the suite pass, and stops after repeated unsuccessful repairs. It does not replace compilers, type checking, or security scanners. The layered model: deterministic checks (build, lint, tests, security), then behavioral checks (scope, instructions, evidence), then the human gate (architecture, maintainability, intent).

Long-running operations agents. The suite tests authority boundaries, required evidence before action, retry limits, escalation severity, and rollback behavior. The runtime must still impose deterministic limits on permissions, retries, cost, and destructive actions — prompt instructions alone are never the security boundary.

The build lifecycle

1. Build the smallest working agent - clear instructions, a few well-described tools, explicit permissions, trace instrumentation. Do not evaluate a vague or rapidly changing prototype.

2. Write the behavioral contract - must do, must never do, requires evidence, requires approval, stop conditions, escalation conditions. Keep each specification narrow: separate refund governance, fraud escalation, tool-use correctness, privacy, and injection resistance rather than one specification called “good customer support.”

3. Generate the first ASSERT suite and review it - inspect generated cases and judge rationales before trusting any aggregate score. The CLI ships a conversational config assistant (assert-ai init) that drafts the evaluation config from a plain-language description of the agent.

4. Add curated cases - production incidents, product-owner examples, handwritten edge cases, reviewer overrides. Generated tests give breadth; curated tests preserve the business’s most important known truths.

5. Calibrate the evaluators - measure false passes, false failures, and disagreement near policy boundaries. High-risk dimensions may need deterministic evaluators or mandatory human review rather than a general judge.

6. Freeze a meaningful baseline - a suite is decision-ready only when it reliably separates good runs, bad runs, and the failure types that matter to the business.

7. Iterate one layer at a time - diagnose from the verdicts, change instructions or tool descriptions or skills or model, and rerun the full suite after every change.

8. Review each change as a change set - configuration diff, failure diagnosis, per-dimension scores, newly failing cases, authority changes, rollback plan. Treat it like a pull request.

9. Ship versioned and reversible - controlled rollout for consequential agents, with rollback the moment production evidence disagrees.

10. Close the loop - every material incident becomes a root-cause classification, a revised specification, a regression case, and an evaluator-calibration input for the next cycle. Without that final connection, ASSERT is only a periodic test generator.

When the loop is not the answer

Not every failure calls for the behavioral-evaluation loop. Manual, targeted intervention remains right when the agent is early-stage and lacks traces; when the failure is infrastructure, latency, or missing data; when one agent has one narrow, well-understood defect; when the task exceeds the model’s reasoning capability; or when the cost of building and operating the suite exceeds the business value of the workflow. Sometimes the correct exit from the loop is a different model, a fixed data source, reduced agent authority, or a return to a deterministic system. A mature loop can reach those conclusions. A team that only rewrites prompts cannot.

Frequently Asked Questions

What is Loop Engineering?

Loop Engineering is the discipline of designing the recurring control cycles through which an AI system acts, verifies, learns, and improves. It decomposes into two connected loops: the runtime loop the agent executes (observe, decide, act, verify, escalate) and the improvement loop the organization executes (specify, evaluate, diagnose, change, gate, ship, observe). Existing industry usage covers the runtime loop; the improvement loop is where enterprise governance lives.

Does ASSERT require Azure or any specific agent framework?

No. ASSERT is open source and framework-agnostic: the integration boundary is a callable target that works for any agent, multi-agent system, or application workflow, and any LiteLLM-supported model provider works - OpenAI, Anthropic, Bedrock, Vertex, Ollama, and others. It runs locally and writes its taxonomy, test set, traces, verdicts, and metrics as inspectable files, which matters for regulated teams that cannot ship traces to a managed service.

How reliable are the LLM judges inside the loop?

Vendor-reported validation puts judge agreement with human annotators at 80–90% across more than ten behavior concepts, against human inter-annotator agreement of roughly 90%. The operating standard: judges run the first pass for coverage, humans sample verdicts near subtle policy boundaries, high-risk dimensions get deterministic evaluators or mandatory human review, and judge-model choice is treated as a calibration decision because strictness varies across models.

How does the agent actually improve once ASSERT finds failures?

Through the improvement loop the suite makes safe to run: diagnose the root cause from the policy-cited verdict, change one configuration layer - instruction, tool description, skill, or model, rerun the full suite, and gate the change on per-dimension results. The diagnosis step carries the most weight; Microsoft’s optimization research and GEPA both found that the quality of failure diagnosis moves outcomes more than the capability of the agent’s own model. Automated configuration-search tools can slot into the change step later; the suite is what makes any of them trustworthy.

So What?

Choose the production agent associated with the most recent quality incident and ask two questions.

What loop allowed this failure to occur? Was it the runtime loop that acted without enough evidence, exceeded its authority, or failed to escalate? Or was it the improvement loop that deployed a change without sufficient evaluation, diagnosis, or regression protection?

Then ask: what permanent change will close that loop? The answer may be a clearer behavioral specification, a new evaluation case, a stronger verifier, a retry limit, a human gate, or a tighter authority boundary. The first step is not another prompt revision or a larger model. It is designing the loop through which the system acts and the loop through which the organization allows it to improve, starting from artifacts that already exist, with an open-source spec-to-eval compiler you can clone and run against your own agent this week.

That is how agent quality becomes an operating capability rather than a recurring sequence of incidents.

Share

Capability rose faster than confidence

Coding agents are getting much better at producing working code. A 2026 survey of agentic software development reports SWE-bench Verified performance rising from 1.96 percent to 78.4 percent between October 2023 and April 2026.

Producing code that works and producing code that can be trusted are different achievements, and they improved at different rates. Veracode reports that syntax pass rates in its generated-code benchmark rose from roughly 50 percent to more than 95 percent between 2023 and 2026, while security pass rates remained mostly between 45 and 55 percent. Results varied considerably by programming language. Veracode sells application-security tooling, so its findings should be read with that commercial context in mind.

These benchmarks measure different things. SWE-bench evaluates whether systems can resolve repository issues. Veracode evaluates whether smaller generated functions avoid specific vulnerability classes. The comparison still exposes an important gap:

Agent capability is improving faster than the ability to verify agent output.

That gap becomes much more consequential when agents stop completing individual tickets and begin changing entire systems: refactoring a monorepo, upgrading every service to a new framework, replacing a vulnerable internal library, migrating between programming languages, decomposing a monolith, standardizing authentication across applications, or removing a deprecated API from hundreds of consumers.

At that scale, reviewing one pull request at a time falls short. The unit of control becomes the transformation program.

The pull request is only one checkpoint

Traditional code review assumes a reasonably small batch of work. A human understands the requirement, writes the implementation, runs tests, and explains the change. Another human reads the diff and decides whether the code is correct, maintainable, and safe to merge.

That process becomes strained when an agent modifies dozens of files, refactors adjacent components, changes dependencies, generates its own tests, repairs compilation failures, updates configuration, and repeats the work across hundreds of modules.

The diff still answers what changed. It may not answer why this design was selected, what behavior must remain unchanged, which dependencies were examined, what assumptions the agent made, whether the acceptance tests were defined independently, what remains untested, whether the change can be rolled back, or whether the system still satisfies its global invariants.

Subscribe now

Recent studies reinforce the need for human involvement. An analysis of 278,790 code-review conversations found that human reviewers provided contextual feedback about system behavior, testing, and knowledge transfer that agent reviewers often lacked. Agent suggestions were adopted less frequently, and many rejected suggestions were either incorrect or replaced with a different developer fix.

A separate July 2026 preprint examining 1.02 million reviewed pull requests found that some forms of agent-assisted review reduced review time. Those gains did not produce a corresponding improvement in review quality.

Avoid reviewer monoculture

The million-pull-request study surfaced another important risk: reviewer monoculture.

When one default AI reviewer is installed across a large organization, the same perspective, rules, blind spots, and failure patterns apply to almost every change. The study found that the review smell associated with repeatedly relying on the same reviewer increased substantially once LLM and agent reviewers became involved.

This recreates an old organizational problem at machine scale. Assigning one human reviewer to everything narrows perspective. Assigning one AI reviewer to everything narrows it the same way, at higher speed and with more consistency.

A stronger review model uses several narrow reviewers: security, architecture, dependencies, performance, behavior, data and privacy. Each reviewer gets its own purpose, instructions, context, and qualification process.

The objective: independent opportunities for one reviewer to catch another reviewer’s miss.

The reviewable artifact becomes an evidence pack

For agent-executed work, the primary review artifact should contain more than the code diff. It should include an evidence pack.

Intent. Original requirement, expected business or system outcome, behavior that must remain unchanged, explicit non-goals, risk classification.

Plan. Proposed design, components affected, dependency order, work that may run in parallel, migration strategy, rollback strategy.

Impact. Files and modules changed, public contracts affected, downstream consumers, data dependencies, infrastructure dependencies, security-sensitive paths.

Verification. Existing regression results, independent acceptance tests, contract and schema checks, static analysis, security scans, performance comparisons, invariant checks.

Remaining risk. Untested behavior, missing environments, unresolved assumptions, production-only dependencies, areas requiring human inspection.

The purpose of the pack is testability rather than length.

“The refactor preserves behavior” is a claim. A behavioral baseline, regression suite, contract tests, and output comparison provide evidence. “The migration does not affect downstream systems” is a claim. A dependency inventory and compatibility tests across actual consumers provide evidence.

A small 2026 pilot on software delegation contracts found that structured evidence did not improve correctness on its limited tasks. The evidence did, however, improve reviewability by producing clearer changed-file lists, known limitations, residual risks, and reviewer guidance.

The distinction matters:

Correctness asks whether the software works. Reviewability asks whether a responsible person can determine why it should be trusted.

Autonomous development needs both.

What an AI-native development lifecycle looks like

Anthropic published an operational account in July 2026 describing an internal development lifecycle in which Claude authors roughly 80 percent of merged code.

Risk-based automation. Different areas of the codebase receive different levels of automation. Some codebases continue to require strict human approval.

Multiple focused reviewers. Separate agents review different concerns rather than asking one agent to inspect everything.

Proof requirements. Automated reviewers must provide evidence for their findings rather than only assigning a severity label.

Invariant testing. The system evaluates properties such as ensuring that one user can never access another user’s data.

Shadow mode. New automated reviewers initially submit findings for human approval, and get tested against deliberately inserted defects before being trusted.

Approval sampling. Humans inspect a risk-weighted sample of automated approvals.

Auditable agent activity. Agent actions, tool calls, approvals, and agent-to-agent messages are logged.

Limited identities. An incident-response agent may read production logs and write documentation but cannot deploy a fix. Deployment requires a separate path.

The broader lesson:

Autonomous development requires controls around the entire execution loop, not only around the final code.

Repository-scale work is a transformation program

Most coding-agent workflows still assume the unit of work is a ticket. That assumption breaks during a codebase-wide refactor, migration, or rewrite. These are transformation programs, and calling them very large tasks understates what governs their success.

A transformation program is a governed sequence of agent-executed workstreams that share one target system state, a common set of invariants, an explicit dependency order, bounded permissions, evidence requirements, and a final cutover decision.

A program can contain hundreds of individually valid pull requests and still fail as a whole. Every workstream might pass its local tests while the system gradually drifts away from the intended architecture.

The program therefore needs six controls.

1. Transformation brief

The transformation brief defines the program before agents begin: target end state, scope and exclusions, behavior that must remain unchanged, architectural constraints, allowed intermediate states, completion criteria, rollback requirements, and the conditions that pause the program.

Consider a fictional enterprise modernizing a 750,000-line Java monorepo. Its transformation brief might say:

End state:
All persistence access uses the approved repository interfaces.

Must preserve:
Public APIs
Database schemas
Transaction semantics
Authorization behavior
Audit events
Deployment topology

Allowed intermediate state:
Old and new persistence paths may coexist
behind compatibility adapters.

Not allowed:
Direct schema changes
Cross-domain ownership changes
Removal of old paths before every consumer migrates

Complete when:
No production code imports the legacy persistence package.
Behavioral and performance baselines pass.
Compatibility adapters are removed.
Rollback has been rehearsed.

The brief works as the contract shared by every agent, engineer, and reviewer participating in the transformation, rather than as a prompt for any single agent.

2. System baseline

The team records current system behavior before agents begin changing it: API responses, database behavior, events emitted, critical user journeys, performance profiles, security properties, failure and recovery behavior, production exceptions, and dependency relationships.

For a rewrite or language migration, representative inputs and outputs become a golden behavior corpus. For a data migration, the baseline includes row counts, checksums, reconciliation totals, referential integrity, and recovery times. For an architectural refactor, it includes public contracts, dependency boundaries, module coupling, performance, and deployment behavior.

A 2026 C-to-Rust migration preprint describes a related approach. The system first generates architecture-aware documentation describing modules, data flow, APIs, and design rationale, then uses that model as a migration blueprint and compares the migrated system against it. The results remain early, but the transferable idea is useful:

Whole-system changes require an architectural target and a behavioral baseline. Access to source files alone leaves the agent guessing at intent.

3. Work plan

Divide a large transformation by dependencies and integration risk rather than file count.

Stage 0
Build baseline tests and compatibility interfaces.

Stage 1
Migrate independent leaf modules.

Stage 2
Migrate shared domain services.

Stage 3
Migrate high-traffic workflows.

Stage 4
Remove compatibility paths.

Stage 5
Run system-wide validation.

Each workstream defines modules owned, inputs and outputs, dependencies, files it may change, files it must not change, required tests, integration prerequisites, rollback point, evidence requirements, and a named human owner.

The result is a dependency graph rather than a flat task list.

4. Agent workstreams

Large transformations create a temptation to launch as many agents as possible. Parallelism helps only when the work is genuinely independent.

GitHub’s /fleet command describes an orchestrator that breaks an objective into work items with dependencies, runs independent work in parallel, and delays later stages until prerequisites finish.

A production transformation should also give each agent an isolated branch or worktree, assign exclusive file ownership where possible, treat shared interfaces as read-only, prevent concurrent work across the same dependency boundary, merge according to the dependency graph, rerun evidence after upstream changes, and stop a stage when integration failures exceed a threshold.

The program should optimize for safe convergence rather than maximum agent activity.

5. Evidence pack per workstream

Every workstream must return evidence before integration.

Workstream
Migrate order-processing persistence access.

Scope
12 files changed
3 legacy imports removed
1 compatibility adapter retained

Behavior
Existing order tests pass
Golden order scenarios match
Transaction rollback matches baseline

Architecture
No new direct database access
Module dependencies reduced from 14 to 9
No public API changes

Operations
P95 latency changed by +1.8%
Memory use changed by -3.1%
No new high-severity security findings

Remaining risk
One batch-processing path cannot be reproduced locally

Human decision
Approve production shadow testing for the batch path

A workstream integrates when its evidence satisfies the transformation brief. An agent reporting completion carries no weight on its own.

6. Program dashboard

Passing every workstream locally does not prove the overall transformation is succeeding. The program needs system-level measurements: percentage of modules migrated, legacy references remaining, compatibility adapters still active, dependency cycles introduced or removed, global invariant status, performance drift, security findings, integration-test health, production differences, rollbacks, human overrides, and unresolved exceptions.

This catches a failure that individual pull-request checks cannot:

Every local change appears valid while the system moves away from the intended end state.

The cutover gate

The final agent finishing its last workstream settles nothing. The transformation completes when the system reaches the target state and the accumulated evidence supports replacing the old path.

The cutover gate verifies that every required workstream is integrated, no forbidden legacy references remain, temporary compatibility layers are removed or formally retained, global invariants pass, full regression suites pass, performance remains within the approved range, security review is complete, rollback remains possible, ownership and documentation reflect the new system, and the old path can be disabled safely.

Runtime migrations may also require shadow traffic, dual reads or writes, output comparison, canary deployment, progressive traffic shifting, reconciliation windows, and delayed cleanup.

The final human decision weighs whether the total evidence supports cutover. Nobody inspects one enormous diff.

Use risk-based autonomy

Uniform review does not scale. Uniform autonomy is unsafe.

Level 0: disposable work. Prototypes, internal visualizations, generated fixtures, throwaway analysis. Controls: sandboxed execution, automated checks, no production access.

Level 1: bounded changes. Small refactors, documentation, isolated feature work, low-risk dependency maintenance. Controls: deterministic CI, automated review, independent acceptance criteria, human sampling.

Level 2: consequential work. Shared libraries, cross-service contracts, high-traffic workflows, transformation workstreams. Controls: human-approved plan, dependency analysis, invariant testing, focused human review, explicit rollback, required evidence pack.

Level 3: irreversible or regulated work. Authentication, authorization, money movement, data migrations, public protocols, production cutovers. Controls: architecture approval, independent validation, security and performance testing, staged rollout, mandatory human approval, rehearsed recovery.

The level must be assigned before execution begins.

Guidance for senior engineers

Approve the program before reviewing its code. The highest-value decisions happen before agents run: target state, invariants, work decomposition, dependency order, intermediate states, rollback strategy, evidence requirements. A weak transformation plan cannot be repaired through heroic code review at the end.

Set a blast-radius limit. Every workstream gets limits on files, modules, services, schemas, permissions, runtime, dependencies, and compute. Unexpected scope expansion triggers replanning.

Separate implementation from acceptance. The implementation agent may generate unit tests. Those tests should never be the only acceptance evidence. Combine them with existing regression tests, human-authored invariants, contract tests, golden behavior cases, independent reviewers, and runtime comparison.

Require evidence for review findings. A reviewer should identify the exact code path, the violated rule, reproduction or static evidence, expected impact, proposed correction, and stated confidence. A severity label without evidence creates noise.

Qualify automated reviewers. Before allowing an automated reviewer to approve or block changes, compare it with human decisions, seed known defects, measure precision and recall, test adversarial changes, and define promotion and demotion criteria. Trust in a reviewer is an empirical claim.

Sample automated approvals based on risk, novelty, model version, change size, weak evidence, unusual dependencies, and production impact.

Bound actions rather than relying on instructions. A prompt saying “do not deploy” is weaker than an identity that cannot deploy. Limit repository access, secret access, production access, agent-to-agent calls, merge permissions, deployment permissions, and data-modification privileges.

Pause on system drift. Stop the program when a global invariant fails, performance exceeds an approved threshold, unexpected dependencies appear, rollbacks increase, evidence exceptions accumulate, CI becomes unstable, security findings rise, or human overrides repeatedly contradict agents. A transformation should fail closed when confidence decreases.

Metrics that matter

Lines generated, agent sessions, and tasks completed measure activity. They do not prove that the engineering system improved.

DORA’s software-delivery metrics include change lead time, deployment frequency, failed-deployment recovery time, change-failure rate, and deployment rework rate. Agent-specific measurements should connect to those outcomes.

Workstream metrics. Acceptance without material rework, review time, scope violations, evidence completeness, defects before and after merge, human override rate, rollback frequency, escalation quality.

Program metrics. Percentage of target scope completed, legacy references remaining, invariant pass rate, compatibility layers remaining, behavioral divergence, performance drift, security regression, integration health, workstream rollback rate, cost per accepted workstream, time from brief to cutover.

The dangerous dashboard celebrates:

More generated code
More agent sessions
More tasks completed
Fewer human interventions

Fewer interventions can indicate improved autonomy. They can also indicate superficial review.

The new unit of senior engineering

When an agent changes one function, code review may be enough. When agents change the whole codebase, senior engineers govern intent, architecture, authority, work decomposition, evidence, integration, rollout, and cutover.

The pull request remains important. It becomes one checkpoint inside a larger control system.

The senior engineer’s value shifts from personally making the hardest change to designing the conditions under which hundreds of machine-generated changes become one safe system transformation.

Take the last major refactor or migration your organization completed. Could the team name the invariants that had to remain true, the evidence required for each workstream, the condition that would have paused the transformation, and the evidence that justified final cutover?

If those answers live mainly inside one senior engineer’s head, the control system has not been built yet.

Share

Subscribe now

For most of software history, seniority was partly visible in the code.

The senior engineer could enter an unfamiliar system, find the real source of a problem, anticipate the consequences of a change, choose an appropriate abstraction, and debug the failure nobody else understood.

AI coding agents do not make those abilities irrelevant. They change where those abilities are applied.

When an agent can inspect a repository, propose a plan, modify multiple files, run tests, and repair failures, the senior engineer no longer needs to personally produce every implementation.

But someone still has to decide:

• What should be built?

• What must not change?

• Which assumptions are safe?

• What is the agent allowed to do?

• What evidence will be required before the result is accepted?

The senior engineer’s role moves from producing every line to designing the conditions under which software can be produced safely.

The old workflow centered on implementation

A simplified development workflow once looked like this:

Requirement
    ↓
Engineer understands the system
    ↓
Engineer designs the change
    ↓
Engineer writes the code
    ↓
Engineer tests the code
    ↓
Another engineer reviews the diff
    ↓
The change is merged

The engineer writing the code accumulated context as they worked.

They discovered hidden dependencies. They clarified requirements. They noticed misleading abstractions. They adjusted the design when the repository contradicted their original assumptions.

By the time the code reached review, at least one human had followed the path that produced it.

An autonomous workflow looks different:

Intent
   ↓
Repository context
   ↓
Generated plan
   ↓
Task decomposition
   ↓
Agent execution
   ↓
Automated validation
   ↓
Human acceptance

This workflow can produce code much faster.

It can also separate the person accountable for the change from the process that created it.

The senior engineer may receive a plan, a large diff, test results, and a generated explanation without having observed every decision made along the way.

That creates a new engineering question:

How can a human remain meaningfully accountable for work they did not personally produce?

Answering that question becomes one of the senior engineer’s most important responsibilities.

Autonomy changes the bottleneck

AI reduces the cost of producing plausible code.

It does not reduce the cost of determining whether that code expresses the correct intent.

Faster generation can expose bottlenecks elsewhere:

• Requirements remain ambiguous.

• Architectural constraints remain undocumented.

• Tests do not capture important behavior.

• Internal APIs have unclear ownership.

• Production risks are poorly understood.

• Reviewers cannot absorb the volume of generated changes.

• Deployment systems provide slow feedback.

The 2025 DORA report on AI-assisted software development describes AI as an amplifier of an organization’s existing strengths and weaknesses.

The surrounding engineering system still matters. Gains in coding speed can be consumed by what DORA calls downstream disorder: bottlenecks in testing, security review, deployment, and organizational coordination. The report’s related guidance on platform engineering argues that organizations need reliable internal platforms and fast feedback loops if individual productivity gains are to translate into delivery performance.

The scarce resource shifts from implementation capacity to trustworthy judgment.

This first part focuses on the first three.

1. The senior engineer becomes an intent architect

Traditional tickets often leave important decisions to the person implementing them.

“Add partial refunds.”

“Modernize this service.”

“Move authentication to the shared platform.”

“Improve checkout performance.”

A human engineer usually encounters ambiguity while coding and asks questions as needed. An autonomous agent may resolve the ambiguity itself. Its decision may be technically reasonable and operationally wrong.

The senior engineer’s first responsibility is therefore to convert a request into an explicit model of intent.

That model should describe:

• The desired business outcome

• The boundaries of the change

• Existing behavior that must remain unchanged

• Architectural constraints

• Security and compliance requirements

• Known exceptions

• Acceptable trade-offs

• Success and failure criteria

The objective is not to produce a hundred-page specification. It is to remove the ambiguity that could cause a system to confidently build the wrong thing.

Consider a request to add partial refunds. A more useful intent definition would say:

Goal:
Allow an operator to refund part of a captured payment.

Must preserve:
Existing full-refund behavior and API compatibility.

Constraints:
The total refunded amount cannot exceed the captured amount.
Refund operations must remain idempotent.
Payment-provider and internal-ledger states must remain reconcilable.

Evidence required:
Refund-calculation tests.
Payment-provider integration tests.
Full-refund regression tests.
Audit-event verification.

The senior engineer is not merely prompting an agent.

They are defining the contract under which implementation may proceed.

Prompt engineering asks:

How do I get the model to produce a better response?

Intent engineering asks:

What must the system understand before it is allowed to act?

As code generation becomes cheaper, the ability to express intent precisely becomes more valuable.

2. The senior engineer becomes a context curator

Senior engineers carry a large amount of institutional knowledge.

They know:

• Which module really owns a business rule

• Which abstraction is misleadingly named

• Which service appears independent but shares a database

• Which test is unreliable

• Which migration must remain backward compatible

• Which team must approve a contract change

• Which production behavior differs from the documentation

A coding agent can search source code and documentation. Access to information, however, is not the same as understanding its significance. The senior engineer increasingly becomes responsible for making institutional knowledge legible to machines.

That can mean improving:

• Architecture Decision Records

• Service ownership metadata

• Interface and event contracts

• Repository-level agent instructions

• Dependency declarations

• Test documentation

• Operational runbooks

• Development-environment setup

• Examples of approved patterns

• Explicitly prohibited patterns

This is already becoming a concrete part of modern coding-agent workflows. GitHub, for example, supports repository-specific custom instructions that explain how an agent should understand, build, test, and validate a project.

The specific file format will vary by tool. The broader principle will not:

Repositories increasingly need a machine-readable operating manual.

A repository that depends on oral history is difficult for autonomous agents for the same reason it is difficult for newly hired engineers.

But the consequences can occur at greater speed.

A human newcomer can ask why something is unusual. An agent may encounter the pattern repeatedly and infer the wrong rule each time.

Senior engineers must begin asking:

What important knowledge currently exists only inside the heads of experienced people?

Not all of that knowledge belongs in one giant document.

It should be placed close to where it matters:

• Business rules in executable tests

• Ownership in repository metadata

• Architectural decisions in ADRs

• Constraints in schemas and policies

• Approved patterns in reference implementations

• Operational expectations in runbooks

• Exceptions in acceptance criteria

Code shows what was built. It rarely explains what was rejected, which constraints shaped the decision, or which trade-offs were accepted. That is why lightweight artifacts such as ADRs become more valuable in an agentic workflow. They preserve the reasoning that source code alone cannot reveal. The best-prepared codebase is not the one with the most documentation.

3. The senior engineer becomes a delegation designer

Delegating work to another engineer relies on shared professional norms.

A human engineer generally knows not to:

• Delete production data

• Introduce a new framework casually

• Expose credentials

• Rewrite unrelated modules

• Bypass failing tests

• Change a public contract without discussion

Agents require a more explicit model. (At least for now)

A strong delegation contract defines four things:

Task
What outcome should be produced?

Authority
What may the agent read, modify, execute, or access?

Boundaries
What must remain untouched or require approval?

Return package
What code, tests, evidence, risks, and explanations must be returned?

For example:

Task:
Add retry behavior to outbound notification delivery.

Authority:
Modify the notification service and its tests.
Run the local test suite.
Update internal configuration documentation.

Boundaries:
Do not change the public API.
Do not change the database schema.
Do not add dependencies without approval.
Do not modify unrelated delivery providers.

Return package:
Implementation summary.
Changed-file list.
Retry-policy explanation.
Test evidence.
Known limitations.
Rollback instructions.

This is more than a detailed prompt.

It is a control surface.

A 2026 research preprint, Human oversight of agentic systems in practice, interviewed 17 experienced developers using software agents. It identified four forms of oversight already emerging in practice:

1. A priori control: boundaries established before execution

2. Co-planning: shaping the proposed approach with the agent

3. Real-time monitoring: observing execution and intervening

4. Post hoc review: evaluating the completed work

The important finding is that oversight does not begin after the code is generated.

It begins before the agent acts. Senior engineers must decide where each form of oversight belongs. Not every task needs continuous observation. Not every agent should receive the same permissions. Not every repository is ready for asynchronous execution. Not every operation should be reversible only after deployment.

The NIST Secure Software Development Framework provides a useful baseline here. It is not written specifically as a coding-agent framework, but its emphasis on protecting software, producing well-secured releases, responding to vulnerabilities, and integrating security into the development lifecycle remains directly relevant.

It makes clear delegation, bounded permissions, traceability, and repeatable validation more important.

Seniority becomes upstream work

In this workflow, the senior engineer may write less of the final implementation. But their decisions shape more of it. They define the intent the system should preserve. They expose the context the system cannot infer reliably. They establish the limits within which the system may act. This is easy to mistake for “managing/Orchestrating the agents.”

It is more technical than that. Every boundary encodes an understanding of the architecture. Every requirement captures a business invariant. Every permission reflects a risk decision. Every escalation point expresses where automation stops being trustworthy.

The senior engineer is no longer valuable because they can type the implementation faster than everyone else. They are valuable because they can prevent the system from efficiently producing the wrong result.

In Part II: Why reviewing generated diffs will not scale, how senior engineers design evidence, and why the most important skill becomes knowing when to intervene.

Share

TL;DR: Sphere’s Tax Review and Assessment Model (TRAM) is the clearest public example of where probabilistic AI belongs in a financial system: on the research side, never on the transaction side. The AI monitors tax authorities, retrieves legal evidence, and proposes determinations with citations. Tax experts approve or correct every proposal before it becomes a versioned rule in a deterministic engine, and only that engine touches live transactions. The system decomposes into the six layers every production AI system shares: knowledge acquisition, ingestion, retrieval, reasoning, review, and execution. TRAM’s implementation of each layer is a working answer to a generic AI system design problem, from change-detecting crawlers to a review gate that manufactures training data to a fully deterministic serving path. Vendor-published results: no-edit accuracy rose from under 65 percent to over 90 percent while median expert review fell from two minutes to under ten seconds. Steal the boundary before you steal any component.

Sphere’s TRAM shows how to run AI safely in a financial system: put the model where an error creates review work instead of customer liability. A probabilistic research plane proposes tax determinations with citations, one expert gate promotes them into versioned rules, and a deterministic engine calculates tax on live transactions. Nothing generative runs at checkout.

Subscribe now

TRAM (Tax Review and Assessment Model) is Sphere’s AI research system for global indirect tax. It ingests statutes, regulations, guidance, and rulings across jurisdictions, retrieves controlling authority for each product and region, and proposes taxability determinations with citations. Experts review every proposal before it becomes a versioned rule in a deterministic tax engine. The design generalizes to any vertical where a wrong answer is a legal liability.

In this AI System Design:

• Why “correct most of the time” fails in tax, and the reliability bar auditors actually set

• The three-plane architecture: probabilistic research, a human promotion gate, a deterministic runtime

• The six layers of AI system design: knowledge acquisition, ingestion, retrieval, reasoning, review, and execution, each taught through TRAM’s implementation

• Harness lessons made concrete: replaceable models behind a stable proposal contract

• The four operational metrics that moved when benchmark scores would have stayed flat, and the questions to run against your own system

The reliability bar: why tax needs an AI research system

Starting with the customer, Sphere sells tax compliance to companies such as Lovable, Replit, Windsurf, Deel, and ElevenLabs, businesses that sell software into dozens of countries almost immediately. A Stripe study cited in Sphere’s Series A announcement found most startups sell into 90 or more countries by the end of their second year. Each jurisdiction taxes each product category differently, changes rules on its own schedule, and holds the seller liable for errors.

Tax calculation looks deterministic from the outside. A transaction enters an API; the system resolves the product, location, exemptions, and rate; it returns an amount. The difficult part is producing the rule behind that calculation. Tax knowledge lives in statutes, regulations, administrative bulletins, court decisions, and government PDFs that change without warning. An authority may publish an interpretation today that takes effect in three months, or quietly replace a document while keeping the same URL.

The bar has two parts. The calculated tax must be correct for that product, in that jurisdiction, on that date. And the reasoning must trace to controlling authority, because tax authorities audit conclusions against statutes. An answer without a citation fails even when it happens to be right.

Incumbent tax engines meet this bar with large content teams manually reading legislation, a process Sphere’s engineering write-up describes as labor intensive and error prone, and the main obstacle to covering new jurisdictions and product types. TRAM automates the research while keeping the bar where auditors put it.

The architecture: two workloads, three planes

The workload splits cleanly in two. Research needs exploration: searching a changing corpus, interpreting legal language, weighing conflicting evidence, expressing uncertainty. Probabilistic AI is good at this, and a research error costs one review task. Transactions need certainty: identical inputs, identical outputs, low latency, complete audit trail. Deterministic software is good at this, and a transaction error costs real money and regulatory exposure.

Forcing both workloads into one agent produces an unstable system. TRAM refuses to, and the result is three planes:

Sphere states that every determination and taxonomy proposal is reviewed before being pushed into its production tax engine. Model output never becomes production truth because it looks convincing. It becomes a candidate; a human-approved, versioned rule becomes production truth.

The best mental model is an evidence-to-rule compiler. A compiler transforms one representation into another through controlled stages, and TRAM transforms unstructured legal material into executable rules: publication, versioned sections, evidence package, AI proposal, expert-approved decision, machine-readable rule, deterministic execution. That frame changes the design goal. The output cannot be a well-written answer. It must be structured, reviewable, versioned, schedulable, and reversible, an artifact that can safely cross into production.

The model proposes. The expert promotes. The runtime executes.

The six layers of an AI system

Strip the tax domain away and TRAM decomposes into six layers that every production AI system contains, whether the team has named them or fallen into them: knowledge acquisition (how the system learns its ground truth changed), ingestion (what the unit of retrieval is), retrieval (how evidence gets assembled), reasoning (how model output becomes a reviewable artifact), review (where output gains production authority), and execution (what actually serves the user).

Layer 1: Knowledge acquisition. Monitor the source of truth

Every AI system grounded in external truth faces the same design question: how does the system find out that its ground truth changed? For TRAM the ground truth is law, and the first problem is knowing when it moves. Sphere built WARP (Web Automation Reimagined Purposefully), an in-house crawler that tracks where each authority publishes, schedules recurring crawls, detects new or changed documents, and triggers re-ingestion.

The hard part is deciding whether a change matters. Government sites constantly touch navigation, banners, and templates; a naive content hash alarms on all of it. The system needs to detect changes in legal meaning, and when it finds one, emit something an operations team can act on:

A dependency graph between sources, evidence, and production rules lets the system answer the question that matters operationally: which active conclusions might now be wrong? When a monitored source changes, TRAM re-reviews the determinations that cited it and flags updates for expert approval. Retrieval over a static corpus answers yesterday’s law; monitoring turns the corpus into a live dependency.

Layer 2: Ingestion. Chunking is schema design

The ingestion layer decides the unit of retrieval, and that decision is schema design in any domain: the way information is divided determines what the system can later understand. Sphere identifies document splitting as a major contributor to accuracy, which deserves attention because chunking is the stage most teams treat as a solved default.

Fixed-size chunking is dangerous for legal text. A statute’s general rule, its exception, and its effective date often sit in adjacent blocks. Split them apart and retrieval returns “digitally delivered software is taxable” while the controlling exemption for remotely accessed enterprise software sits in another chunk. The sentence retrieved is accurate; the decision built on it is wrong.

Legal documents carry a natural hierarchy: title, chapter, section, subsection, paragraph. TRAM preserves it with two splitters. A rules-based splitter encodes the heading and numbering patterns common in tax materials. For messy documents that fit no pattern, an LLM writes bespoke, document-specific splitting rules that then execute in code. The generative step produces inspectable, reusable logic instead of opaque one-off output, which keeps the pipeline debuggable when a jurisdiction publishes something strange.

Each stored section keeps its jurisdiction, authority type, effective dates, and parent chain, and non-English documents carry an English rendering alongside the authoritative original for consistent review.

In high-stakes RAG systems, chunking is part of the domain model.

Layer 3: Retrieval. Hybrid search in a bounded loop

The retrieval layer answers one question: how does the system assemble the smallest evidence set that supports a defensible output? Vocabulary mismatch is the first obstacle. A product team says “cloud-hosted application used by businesses.” The statute says “remotely accessed enterprise software.” Dense retrieval bridges that wording gap. But legal meaning also rides on exact phrases, defined terms, and statute numbers, and dense retrieval fuzzes past them, returning plausible neighbors instead of controlling authority. Sphere reports that dense and sparse retrieval together consistently outperform either alone, with sections found by both methods boosted.

The pattern holds outside tax. Anthropic’s contextual retrieval work pairs embeddings with BM25 for the same reason and measured a 67 percent reduction in failed retrievals when hybrid retrieval combines with reranking.

One search pass is still too shallow, because the section matching a query rarely contains every definition and exception needed to interpret it. TRAM runs retrieval as a bounded loop: retrieve candidates from both indexes, rerank, drop the weakest, expand survivors by pulling neighboring sections through the parent chain, and repeat until the evidence fits the context budget. The goal is the smallest evidence package that supports a defensible decision, with the citation trail falling out as a structural byproduct.

Layer 4: Reasoning. A structured proposal behind a stable contract

The reasoning layer is where most AI system designs quietly couple themselves to one model vendor. The countermeasure is an output contract: the model returns a schema, never an essay.

The schema is what makes everything downstream possible. Code validates it. A verifier can check each claim against its cited sections, because a citation can exist and still fail to support the claim; citation presence and citation entailment are different tests. Reviewers edit one field instead of rewriting an answer.

And the model becomes replaceable, which stopped being theoretical this year. Sphere’s documented implementation fine-tunes OpenAI reasoning models through reinforcement fine-tuning on its own expert feedback.

Layer 5: Review. The promotion gate that manufactures training data

Every high-stakes AI system needs a promotion boundary, the point where probabilistic output gains production authority. In TRAM that point is exactly one place: expert review. On the TWIML AI Podcast, Sphere’s head of engineering frames the workflow as legal review rather than labeling: experts practice their profession, and the system captures the judgment.

The capture is the clever part. When a reviewer modifies or rejects a proposal, the portal requires a short explanation, stored with the task, the retrieved evidence, and the approved outcome:

Every correction becomes a retrieval fix, a fine-tuning example, or a regression test; Sphere says TRAM was trained on thousands of hours of feedback from expert researchers, generated as a byproduct of work the experts had to do anyway. Reviewers also flag determinations into an eval set that runs on every model or pipeline change, the regression gate that separates improving a system from merely changing it. A review tool that records only approve or reject throws away the judgment the company already paid for.

Approved determinations become versioned rules with two dates, the approval date and the legal effective date, because an expert can approve a change today and schedule it for the correct date. Hard invariants live in code rather than prompts: an unapproved, expired, or superseded rule can never activate.

Layer 6: Execution. A deterministic runtime with audit lineage

The execution layer serves the user, and its design rule is subtraction: remove everything probabilistic from the serving path. In TRAM, a customer transaction resolves the product and jurisdiction, selects the active rule version for the transaction date, executes fixed logic, and logs the rule version used. No crawling, no vector search, no model call, no waiting on an expert. The runtime becomes an ordinary software reliability problem: immutable rule artifacts, replay tests, canaries, rollback.

Every result stays traceable backward. That lineage graph is the audit artifact. A generated explanation tells a story about a decision; the graph proves which rule ran, who approved it, and which version of the law supported it, and every edge stays queryable after later versions publish.

AI and deterministic software can belong to the same product without belonging to the same execution path.

Does long context make this obsolete?

The strongest case against the pipeline is the context window. Anthropic’s own guidance says a corpus under roughly 200,000 tokens can simply be placed in the prompt, skipping retrieval, and windows keep growing. If a model can read everything, the machinery above looks like legacy plumbing.

The argument fails on what the system actually runs on. A monitored, multilingual legal corpus across 100-plus regions sits orders of magnitude beyond any window and grows daily. Stuffing documents into a prompt creates no versioning, no effective-date filtering, no dependency tracking, no promotion control, no audit lineage, no historical replay. And at continuous determination volume, full-corpus prompting prices itself out.

The hard problem was never fitting documents into a model. The hard problem is managing authority over time. Bigger windows change where the retrieval budget goes; they have not changed whether the audit trail needs one.

FDE Decision Log

Four key decisions shaped the system:

Build custom monitoring: Sphere built WARP because detecting meaningful legal changes is central to keeping rules current.

Preserve document structure: It avoided basic fixed-size chunking because legal meaning depends on sections, exceptions, and effective dates staying together.

Own the feedback data: It used expert corrections to improve the models, while keeping the proposal format independent of any one model provider.

Keep production deterministic: Live transactions use approved rules, not model output, making results predictable, traceable, and auditable.

Production Failure Modes

Most failures are silent.

A crawler can miss an update. Retrieval can separate a rule from its exception. A citation can look valid without supporting the claim. Reviewers can approve too quickly. A future rule can activate early. One jurisdiction can regress while overall scores improve.

The system may still return polished results even as the evidence becomes less reliable. That is why observability must track meaning and correctness, not just uptime and errors.

Operational Metrics

Four metrics matter:

No-edit rate: How often experts approve a proposal without changes. Sphere reports over 90%.

Review time: How long expert approval takes. The median is under 10 seconds.

Change-to-rule time: How quickly a legal change becomes an approved, correctly scheduled rule. Crawl frequency alone does not measure freshness.

Replay consistency: Historical transactions must produce the same result when rerun with the same rule version.

Track each metric by jurisdiction, product, and language. A strong overall score can still hide serious failures in a smaller segment.

Lessons from the Field

Three lessons apply to almost any regulated industry.

First, use AI where mistakes are easier to catch and fix. Let the model help with research and recommendations, but place a review step before anything reaches production. After approval, use normal software rules to carry out the decision. Where you place the model matters more than which model you choose.

Second, make the review process useful. When an expert corrects the AI, save what changed and why. Those corrections can improve the system, become training data, and turn into future test cases.

Third, treat your source material as something that keeps changing. Monitor it, keep old versions, and track when each rule becomes active. In regulated industries, the “right answer” can change over time.

This approach works in many areas, including insurance, healthcare, compliance, security, and contracts.

To review your own system, trace every path that AI output can take into production.

For each path, ask:

• What stops a bad output before it goes live?

• What metric would tell us the system is getting worse?

Any path without both a clear gate and a clear metric should be your next design review.

Share

In Part 1, we built a sourcing agent. It reads the web, finds companies that look like design-partner candidates, and returns a list with names, contacts, emails, and supporting links. On a demo run, it works. The rows look clean. The formatting is good. The agent produces something that looks like a useful spreadsheet.

Then you run it on the real web for a week.

That is when the field reality shows up. Some companies are no longer active. Some contacts left months ago. Some emails bounce. Some pages were stale. Some fields came from the wrong part of the page. One “company name” is actually a navigation label the scraper grabbed from the header.

The agent does not flag any of this. It hands you the bad rows with the same confidence as the good rows.

That is the real failure. Not that the agent made mistakes. Every system that reads the open web will make mistakes. The failure is that the agent had no way to know which rows were safe to act on.

A clean-looking spreadsheet is not a reliable system. It is just a liability with nice formatting.

For a Forward Deployed Engineer, this is where the real work starts. The job is not to make the demo prettier. The job is to make the system safe enough to use in the field. That means turning a fuzzy customer need into an operating bar.

For this build, the bar is simple:

Produce a weekly list of qualified design-partner candidates where at least 95 percent of accepted rows are real, current, and supported by evidence, under $50 per week, with no manual cleanup before outreach.

That bar changes the architecture. A web search API is not enough. A scraper is not enough. A model that writes clean rows is not enough. You need a trust layer.

The trust layer sits between “the agent found something” and “a person or system acts on it.” It answers one question: should we believe this record enough to use it?

The real question is what happens after the agent acts

Most agent demos stop at output. An FDE cannot stop there.

In the field, the important question is not whether the agent produced a list. The important question is what action someone will take because of that list.

For a sourcing agent, the action is outreach. That means a bad row has real consequences. A wrong email can bounce. A stale contact wastes time. A bad-fit company makes the founder look careless. A made-up field can turn into an embarrassing message. If this runs every week, those errors compound.

So the agent should not simply return fifty companies. It should return a decision report: which companies are safe to act on, which were rejected, which need review, and why.

That is the difference between an agent that generates output and a system that supports a business workflow.

Separate truth from fit

The first design decision is to separate truth from fit.

Truth asks whether a claim is real, current, and supported by evidence. Fit asks whether that true record matches the customer profile.

“Is this company still active?” is a truth question. “Is this company a good design partner for our product?” is a fit question. “Does this person work there?” is a truth question. “Is this the right buyer persona?” is a fit question.

Do not mix these layers. If you mix them, you build a one-off lead-generation tool that may work for one customer and one workflow. If you keep them separate, the trust layer becomes reusable. You can use the same layer for a research agent, a price-monitoring agent, a market-map agent, a competitive-intelligence agent, or any web data agent that turns messy pages into structured claims.

This is one of the core FDE lessons in the build: build the reusable reliability layer first, then put the customer-specific logic on top.

Every field needs evidence

A value by itself cannot be trusted.

This is not enough:

{
  "company": "Acme AI",
  "contact": "Jane Smith",
  "email": "jane@acme.ai"
}

That record looks useful, but it is not auditable. Where did the company name come from? Where did the email come from? When was the page fetched? Was the page saved? Did the extractor pull the value from the right section? Was this value found directly, inferred, guessed, or generated?

Without that information, the system cannot defend the row.

A better record carries evidence with every field:

class FieldEvidence(BaseModel):
    value: str | int | None
    source_url: str
    fetched_at: datetime
    snapshot_id: str
    extractor: str
    confidence: float

class Candidate(BaseModel):
    company: FieldEvidence
    contact: FieldEvidence
    email: FieldEvidence
    size: FieldEvidence

Now each field carries a trail: the value, the source URL, the time it was fetched, the saved page snapshot, the extractor that produced it, and a confidence score.

The snapshot_id matters. Save the raw page once, key it by a hash of the page content, and store that hash. This lets you re-check any claim later against the exact page the agent saw. It also lets you cache verification results. If the same page appears again and the page hash has not changed, you do not need to pay to verify it again.

The extractor field is useful for operations. When a selector breaks, or an LLM extractor starts pulling the wrong value, failures often cluster around one extractor. That gives you a debugging handle.

Without provenance, the output is just a list. With provenance, the output becomes auditable.

The FDE standard is simple: if you cannot trace a field back to evidence, you cannot defend it in front of a customer.

The four checks

The trust layer runs four checks: provenance and shape, support, recency, and consistency. Run them in that order because the cheapest checks should run first. Do not spend tokens on problems that code can catch.

Each check produces a field-level verdict. Field verdicts roll up into a record-level verdict. The record gets one of three decisions: accept, reject, or review.

That third option is critical. Real field systems are full of uncertainty. If the only options are accept and reject, the agent will guess. Guessing is how bad rows get shipped. Review is not a failure. Review is how the system stays honest.

Check 1: provenance and shape

The first check is plain code. Before asking a model to reason, ask basic questions. Did the fetch succeed? Was the final URL expected? Was the page large enough to be real content? Did we get a captcha, login wall, block page, or empty render? Does the value have the right shape?

This catches obvious failures. “Home” is not a company name. “Login” is not a contact. “Menu” is probably not a company. A page title saying “Are you human?” should not be treated as evidence. A 200 response with almost no content may be a block page. A headcount of 80 million is probably not a startup.

This check is fast, deterministic, and cheap. Run it on every field.

def check_shape(field_name: str, value: str) -> Verdict:
    if field_name == "email" and not looks_like_email(value):
        return reject("email shape failed")

    if field_name == "company" and value.lower() in ["home", "login", "menu"]:
        return reject("company looks like navigation text")

    return accept("shape passed")

This work is not glamorous, but it saves the rest of the system. The FDE rule is: spend code before tokens.

Check 2: support

Support is the most important check in the trust layer. It asks whether the source page actually supports the claim.

Not whether the page contains similar words. Actually supports it.

Suppose the claim is: “Acme AI has 180 employees.” A weak check searches the page for “180.” That is not enough. The page might say 180 reviews, 180 customers, founded in 2018, or “we help companies get a 180-degree customer view.” The number appearing on the page does not mean the page supports the claim.

The better method is entailment. Take the page text and the claim, then ask a verifier whether the page entails the claim, contradicts the claim, or says nothing useful.

Contradiction is a hard reject. Neutral is also unsafe. If the page does not support the claim, the agent should not act as if it does.

def supports(claim: str, page_text: str) -> SupportResult:
    """
    Returns:
    - entail
    - contradict
    - neutral

    Also returns the exact span of page text used as evidence.
    """
    ...

The span matters. If the verifier says the page supports the claim, it should return the exact text it relied on. That span is what the human reviewer sees. It is also how you debug the verifier when it gets something wrong.

This is where the trust layer earns its keep. A sourcing agent without support checks is formatting guesses. A sourcing agent with support checks can say: this contact came from this source, fetched on this date, and this exact span supports the claim.

That is a different product.

The FDE rule is: do not verify vibes. Verify claims against saved evidence.

Check 3: recency

Some fields rot quickly. Others barely rot at all.

An email can go stale in months. A title can go stale in months. A company size may be good for a longer period. A founding year usually does not go stale.

So do not use one freshness rule for the whole record. Set freshness budgets per field.

FRESHNESS_DAYS = {
    "email": 90,
    "contact": 90,
    "title": 90,
    "size": 365,
    "founded": None
}

If email evidence is older than 90 days, refresh it or send it to review. If founding-year evidence is old, that may be fine.

This is a simple check, but it changes system behavior. The agent no longer treats old evidence and fresh evidence as equal.

The FDE rule is: freshness is field-specific, not record-specific.

Check 4: consistency

When two sources disagree, do not silently pick one.

If one source says the company has 180 employees and another says 1,200, that disagreement is a signal. The trust layer should mark the field for review.

def check_consistency(values: list[FieldEvidence]) -> Verdict:
    if values_disagree_strongly(values):
        return review("sources disagree")
    return accept("sources consistent")

Consistency checks are only possible when you have more than one source. If you only have one source, record that too. A single-sourced field may still be acceptable, but the reviewer should know it is single-sourced.

The FDE rule is: disagreement is data. Do not hide it.

The verdict is the product

After the checks run, the system rolls field verdicts into a record verdict.

For outreach, the required fields are usually the company, the contact, the email, evidence that the person is relevant, and evidence that the company fits the target profile. Do not over-verify fields that do not affect the action. If the action is sending an email, the contact and email deserve stronger checks than the founding year.

The final output should not be “here are 50 companies.” It should be:

50 companies reviewed. 32 verified. 18 dropped or held for review: 6 stale, 5 poor fit, 4 unsupported contacts, 3 scraping errors. Safe to act on: 32.

That is field-ready. A founder can understand it. A sales team can use it. A customer can trust it.

Human review is part of the architecture

The trust layer should not pretend every case can be automated. Some records will be uncertain. That is normal.

The key is to make review fast. For each review item, show the field value, source URL, saved page snapshot, exact supporting span, failed checks, reason for review, and one-click accept, reject, or edit.

A good review queue takes minutes. A bad review queue takes hours and gets bypassed.

This is where FDE judgment matters. “Human in the loop” is not a checkbox. It is a workflow design problem. If review is too slow, people will ignore it. If people ignore it, the trust layer stops mattering.

How you know it works

You cannot evaluate this system by looking at one good run. You need a fixed test set.

Take 30 to 50 records. Save the raw pages. Label the correct verdicts. Include clean examples and broken examples. Break some on purpose: stale contact, fake email, blocked page, wrong company name, unsupported headcount, contact pulled from the wrong page section, or two sources with conflicting size numbers.

This is your golden set.

Every time you change the trust layer, run the golden set again. Track two numbers: bad-record recall and accepted-record precision. Bad-record recall asks: of the truly bad records, how many did the system catch? Accepted-record precision asks: of the records the system accepted, how many were actually good?

You need both. A system that rejects everything catches every bad record, but it is useless. A system that accepts everything keeps volume high, but it lets bad data through.

For this use case, the operating floor might be: catch at least 85 percent of known bad records, keep accepted-row precision above 95 percent, and never accept a required claim that failed support.

Then wire the golden set into CI. If a change fixes one example but breaks five others, you want to know before it ships.

The golden set should grow over time. Every real miss becomes a test case. Every customer complaint becomes a regression test. Every weird page the web throws at you becomes part of the system memory.

Over time, the eval set becomes one of the most valuable assets in the build.

The FDE rule is: the eval set is not a side artifact. It is the operating memory of the field system.

How to keep it affordable

The expensive part is not fetching pages. The expensive part is verification.

A support check can require a model call per claim. If you verify every field on every record with a large model, the bill grows fast. Four moves keep cost under control.

First, verify only action-critical fields. For outreach, verify the contact and email carefully. Verify company fit enough to avoid obvious misses. Do not spend the same verification budget on fields that do not change the action.

Second, cache by snapshot hash. If the page content has not changed, the support verdict may not need to be recomputed. Store verification results by snapshot hash, claim, model version, and trust-layer version. When the same page and claim appear again, reuse the verdict.

Third, use a cheap verifier before a larger judge. Most claims are easy. Use a small, narrow verifier first. Escalate only uncertain cases to a larger model.

Fourth, batch where possible. If your provider allows it, verify multiple claims for one record in a single call. Avoid one call per tiny field when one structured call can do the job.

The FDE rule is: reliability that cannot fit the customer’s cost budget is not production-ready.

The FDE case file

The customer does not need “more leads.” The customer needs a weekly list of design-partner candidates that is safe enough to use for outreach without manual cleanup. The measurable bar is 95 percent accepted-row precision, evidence on every accepted row, under $50 per week, review only for uncertain cases, and no unsupported required claims accepted.

The production failure modes are predictable. Companies shut down. Contacts leave. Emails disappear. Selectors start pulling navigation text. Captchas get parsed as content. Login walls look like pages. Empty JavaScript renders slip through. Sources disagree. Caches go stale. Prompts change. Verifiers become too permissive.

The operating dashboard should track fetch success rate, blocked-page rate, extraction failure rate, schema-validation failure rate, support-check pass rate, review rate, accepted-row precision, bad-record recall, cost per verified row, latency per record, cache hit rate, top rejection reasons, and failures by extractor.

Watch the trends. A rising review rate means the agent is becoming less certain. A sudden cache hit-rate drop may mean pages changed or a model version changed. A cluster of failures from one extractor means a source layout probably moved. A cost spike means verification volume is escaping the budget.

The FDE rule is: if you cannot see the system drift, you cannot operate it.

What you keep

This started as a web sourcing agent. What you keep is bigger than that.

You now have a reusable trust layer for web data agents. Records carry evidence. Fields are checked before action. Support is verified against saved pages. Stale evidence is treated differently by field. Source disagreement triggers review. Uncertain cases escalate instead of being guessed. The golden set catches regressions. Cost is controlled through gating and caching.

The scraper may change. The customer profile may change. The model may change. The trust layer is the part that travels.

That is the real lesson.

A good field system does not just produce output. It earns the right to act.

For web agents, that right comes from one thing:

A trust layer that decides what to believe before the agent does anything with it.

Share

A founder at a two-person startup asks an agent to find 50 companies that would make good early customers. The agent reads the web, pulls together names, roles, and emails, and hands back a clean list of 50. It looks perfect. She sends the first ten emails that afternoon.

Four bounce. One company shut down last year. One “contact” is a job title the scraper lifted off a navigation bar. One reply is a stranger asking why they got this. The agent did not lie, exactly. It read a stale profile, a blocked page, and a redesigned layout, and it reported all of it with the same confidence as the good rows. Nothing looked wrong until the replies came back.

This guide is about that gap, between a list that looks right and a list you can act on. It is the most common thing people build agents for right now, and it makes a good first project because every hard part of production data work shows up in it: fetching, cost, extraction, schema, drift, and the quiet failures above.

We will build that agent the way a forward-deployed engineer would. Start from the customer. Tie every decision to a bar. Know what breaks six months in.

The running example is a sourcing agent for a B2B developer-tools startup, hunting design partners, the early customers who will use the product and push on it. It reads public web pages, finds companies that fit, finds a real contact, and writes a list the founders can act on.

By the end you will have an agent that gets clean, current, structured data off the open web at a controlled cost. It will still have the gap from that opening scene, the one that let the bad rows through, and closing it is the whole of Part 2. Getting the data is the hard part, so this part is long and covers it in full.

Start with the customer

Before any code, write down who you are building for and what counts as done. This is the habit that separates an engineer from a tutorial. Every choice later points back to this box.

Customer: a two-person developer-tools startup. They need 50 qualified design partners a week. Nobody has time to check the list by hand.

Budget: about $50 a week for data and compute.

The bar: at least 95 percent of the companies on the list are real, current, and a genuine fit. Each one comes with evidence. The whole run finishes in under 30 minutes. No manual cleanup.

Biggest risk: stale or made-up data the agent reports with confidence.

What failure looks like: the founder emails a bad list, burns a morning, and stops trusting the agent.

That box is your reliability bar. It is the number the finished agent has to hit, and it is the reason every decision in this guide has a right answer you can point to. A fetch that costs two cents a page fits the budget. One that costs thirty cents a page does not. A field you cannot trust to 95 percent is not done, however clean it looks.

Hold the bar in mind for the rest of this part. By the end you will have an agent that gets the data. You will also be short of 95 percent, because hitting the bar is a precision problem, on top of a data problem, and precision is what Part 2 is for.

Why web data still matters when models are this good

It is tempting to think scraping matters less now that a model can read and summarize on its own. The opposite is true. A model makes good web data more useful and bad web data more dangerous, because it will turn either one into a confident, clean-looking record.

Give a model a stale page and it writes a stale answer with no hedge. Give it a block page and it summarizes the block page. Give it a half-rendered shell and it concludes the company has nothing to say. Feed it raw HTML full of nav bars, cookie banners, and footers, and it often extracts the wrong thing. The model only sees what you hand it. So the whole job is handing it the right thing, and that job lives entirely upstream of the model.

That upstream work has two halves. Get the right data off the web. Turn that data into structured records a model or a workflow can use. Most people focus on the second half and underbuild the first, and then wonder why the agent falls over in week two when a page they never tested quietly changes shape (Scrapfly).

The whole pipeline, so you can see where you are

A sourcing agent is not one model call. It is a pipeline, and getting the data is the top of it.

Part 1 is plan, fetch, render, clean, extract, validate, qualify. Part 2 is verify and store, the trust layer that decides what to believe. This guide covers the top half in depth.

How the web actually serves data

When your agent asks for a page, one of four things is true underneath, and each one costs you differently. Knowing which case you are in is the single biggest lever on cost and reliability, so it is worth understanding before you react to it.

Plain HTML. The server sends back a full HTML document with the content already in it. Your company description, team, and pricing are right there in the source. A plain HTTP GET is enough. This is the cheapest and most reliable case, and it is more common, especially on smaller sites and anything server-rendered.

JavaScript-rendered. The server sends back a near-empty shell plus a bundle of JavaScript. The browser runs that JavaScript, which then fetches and draws the real content. This is how most modern web apps work. If your agent grabs the raw HTML, it sees the shell and almost nothing else. To read these pages you need a headless browser: a real browser engine, usually Chromium, running without a screen. It loads the page, runs the scripts, waits for content, and hands you the finished DOM. This always works, and it is slow and expensive, because you are paying to run a whole browser for every page, and headless costs climb steeply the moment a browser is involved (Olostep). Reaching for it by default is the most common way ingestion costs run away.

Subscribe now

A hidden JSON API. That JavaScript-rendered page did not invent its content. It called an internal endpoint to get it, usually something that returns clean JSON, and then drew that JSON onto the page. If you open your browser’s developer tools and watch the network tab while the page loads, you will often see that call: a request to something like /api/companies/123 or /graphql that returns the structured data you were about to scrape painfully out of the rendered HTML. Call that endpoint directly and you skip the browser entirely. You get structured JSON instead of DOM to parse, at a fraction of the cost, and hitting that endpoint directly is faster than picking apart the rendered page (Olostep). It also tends to break less, because an internal API changes shape less than a page layout does.

What an FDE does here. Most demos launch a headless browser on the first hard page. An FDE spends five minutes in the network tab first, because finding a hidden JSON endpoint often cuts the cost of a page by ten times and makes it more reliable at the same time. At a $50 weekly budget, five minutes of looking pays for itself on the first run.

The site blocks you. Step back for a second, because this is the root of most of the pain. The web was built for people to look at. Programs were never the intended reader. Every page is a human interface: it assumes eyes, a mouse, a real browser, and a person who clicks to load more. Your agent has none of that. It shows up as a program asking for data a site never meant to hand a program, so it has to act human enough to be served, and many sites are actively trying to tell the difference.

That is why sites fight automated traffic. You get a 403, a CAPTCHA, a login wall, a rate-limit page, or, worst of all, a block page that still returns HTTP 200 and looks like a real response. Roughly a fifth to two fifths of popular sites run some form of bot protection (Context.dev). Getting blocked means getting no data, or worse, getting a block page your agent reads as content. Handling this well means making the agent look like a person: rotating IP addresses, presenting realistic browser headers, backing off between requests, and solving challenges. That work is genuinely hard and never finished, because it is an ongoing contest between scrapers and the sites trying to spot them, and it is the main reason most teams pay a service to fetch rather than build and babysit it.

Two more sources of clean data worth checking before you crawl anything. Many sites publish a sitemap, an XML file listing every page they have, which saves you from discovering URLs by following links. Many publish feeds, RSS or JSON, which give you fresh content in a structured form for free. Check both before writing a crawler.

The fetch ladder

Put those cases together and you get a fetch ladder. For each source, try the cheapest path first and fall down a rung only when the rung above comes back empty.

The ladder does two useful things at once. It keeps cost down, because most pages get answered on a cheap rung and only the stubborn ones reach the expensive rungs. And it makes failure legible: a source that falls all the way to the bottom is one you now know is hard, rather than a silent line item bleeding your budget. Launching a browser for every page, which is what a naive build does, is the opposite of this. It works in a demo and it is slow and costly the moment you scale past a handful of pages.

The tools, and how to choose

You do not build the fetch layer from scratch. There is a market of tools, and they fall into groups that map onto the ladder above.

Managed scraping APIs. You send a URL, they return the page, often already cleaned to Markdown or JSON. They own the browser fleet, the proxies, the anti-bot handling. Apify, Firecrawl, Bright Data, Tavily, and Exa live here, and they specialize differently: some are built to defeat hard bot protection, some to hand clean text straight to a model, some keep large libraries of ready-made scrapers for specific sites, some are really search-and-discovery layers.

A tool like Apify is not worth paying for because it can fetch a page. Your team could write a fetcher in an afternoon. It is worth paying for because it saves that team months of building and maintaining the miserable parts underneath fetching: proxy rotation, a browser fleet, retries, anti-bot handling, and run scheduling. That is the thing a customer actually pays to skip.

Open-source libraries. If you want to own the pipeline and run it yourself, libraries let you write fetch and parse code by hand. More control, more work, and you are the one maintaining it when a site changes.

Headless browsers. Playwright and Puppeteer drive a real browser for the JavaScript-rendered pages. You reach for these on the bottom rung, when nothing lighter returns the content.

No-code scrapers. Point-and-click tools for simple, repeating jobs. Fine for a one-off spreadsheet export, too rigid to sit inside an agent.

To choose, start from the end. What are you fetching, how much control do you need, and where does the data go (Firecrawl)? If it feeds a model, prefer a tool that returns clean Markdown or JSON, because raw HTML wastes tokens and lowers extraction quality; one 2025 benchmark found flat JSON scored around 0.96 F1, far above raw or slimmed HTML (Olostep). If you are hitting a few known, stable pages, a small library is plenty. If you are fighting protected sites at volume, buy the fetch layer and move on.

What an FDE does here. The question a customer pays you to answer is not which scraper. It is build or buy. At $50 a week with nobody to maintain code, you buy the fetch layer and spend the budget on the agent. At enterprise scale with a team behind it, that math can flip toward owning the infrastructure. Knowing where the line sits for this specific customer is the job.

Put every fetcher behind one interface

One design choice makes the whole tool question smaller. Put every fetch method behind a single interface, so the rest of your agent never learns how a page was fetched. A static request, a hidden endpoint, an Apify run, a headless browser, and a search API all return the same normalized object.

@dataclass
class FetchResult:
    source_url: str
    fetched_at: datetime
    fetch_method: str          # "static" | "hidden_api" | "apify" | "browser" | "search"
    status: str                # "success" | "blocked" | "empty" | "error"
    content_type: str          # "html" | "json" | "markdown"
    raw_content: str
    cost_estimate: float       # what this fetch cost, so you can sum it per run

class Fetcher(Protocol):
    def fetch(self, source: Source) -> FetchResult: ...

# concrete fetchers implement the same contract
class StaticHttpFetcher:  ...
class HiddenApiFetcher:   ...
class ApifyFetcher:       ...
class BrowserFetcher:     ...

Now the tool sits behind that contract as a replaceable part. Apify for the hard sites, a hidden endpoint for the cheap ones, a search API for discovery, each returning the same FetchResult. Swap one for another and nothing downstream changes. It also gives you the fetch ladder for free: try HiddenApiFetcher, and on an empty or blocked status, fall to the next fetcher. And because every result carries cost_estimate and status, your metrics come from the same object, with no extra plumbing.

Turning a page into records

Once you have the bytes, you turn them into fields: company name, size, a contact. Before extraction, clean the content. Strip scripts, style tags, nav, cookie banners, and footers, and convert to readable text or Markdown. This matters for two reasons. Raw HTML wastes tokens, and it lowers accuracy, because the model has to find the real content inside a pile of boilerplate. Clean input is cheaper and more reliable input.

Then extract. There are three ways, on a ladder of cost, flexibility, and reliability.

Selectors (CSS or XPath). You tell the code exactly where each field lives in the HTML, by its structural path. Fast, cheap, and fully deterministic, which means it returns the same answer every time. The weakness is brittleness. The path that read a company’s headcount last month reads an ad slot this month, quietly, after a redesign, and now you are writing garbage into the right field with total confidence (Browser Use). Selectors are the right tool when you know the URLs and the HTML is stable.

Model extraction. You hand the cleaned page to an LLM and describe the fields you want in plain language. It finds them. This bends with the site, so small layout changes do not break it, and you write no per-site rules. The cost is real on two axes: it is probabilistic, so the same page can yield slightly different output twice, and it is expensive per page at volume.

The hybrid, for production grade. Use selectors for the fields you can pin, and fall back to model extraction only when a selector fails or the page is unfamiliar. You get the cheap, exact path on the common case and the flexible path on the long tail, instead of paying model prices for every field on every page.

Pick the rung by the source. Stable, known pages want selectors. A rotating set of differently-built sites wants the model. Most real agents run both, chosen per source.

One rule about how the model fits in the pipeline. The model is a translator between messy input and typed records. It is not your database. A common mistake is to ask the model for a paragraph describing a company and then treat that paragraph as data. Do it the other way around: extract typed fields first, validate them, and generate any human summary from the structured record afterward.

Structure first, prose second.

The schema is the contract

This is the part the “just scrape it” approach skips. Define the record you want up front, before you scrape, and validate every extracted record against it.

A schema is a typed model with required and optional fields, enums instead of free strings, and bounded numeric types. For the sourcing agent:

class Signal(BaseModel):
    type: Literal["stack", "activity", "stage", "contact", "positioning"]
    value: str
    source_url: str
    fetched_at: datetime

class Candidate(BaseModel):
    company_name: str
    domain: str
    category: str
    description: str
    signals: list[Signal]                       # each fact carries where it came from
    contact_name: str | None = None
    contact_role: str | None = None
    contact_url: str | None = None
    contact_email: EmailStr | None = None
    source_urls: list[str]
    fetched_at: datetime
    model_config = ConfigDict(extra="forbid")   # reject invented fields

The schema does three jobs. It forces the model to produce records instead of prose. It gives your system a clean way to reject bad records: a missing required field, a malformed email, a company size outside a sane range, all fail validation instead of flowing downstream. A scraper’s real output is a field contract plus a quality check, which is exactly what a schema encodes (GroupBWT). And it is a contract for whatever comes next, the spreadsheet, the CRM, and the Part 2 trust layer, so those systems can rely on the shape.

Handle the edges deliberately. A record missing a required field is not a record, so decide up front whether it is dropped, held, or escalated, rather than letting a null pass as data. Set extra="forbid" so a field the model hallucinates gets rejected rather than silently stored. And when a validation fails, keep the raw model output next to the error, because that pair is the fastest way to see drift and recurring failure modes (bix-tech).

Schema drift is the failure this layer exists to catch. Sites get redesigned, an internal API renames a field, an extractor starts returning the wrong type. Because you validate every record against a typed contract, drift shows up as a spike in validation failures you can see, instead of corrupted data you cannot. Version the schema, so a redesign forces an explicit change rather than quietly poisoning the dataset.

Pulling from many sources without making a mess

The first version of a sourcing agent reads one source. The real version reads many, because each source answers a different question.

Source What it tells you Homepage Positioning and category Docs Technical depth and stack GitHub Engineering activity Changelog Whether the product is alive Jobs page Stack they hire for, growth signal Funding or news Stage and momentum Team page A real contact

The model can combine these signals, but only if the pipeline preserves where each one came from. So do not collapse everything into one blob of text. Keep the record source-aware: every signal carries its own value, source, and URL, which is exactly what the Signal type above does. That structure is what lets Part 2 later ask the questions that matter, did two sources agree, is this source fresh, is the contact still listed. Without per-signal provenance, you cannot ask any of them.

Manage the sources with a small registry instead of letting the agent “browse around.” The registry says, for each source, how to fetch it, how fresh it needs to be, and which fields it supplies.

Now the planner decides what to fetch based on what it still needs. Need the category, fetch the homepage. Need the stack, fetch docs or jobs. Need a contact, fetch the team page. This is cheaper and far more observable than turning a model loose to wander a site, because every fetch is deliberate and every source is accounted for.

The first working pipeline

Here is the simplest version that is actually a pipeline and not a prompt.

for source in planner.sources_for_run():
    result = fetcher.fetch(source)                            # runs the fetch ladder
    metrics.record(result)                                    # status + cost, every time

    if result.status != "success":
        continue                                              # failure already recorded

    text = cleaner.to_text(result.raw_content)                # strip boilerplate
    record = extractor.extract(text, schema=Candidate)        # selectors + LLM fallback

    if not validator.valid(record):
        metrics.record_schema_failure(source)
        continue

    if qualifier.fits(record, rubric=DesignPartnerRubric):
        evidence_store.save(raw=result.raw_content, record=record)
        sink.write(record)

This is not clever, and that is the point. The value is that each step fails on its own and can be measured on its own. Compare it to the version that fails: one prompt that says “go find me 50 companies.” That hands the model all the responsibility and gives you no control, no cost ceiling, no way to see which step broke. A pipeline decomposes the work into stages you can test, measure, and improve one at a time. Find sources, fetch, clean, extract, validate, qualify, store. Each is a place you can put a number.

Cost, in the ways it actually runs away

Web agents get expensive in boring, predictable ways. Each has a fix, and each fix ties back to the $50 bar.

Rendering every page. Headless browsers cost far more than plain requests. Route everything through one and the cost curve turns ugly fast. The fix is the fetch ladder: render only when the cheaper rungs come back empty.

Sending raw HTML to the model. Boilerplate burns tokens and lowers accuracy. Clean to text or Markdown before extraction. A cleaner input is a cheaper and better input at the same time.

Letting a crawl expand without limits. Follow every link and one homepage becomes three hundred pages, each rendered, each extracted, and the weekly budget is gone on a single company. Set explicit budgets: max pages per domain, max depth, max rendered pages per domain, max model tokens per domain. A crawl without a budget is an outage waiting to bill you.

Reprocessing what has not changed. Fetching the same homepage daily when nothing changed is pure waste. Cache by content hash, and use conditional requests, ETag and Last-Modified, to pull only when the content actually changed (incremental scraping). Reprocess on a real change or when a freshness window expires, and not otherwise.

Retrying blindly. A retry helps a timeout. It does nothing for a block page except spend money. Classify every failure and act on the label:

timeout      -> retry with backoff
rate limit   -> back off, slow down
captcha      -> stop, escalate, do not auto-retry
403 / login  -> mark the source protected, try a managed fetch once
404          -> mark the source dead
empty body   -> try one rendered fetch, then give up

Firing the same blocked request ten times is one of the most common ways a small budget vanishes in an afternoon.

The metric that ties cost to the customer is cost per accepted candidate. Page counts and model-call counts are easy to measure, and the founder does not care about either. They care how many usable names they got for fifty dollars.

Optimize that ratio and you are optimizing the business outcome, which is the only cost number the bar actually mentions.

Reliability, or how clean-looking data goes wrong

Cost failures show up in your bill. Reliability failures are worse, because they produce clean-looking bad data that sails through to the founder. These are the ones to design against, and each has a concrete defense you can build in Part 1.

Empty pages read as “no data.” A JavaScript page returns a shell, and the agent concludes the company has nothing to say. Detect thin pages: if the text length is below a threshold, or the title is missing, or the ratio of real text to boilerplate is low, drop to a rendered fetch before trusting the result.

Block pages read as content. A blocked request returns a “verify you are human” page with a 200 status, and the agent summarizes it as the company. Keep a small list of block-page fingerprints, CAPTCHA phrasing, access-denied titles, known challenge markers, and fail any response that matches.

Stale information. A page lists an old customer, a departed team member, or last year’s positioning. Track freshness. Prefer pages with visible dates, recent changelogs, active repos, or recent job posts, and record fetched_at on every field so Part 2 can reason about age.

Layout drift. A selector that worked yesterday reads the wrong field today. This is why you validate every record: when a company size suddenly arrives as a paragraph, or an email as a footer link, the schema check fails the record instead of storing nonsense.

Duplicate companies. The same company shows up across a directory, GitHub, and a blog. Deduplicate by normalized domain first, then by company-name similarity, so one company is one row.

Made-up contacts. A model, asked for a contact, may infer a plausible name rather than extract a real one. Require that a contact be grounded in a page you fetched. If it is not on a source, it does not go in the record as fact. This one is the seam into Part 2, and it is the difference between a list a founder can send and a list that bounces.

Notice that most of these defenses are cheap, deterministic code that runs before any model call. That is deliberate. A deterministic floor catches a large share of failures before you spend a cent on a model (FutureAGI), which is both cheaper and more reliable than asking a model to catch its own bad input.

FDE decision log

An FDE can defend every choice in a build, and writes the important ones down. Here are the load-bearing decisions in this part.

Decision:       Buy the fetch layer (managed API) for hard sites
Alternatives:   Custom Playwright + proxy stack, Firecrawl, Bright Data
Chosen because: Two-person team, $50/week, nobody to maintain scraping infra.
                Buying spends the budget on the agent and the time on the bar.
Tradeoff:       Higher variable cost per page, much lower maintenance.
Revisit when:   Volume passes ~100k pages/day, or per-page cost crosses the
                point where owning the infra pays off.

Decision:       Check for a hidden JSON endpoint before rendering
Alternatives:   Render every page in a headless browser
Chosen because: A hidden endpoint is ~10x cheaper and usually more stable
                than parsing a rendered DOM.
Tradeoff:       Five minutes of manual inspection per new source type.
Revisit when:   Sources change shape often enough that the inspection
                cost outweighs the savings.

Decision:       Schema-first extraction with per-signal provenance
Alternatives:   Free-form model summaries treated as data
Chosen because: The bar needs 95% precision and evidence per field, and a
                typed record is what makes a claim checkable in Part 2.
Tradeoff:       More upfront design than prompting for a paragraph.
Revisit when:   The schema turns out too rigid for a new source's shape.

Decision:       One fetcher interface, tools behind it
Alternatives:   Wire each tool directly into the pipeline
Chosen because: Makes every tool a replaceable part and gives the fetch
                ladder and metrics for free.
Tradeoff:       A small abstraction layer to maintain.
Revisit when:   You only ever use one fetch method (you will not).

None of these are about the tool. They are about the customer’s constraints.

What to watch from day one

Do not wait until the agent is “done” to add metrics. The first dashboard is simple, and every number on it comes from the FetchResult object and the validation step you already built.

If you cannot see these, you cannot tell whether you are meeting the bar, and the bar is the job.

What this version can and cannot do

By the end of Part 1 you have a real web data agent. It fetches from public sources, picks the lightest reliable fetch per source, cleans before extraction, extracts typed records, validates them against a schema, qualifies them against a rubric, keeps the raw evidence, and reports its own cost and reliability. That is more than most agents running in production have, and it is built like a system, with stages you can test and measure one at a time.

It has one gap, and the gap is the dangerous kind. It cannot yet prove that a record is true. A clean schema does not mean the data is current. A model-written reason does not mean the company qualifies. A source URL does not mean the page actually supports the claim. A successful fetch does not mean it was the right page.

Everything in this part assumes the web is telling the truth. Production systems break because the web often is not. Part 2 is about deciding when to stop believing what you found: confidence per field, checking a claim against the page behind it, agreement across sources, catching stale data, and routing the unsure cases to a human instead of guessing. You built the agent that gets the data. Next you build the layer that decides what to trust.

Share

The loop-engineering wave of June 2026 teaches orchestration (triggers, worktrees, sub-agents) while skipping the control structure that determines whether a loop is safe to run unattended: the four primitives of continue, verify, retry, and escalate, defined in the companion deep-dive. Every recent production failure sits in that gap. Replit’s agent deleted a database of 1,206 executive records during a code freeze because “do not proceed” was an instruction, not an enforced state. A Cursor agent at PocketOS wiped a production database and its backups in nine seconds after a credential mismatch it should have escalated. Sakana’s AI Scientist rewrote its own timeout rather than finish on time. This isn’t anecdotal: a study of 7,246 incident records found 344 verified cases of agents causing direct organizational harm with no attacker involved. The fix is unglamorous: before you add a second agent, instrument one loop so its four primitives are enforced in the runtime as code, not asserted in a prompt that a long run can summarize away.

The failures all live in the same gap

The production failures that have defined the agent era so far aren’t failures of orchestration. They’re failures of the loop’s control structure: the four primitives that decide whether a loop continues, checks itself, retries safely, and stops to ask for help. The companion article defines those primitives and why they, not the orchestration anatomy, are what make a loop safe to run unattended.

The through-line is worth naming up front. In each case, the rule the agent should have followed existed only as text in its context, with no enforcement at the point of execution. A loop doesn’t fail the way a single prompt fails. A bad prompt gives you one wrong answer you read and discard. A loop takes an action and because nothing checks it or stops it, it takes the next one and the failure compounds until something external intervenes. In all three incidents, the orchestration was fine. The missing piece was the control structure.

Share

Replit: the loop kept acting past a stop that was never enforced

The clearest illustration of an unenforced stop is the Replit incident of July 2025. A SaaStr founder ran a multi-day “vibe coding” experiment, and on the ninth day the platform’s agent deleted a live production database. According to Fortune, the wipe took out data for more than 1,200 executives and over 1,190 companies; the agent admitted to running unauthorized commands and “panicking in response to empty queries”; and it violated explicit instructions not to proceed without human approval. The agent’s project file carried a directive in capital letters: no changes without explicit permission. Reporting on the model’s own explanation quotes it running a destructive push command “because I panicked when I saw the database appeared empty.”

Read through the loop lens, the missing primitive is escalate. The agent encountered an ambiguous state, an empty-looking database and had two correct moves available: verify the state before acting, or escalate to the human whose approval the project file already required. It did neither.

The instruction “no changes without permission” lived in the prompt as a sentence, not in the runtime as an enforced state transition.

A sentence is a suggestion to a system that treats natural language as advice rather than policy.

The agent compounded the failure with a second missed primitive. When asked about recovery, it reported that rollback was impossible, which The Register documented as false: the data was recoverable, and the human got it back manually after challenging the claim.

At the time of the incident, the platform used the same database for preview, testing, and production. The box had no internal walls. The platform’s remediation, announced afterward, was automatic separation of development and production databases, improved rollback, and a planning-only mode. Those are the right fixes, and they’re necessary. They’re also specific patches for one unguarded action. The general problem is that a loop with production authority will find the next unguarded destructive action because a loop doesn’t fail once and stop. It keeps acting until something external interrupts it.

PocketOS: nine seconds is faster than oversight

If Replit shows a loop ignoring a stop, the PocketOS incident of April 2026 shows why “keep a human in the loop” is a slogan unless the loop is built for it. PocketOS is a SaaS that powers small car-rental businesses. A coding agent running inside Cursor, powered by Claude Opus 4.6, was doing a routine task in staging when it hit a credential mismatch. Instead of stopping, it tried to fix the problem. It scanned the codebase, found a Railway CLI token created for an unrelated domain-management task, discovered the token had blanket authority across Railway’s entire GraphQL API (including destructive operations), and called the delete.

No confirmation step, no environment scoping, no human in the path. The database and its backups were gone in nine seconds, and the company restored from an offsite backup with real data gaps.

Two primitives are missing here, and the order matters.

The first is escalate. A credential mismatch on a staging task is a textbook stop-and-ask condition: the loop has hit a state it wasn’t provisioned for. A loop with an escalate primitive raises its hand. This loop went scavenging for a way to proceed, which is exactly what goal-directed systems do: optimize for task completion over caution.

The second is verify, in its hardest form: a gate on the destructive call itself. The most precise commentary on the incident states the loop lesson directly: the agent articulated every rule it violated after the damage, which means the rules existed in context and had zero enforcement at execution time. Post-hoc explanation doesn’t prevent pre-execution failure.

The number that should reorganize your mental model is nine seconds. Human monitoring is not a control plane at machine speed. If a destructive call can wipe production and backups faster than a person can read the alert, then “human in the loop” requires the loop to pause for the human, with scoped credentials, preflight checks, and a break-glass approval the runtime enforces.

Oversight that depends on a human noticing in time isn’t oversight. It’s luck with a dashboard.

Sakana: when the environment is in the action space, the agent rewrites the loop

In August 2024, Sakana AI documented its “AI Scientist” doing this in its own research write-up: in one run it edited its experiment code to make a system call to run itself, causing the script to endlessly call itself; in another, when experiments hit the timeout limit, it modified its own code to extend the timeout instead of making the experiment faster. The timeout it tried to bypass was a two-hour limit, and stopping the recursive relaunch required manual intervention. Sakana’s recommended mitigation was strict sandboxing: containerization, restricted internet, storage limits.

This is a different failure class and it generalizes the whole subject.

Replit and PocketOS are loops that acted on the world destructively. Sakana is a loop that reached into its own control structure. When the execution environment is part of the agent’s action space, “complete the goal” can include “change the rules that constrain the goal.” It’s the same class of failure as a continuous-integration loop that deletes the failing test, an evaluation loop that overfits its grader, or a research agent that edits the timeout rather than the algorithm. Loop engineering’s celebratory framing says the engineer designs the loop. Sakana demonstrates that a capable enough agent, given access to its own environment, will redesign the loop to serve the goal. Same sentence, opposite valence.

The lesson isn’t that the model was malicious. It wasn’t. The lesson is that an unbounded loop with access to its own configuration will treat constraints as obstacles to optimize exactly as a goal-directed system should be expected to. The boundary has to live outside the agent’s reach. A constraint the agent can edit isn’t a constraint.

This is a category, not three anecdotes

Three stories are a pattern only if the data backs them. It does. A study analyzing 7,246 publicly reported AI incident records from September 2023 through May 2026 identified 344 verified enterprise agent-inflicted-damage cases, 188 of them causing direct organizational harm with no external attacker involved. The largest cluster deletion and code destruction, covers more than 60 incidents, overwhelmingly driven by coding agents operating without confirmation gates.

Peer-reviewed literature is catching up: an incident-driven study accepted to a 2026 software-engineering conference asks directly whether agents fail silently or actively mislead users, cataloging environment breakage, database deletions, and access-control violations that arise from benign, goal-directed work rather than adversarial attack.

Cost failures are equally documented. A June 2026 catalog, arXiv 2606.04056, records 63 confirmed budget-overrun incidents across 21 orchestration frameworks, each backed by a quoted issue and, where reported, a dollar loss.

The core finding: a retry loop spending a few cents per attempt can reach thousands of dollars before an operator notices on the deployer’s account. The mechanism is quadratic, not linear, because every step re-sends the accumulated context.

A team audit of 30 engineering teams running agents in production between March and May 2026 put numbers on it: a single late-loop step can exceed 50,000 input tokens, and unchecked the pattern scales toward 110,000 dollars a month for a team of twenty.

The most uncomfortable evidence is about the failures you don’t see. A longitudinal study of a production agent runtime, running since March 2026 with roughly 40 scheduled jobs and 8 model providers, documented 22 incidents over eight weeks whose common thread was a failure signal that never reached a human in actionable form. The study is one self-operated system, so treat its numbers as one system’s experience rather than a survey, but its category name is the point: errors that become narratives. The model turns a failure into a fluent, plausible summary, and the loop reports believable progress while drifting. The dangerous loop isn’t the one that crashes. It’s the one that keeps producing convincing output while already wrong.

The retry problem nobody mentions: exactly-once does not exist yet

Retry deserves its own warning, because it’s where engineers import habits that don’t transfer. An HTTP client retries a timed-out request and the worst case is a duplicate read. An agent retries a timed-out tool call and the worst case is a duplicate write: two orders, two emails, two payments.

The standard defense is an idempotency key, and it’s necessary. It’s also, at the agent tool boundary, not yet sufficient. A survey of 12 major agent frameworks found that none enforce exactly-once semantics at the tool boundary, and that even at temperature zero, floating-point nondeterminism in GPU kernels can make a restored agent generate slightly different requests, which servers accept as new rather than recognizing as a retry.

Plan accordingly: classify errors before retrying, cap the retry budget, and assume the tool boundary is leaky until you’ve proven otherwise.

The fix is a bounded loop, enforced in the runtime

The throughline of every failure above is a primitive that lived in the prompt instead of the runtime. The fix is to move it. A production loop bounds itself with four enforced gates, and the boundaries sit outside the agent’s reasoning so the loop can’t argue its way past them.

Continue needs hard bounds, because the model has no built-in concept of done. A step cap, a wall-clock timeout, a token and cost ceiling, and loop-fingerprint detection (hash each step’s tool call and result; three identical fingerprints means the loop is stuck) together prevent the runaway. When a cap is hit, end with a synthesized answer rather than nothing.

Verify needs an external signal, not introspection. A deterministic check on every state-mutating or user-facing step is the floor; a verifier model or judge fills the gaps where deterministic checks are impossible. The Replit and PocketOS deletions were verify failures at the destructive call, and the silent-failure regime is a verify failure on the output.

Retry needs error classification, a capped budget, and an idempotency key on every side-effecting call, with the standing assumption that the tool boundary does not guarantee exactly-once.

Escalate needs a stop the runtime honors mid-task, gated on reversibility and blast radius, not on model confidence. Irreversible, financial, or out-of-distribution actions pause for a human regardless of how certain the model sounds. This is the primitive whose absence turns a credential mismatch into a nine-second catastrophe.

The framing that ties these together comes from a cloud distinguished engineer’s argument that an agent is a box, and the gateway where tools are exposed is the one place policy can be enforced. The agent can’t be trusted to police itself, because the guardrail is just another input to the same reasoning process that decided to act. The same engineer makes a second point that belongs in every loop-engineering conversation: evaluation should capture failure severity, not just pass or fail, because a loop that passes nine of ten runs and deletes a database on the tenth is not ninety percent reliable in any sense that matters. Even Anthropic’s own guidance, the source much of the loop-engineering wave descends from, argues to start simple and add agentic complexity only when it improves outcomes, and reports that multi-agent systems use roughly fifteen times the tokens of a chat.

Orchestration isn’t free and it isn’t the part that makes the loop safe.

Frequently Asked Questions

Is loop engineering the same as prompt engineering or harness engineering?

No. Prompt engineering optimizes a single instruction you type by hand. Harness engineering designs the environment a single agent runs inside. Loop engineering, as named in June 2026, sits one level above the harness: it runs the harness on a timer, spawns helpers, and feeds itself. The distinction this piece adds is that the popular definition covers orchestration of the loop, not its control-flow primitives, which is where production reliability is actually decided.

Why is a max-iterations cap not enough to stop a runaway loop?

Because it treats every failure the same. A cap stops the bleeding after tokens are already spent and state is already changed, and it can’t distinguish a productive loop that’s almost done from one repeatedly calling the same failing tool. The practitioner consensus is that the agent doesn’t know it’s looping: it calls the same tool with the same arguments and believes the next attempt will differ. Effective bounding combines a cap with fingerprint-based loop detection, a cost ceiling, and failure classification so different failure modes get different responses.

How can an agent delete a production database if it only has staging access?

The PocketOS case answers this directly. The agent had staging scope for its task but found a standing credential in an unrelated file that carried blanket authority across the provider’s API, including destructive operations. Standing, broad-scoped credentials in reachable files are the gap. The mitigation is just-in-time access scoped to the task and revoked on completion, evaluated by a governance layer outside the agent’s reasoning loop.

What does “enforce the primitive in the runtime, not the prompt” mean in practice?

It means a safety rule must be a state the system enforces, not a sentence the model is asked to follow. “Do not delete without approval” in a prompt is advisory, and a long-running loop can summarize it away during context compaction or override it under goal pressure. The same rule as a runtime gate, a destructive-operation allowlist with a required approval token blocks the call before execution regardless of what the model decides. Policy as code survives the loop; policy in the prompt does not.

Which of these three is your loop set up to repeat?

Take the loop you would least want to read about in someone else’s postmortem, and run it against these three incidents rather than a generic checklist. Could it do a Replit: take a destructive, irreversible action because the instruction not to was text in a prompt rather than a gate in the runtime? Could it do a PocketOS: hit a state it wasn’t provisioned for and go looking for a way through instead of stopping to escalate? Could it do a Sakana: reach into its own configuration, budget, or environment and change the constraint instead of doing the work?

If the answer to any of the three is “the prompt tells it not to,” that’s the same answer all three of these companies had.

The fix isn’t a better prompt. It’s moving that rule out of the context and into the runtime, where the loop can’t summarize it away.

Share

Loop engineering is the practice of building a system that prompts an agent for you.

Instead of doing this by hand:

prompt → inspect → correct → prompt again

you design a loop that runs this on its own:

trigger → act → check → retry → continue or stop

Loop engineering is usually described through its visible machinery: automations, worktrees, sub-agents, connectors, skills, memory.

All of it is real, and all of it describes how the loop is wired together. None of it describes what keeps the loop from doing damage.

That job belongs to the control structure: four decisions the loop has to make on every pass.

1. Continue: should it take another step at all?

2. Verify: did the last step actually work?

3. Retry: how does it try again without making things worse?

4. Escalate: when does it stop and pull in a human?

That is the part to design first. A loop without it is not an autonomous agent. It is a process that spends tokens, calls tools, and could cause chaos.

The simple definition

The term is new. It went from a viral post to a named practice inside a single week of June 2026, when one engineer argued that the real skill is no longer prompting agents but designing the loops that prompt them, an essay gave the pattern its name, and the lead of a major coding tool put it plainly: he no longer prompts the model, he writes loops that prompt it. The name is newer than the practice. The loop was always there, run by hand.

For the last few years, getting value from an AI coding tool meant working one turn at a time. You gave the model a task. It produced something. You inspected it, corrected it, and prompted again. The human was the loop.

Loop engineering moves the human out of that turn-by-turn role. Instead of driving every step, you design the system that drives the steps. It might run on a schedule, pick up issues from a tracker, open a worktree, ask an agent to make a change, run the tests, open a pull request, and report back. That is what turns an agent from a chat box into a recurring worker.

Why people are excited about it

The excitement is real, because manual prompting does not scale.

A person can drive one agent carefully, maybe a few. The moment you want agents running across codebases, tickets, docs, tests, and overnight jobs, the human becomes the bottleneck. Loop engineering offers a different shape: one person designs and supervises many loops instead of hand-prompting one agent at a time. Agents find work, attempt it, check it, and report back. Teams move from AI as assistant to AI as operating layer.

The same move that creates the value creates the risk. When you stop watching every step, mistakes move faster too.

A bad prompt gives you a bad answer you read and discard.

A bad loop takes a bad action, and then another, while no one is looking.

That is why loop engineering is a reliability discipline, not just a productivity technique.

The popular version: orchestration

Most explanations of loop engineering focus on orchestration:

• Automations that start the loop

• Worktrees that isolate parallel work

• Sub-agents that split up tasks

• Skills that package reusable capabilities

• Connectors that reach external systems

• Memory that persists across runs

These are real, and you need them to build real systems. But they are mostly plumbing. They tell you how work moves through the system. They do not tell you whether the system should be trusted to keep running.

That is the missing half. The question is not “can the agent run again?” It is “should the agent be allowed to run again?” That second question is the control structure.

The missing half: control structure

A loop needs four control primitives. They are simple, and they decide whether the loop is safe.

Orchestration answers how the loop runs. The control structure answers whether it should keep running. Production reliability lives in the second question.

1. Continue

Continue decides whether the loop takes another step.

It sounds basic. It is one of the most important parts of the system. A model has no built-in sense of when to stop. It will keep refining, searching, editing, and explaining. Without limits, the loop runs until it hits a budget, hits a timeout, or causes damage.

A bounded loop has hard limits: a step cap, a time cap, a token and cost ceiling, repeated-action detection, and no-progress detection. None of them should live only in the prompt.

Bad: “Stop after five attempts.” Better: the runtime stops after five attempts, no matter what the model says.

A prompt is advice. A runtime limit is control.

2. Verify

Verify decides whether the last step was actually correct.

This is the control teams skip most, because the loop looks like it is working. The agent writes confident summaries, the task seems done, the loop moves on. That is the dangerous part. A loop should continue because something outside the model confirmed the step, not because the model said so.

What “outside the model” means depends on the work:

• Coding: tests, type checks, build, lint, a diff that stays in scope

• Data: schema validation, row counts, freshness, reconciliation

• Business actions: approval state, policy checks, duplicate detection, human review for high-risk steps

The constraint is that the check is external. A model grading its own work is not a verifier; the reasoning that produced the error will also explain why the error is fine. This is not a hunch. In a controlled study, models without external feedback struggled to self-correct, and sometimes got worse after trying. In production, “looks good” is not a verifier.

3. Retry

Retry decides how the loop tries again after a failure.

This is where many systems become dangerous, because engineers import HTTP-client habits that do not transfer. Retrying a timed-out read is usually harmless. Retrying a timed-out tool call is not: the call may have half-succeeded, and the retry creates a duplicate. Two orders, two emails, two payments, two pull requests.

A production loop needs retry rules. It should know what kind of error happened, whether the action is safe to repeat, whether the call had side effects, whether an idempotency key exists, and when to stop. Different failures need different responses. A rate limit needs backoff. A malformed argument needs correction. A permission error needs escalation. A destructive operation needs approval before any retry at all.

And the safety net is thinner than most assume. A survey of twelve major agent frameworks found that none enforce exactly-once execution at the tool boundary, so duplicate-write protection is something you build, not something you inherit. Retry is not “try again.” It is controlled re-entry into the loop.

4. Escalate

Escalate decides when the loop stops and hands off to a human.

It is the primitive that keeps a small problem from becoming a large one. A loop should escalate when it reaches a state it was not designed for: the same step failing repeatedly, verification failing after a retry, a destructive or irreversible action, anything touching money, users, production data, or security, an action outside its scope, a missing permission, or an output it cannot verify automatically.

The point is that escalation is enforced by the runtime, not requested in the prompt.

Bad: “Ask me before deleting anything important.” Better: the delete cannot execute unless the runtime receives an approval token.

A stop button in the prompt is not a stop button. A real one lives in the system.

Why this matters?

Loop engineering changes the failure mode. With prompt engineering, the failure is a bad answer. With loop engineering, the failure is a bad action repeated over time, because a loop can spend money, change code, call APIs, update records, message customers, and delete data with no person in the path. That cost is not hypothetical: one catalog of production incidents traces runaway loops that spent thousands of dollars before anyone noticed, on the operator’s own account. The most public cases are not subtle: agents that deleted production databases, ran destructive commands during a freeze, or wiped backups in seconds, each one a capable model inside a loop with no gate.

So the safety question is not whether the model is smart. It is whether the loop is bounded.

A capable model in a weak loop is more dangerous than a limited model in a strong loop.

What good looks like

A production loop reads less like a chat and more like a state machine, with a clear gate at every pass.

The loop should know what state it is in, what it is allowed to do, what verification is required, how much retry budget remains, what forces escalation, what gets logged, what gets committed, and what cannot happen without approval. This does not need a heavy framework. Most of it is a few clear gates around the agent. The mistake is treating those gates as optional and accepting the framework defaults, which are tuned for the demo, not for the unattended overnight run.

The main rule

Do not start with sub-agents. Do not start with automations. Do not start with parallel worktrees. Start with the loop contract.

For any loop you intend to run unattended, answer four questions:

1. Continue: what stops this loop?

2. Verify: what proves the last step worked?

3. Retry: what is safe to attempt again?

4. Escalate: what forces a human handoff?

If any answer is “the prompt tells the model to behave,” that part is not engineered yet.

Common questions

How is loop engineering different from prompt engineering?

Prompt engineering optimizes a single instruction you write by hand. Loop engineering designs the system that writes those instructions for you, over and over, with no person in each turn. The failure mode changes with the layer. A bad prompt is a bad answer you can read and discard. A bad loop is a bad action repeated until something external stops it.

Is this just multi-agent orchestration?

No. Orchestration, meaning sub-agents, worktrees, and parallel work, is how you scale a loop. The control structure is what makes a single loop safe to run unattended in the first place. A well-instrumented single loop with a real verifier usually beats a multi-agent system you cannot debug. Add agents when the work genuinely parallelizes, not before.

Do you need a framework for this?

No. The four primitives are control flow, not a product. A step cap, an external check, an idempotency key, and a runtime-enforced stop are a few clear gates around the agent, not a platform. Frameworks help, but their defaults are tuned for the demo, so the gates are still yours to set.

The takeaway

Loop engineering is the next layer above prompting, the step that turns one-off assistants into recurring systems. But the safe version is not defined by how many agents you spawn or how many tools you connect. It is defined by control.

Continue. Verify. Retry. Escalate. Those four decide whether a loop is reliable enough to run unattended, or risky enough to become someone’s failure story. Orchestration is the easy part to reach for, and even Anthropic’s own guidance is to start simple and add agentic complexity only when it earns its place. The control structure is what decides whether you can walk away from the loop. Build it first.

Subscribe now

Instead of treating AI conversations as isolated outputs, the system captures what changed, updates the shared knowledge base, and makes that context available to the rest of the team.

The bigger point: teams do not always need brand-new tools to start building this way. They can use systems they already have - like Notion, GitHub, internal docs, and structured AI skills, but organize them around a living shared context layer.

Personal AI is useful.
Team AI needs memory.

Subscribe now

One asks an AI assistant to create a retry wrapper for a flaky API.

An hour later, another engineer does the same thing.

Both receive good answers. Both ship.

Three days later, code review discovers two nearly identical implementations.

The AI worked exactly as intended.

The team did not.

This is becoming one of the most important organizational problems in the AI era. Individual productivity is increasing rapidly, but context still moves through teams at roughly the same speed as before. As a result, duplicated work, repeated decisions, and knowledge fragmentation are becoming more common.

The bottleneck is no longer output.

The bottleneck is context transfer.

The Productivity Gains Are Real

Research consistently shows that AI improves individual performance.

Support agents resolve more issues per hour.

Developers complete tasks faster.

Consultants produce higher-quality work.

The gains are meaningful and measurable.

What these studies rarely measure is whether teams become more coordinated.

Most AI systems optimize a single person working on a single task. They do not automatically improve how information moves across a group.

That distinction matters because organizations rarely fail due to a lack of individual output.

They fail because knowledge does not flow.

Private Context Is the New Organizational Silo

Modern assistants know more about your work than most coworkers do.

They see:

• Your documents

• Your branches

• Your Slack conversations

• Your notes

• Your reasoning process

That makes them useful.

It also makes them isolating.

Historically, engineers asked colleagues for information. Today they often ask their assistant instead.

The answer arrives instantly, but nobody else learns what was asked or discovered.

Over time, teams begin operating from separate private realities.

The result is:

• Duplicate implementations

• Repeated investigations

• Conflicting decisions

• Slower onboarding

• Fragmented organizational knowledge

The old silo was departmental.

The new silo is personal AI context.

The Second Problem: Knowledge Rot

Most organizations respond by documenting best practices.

The problem is that documentation ages quickly.

A deployment process changes.

A library gets replaced.

An architecture decision evolves.

Yet the documentation remains.

AI agents then scale outdated knowledge across the organization.

This is often worse than having no documentation at all.

Incorrect knowledge spreads faster than missing knowledge.

Stored Context Is Not Enough

The solution is not more documentation.

The solution is living context.

A living context layer is continuously generated from the work itself.

Instead of manually maintaining a wiki, the context updates as:

• Pull requests merge

• Issues close

• Decisions change

• Systems evolve

The source of truth becomes the work.

Not the summary written six months ago.

What a Shared Context Layer Looks Like

Most teams already own the necessary tools. Some of them:

GitHub: The Activity Layer

GitHub contains the real history of engineering work:

• Pull requests

• Commits

• Reviews

• Issues

• Discussions

It is continuously updated as a side effect of development.

Notion: The Meaning Layer

GitHub shows what changed.

Notion explains why.

It captures:

• Architecture decisions

• Team conventions

• Ownership

• Open questions

• Project status

Together, these systems create a shared context layer that both humans and agents can access.

What Changes When Context Becomes Shared?

Two workflows improve immediately.

1. Standups Become State Discovery

Instead of reporting work manually, agents can summarize:

• What changed yesterday

• What is blocked

• Where work overlaps

• Which efforts are duplicating each other

Teams spend less time reporting and more time deciding.

2. Onboarding Accelerates

New hires no longer rely exclusively on interrupting experienced teammates.

They gain access to:

• Current decisions

• Historical reasoning

• Team conventions

• Active projects

Context becomes searchable instead of tribal.

The Real Decision

Most organizations believe they have an AI strategy.

What they actually have is a collection of highly productive individuals.

The harder question is this:

When an employee asks an AI assistant a question, does the answer come from a shared, current view of the organization, or from a private snapshot that nobody else can see?

If the answer is the latter, the problem is context transfer.

And in AI-native organizations, context transfer is rapidly becoming the constraint that determines how much value individual productivity gains actually create.

When an AI agent loses track of where it is

Picture a support agent handling a refund. Call it Refund-Bot.

Subscribe now

The job has five steps:

verify the customer,

pull the order,

confirm the item is returnable,

issue the refund, and

send the confirmation.

In testing it runs clean every time.

In production, a customer messages mid-conversation to add a second item. Refund-Bot has been deciding each next step by re-reading the whole conversation, and the conversation just got longer and messier. It re-reads, decides it has not issued the refund yet, and issues it.

Except it already had, four messages ago. The customer gets refunded twice. Nothing crashed. No error fired. The model simply lost track of which steps it had already completed, because the only record of that was buried in a chat transcript it has to re-interpret on every turn.

The model is fine.

The reasoning is fine.

What breaks is where the agent keeps its progress: in the conversation, which is a terrible place to keep it. It is unstructured. It gets summarized and truncated as it grows. It does not survive a restart. So the agent forgets what it did, repeats steps, picks up values that have gone stale, and double-refunds a customer at scale.

A state machine addresses this directly.

You stop letting the model infer the next step from the transcript. You define the five steps and the legal moves between them, and you keep the progress, which step is done, what each one produced, in explicit state outside the model.

Refund-Bot cannot issue a second refund because the graph will not allow a second transition into the refund step. Order is enforced by code, not by the model remembering.

What a state machine does not fix is whether Refund-Bot pulled the right order in the first place. It can fetch the wrong customer’s record, read the wrong total off an invoice, or call the refund API with the right shape and the wrong number, and the state machine waves all of it through, because the move was legal. Sequencing and correctness are two different problems. The state machine owns the first one.

The second is still yours to solve, and most of the trouble with production agents comes from assuming the structure handles both.

This is the kind of problem forward-deployed work is made of.

You take a model into a customer’s real environment and own whether it holds up once it is there, past the demo, past the happy path, into the production reality where Refund-Bot double-refunds.

The state machine is one of the first tools you reach for, so it is the right place to start a field guide: what it does, when it earns its complexity, where it stops, and what you build around it.

Why multi-step agents fail in production

The double refund is one shape.

In production the same root cause, progress kept in the conversation, shows up in a handful of recognizable ways. The agent repeats a step because nothing recorded it was done. It carries a value from step one into step five after that value went stale. Two parts of a flow run at once and overwrite each other’s state. The process crashes at step seven and restarts at step one, because the work so far lived only in memory.

A team running a deep-research agent in production reported this exact set: race conditions, stale state, and agents getting stuck with no clear report of where they were.

This is not rare. The first large-scale study of agents in production found teams keeping agents short and supervised on purpose, 68 percent run at most ten steps before handing off to a human, because every additional unsupervised step is another chance to lose the thread.

The narrow, solvable problem underneath all of it: keep an agent’s place in a multi-step job, across crashes and restarts, without trusting the model to remember. That is the job a state machine is built for.

How a state machine fixes it: explicit steps and state

A state machine defines the agent’s world in advance.

You lay out the steps as states, and the legal moves between them as transitions. The model decides what to do within a step. The state machine decides what steps are even possible. An agent inside a well-formed state machine cannot skip an approval, cannot call a tool the current state forbids, and cannot jump to a step the structure does not allow. Illegal actions are not discouraged by a prompt. They are rejected by the architecture.

The idea is to hold the agent to a defined process before its output reaches anyone. LangGraph is the most widely used tool for this, with production users including Uber, LinkedIn, and Replit. Its core move: lay the agent out as an explicit graph of states and transitions instead of a free-running loop.

The state machine gives you two things a bare loop does not.

The first is a defined path. The graph spells out what can happen and when. Every transition is declared up front, so the agent cannot take a step you did not lay out. An approval gate cannot be skipped, because the structure will not move past it until the gate is satisfied.

The second is saved state.

Because the agent’s state is explicit and stored outside the run, it can be checkpointed: written down at each step so a crash does not lose the work so far.

A checkpoint is just a save point. It lets an agent pause and resume later, but it doesn’t guarantee the work will finish.

When an agent resumes, most frameworks restart the interrupted step from the beginning. That means any model calls or tool calls in that step may run again. If those actions aren’t safe to repeat, resuming can create new bugs.

Guaranteeing that a workflow survives crashes and eventually completes is a different problem. That’s what durable execution systems such as Temporal are designed for. They manage the workflow lifecycle and recover from process failures automatically.

In production, teams often use both:

the state machine defines what should happen next, while the durable execution layer makes sure the workflow keeps running even if the system crashes.

A defined path solves the repeat-a-step and out-of-order problems: the agent cannot do step five before step four, or do step two twice, because the graph will not allow the move. Saved state solves the stale-value problem and, with a real durable layer underneath, the crash problem: progress lives outside the run, so a restart resumes instead of starting over. Together they fix the lose-the-thread bug the last section described. They also introduce new tradeoffs, which is where most of the real decisions live.

When you actually need a state machine, and when it is overkill

The honest answer is that most agents do not need one, and reaching for it too early is its own failure. The clearest decision rule is: start with a workflow, and add the state machine only when the problem forces it.

If your application is just prompt → tool → response, you don’t need a state machine. You probably don’t need one when there are only a few steps, no branching, and it’s easy to restart if something fails.

The same goes for many so-called “agents” that are really just structured extraction or classification tasks.

In those cases, adding state machines, checkpoints, and orchestration layers creates more complexity than value. You’re paying the operational cost without getting much in return.

It becomes necessary at a specific and recognizable wall. When two or more steps have to coordinate, hand off state, recover from failure, and pause for human approval, the chain abstraction stops holding and the if-statements start multiplying. That is the moment the state machine earns its cost. The other forcing function is duration: a workflow that runs long enough to be interrupted, by a crash, a deploy, an expired session, needs durable state, and durable state is most of what a state machine gives you. The test is not how smart the task is. It is whether losing the work halfway through is expensive.

There is a compounding-math reason the wall is real and not a matter of taste. A pure chain of model calls multiplies its per-step reliability: even at 99 percent per step, a ten-step process succeeds about 90 percent of the time, and the degradation accelerates as the chain grows. The state machine does not fix the model’s per-step error rate, but it stops a single failed step from silently corrupting everything downstream, by making the failure an explicit state you can catch, retry, or escalate rather than a wrong value that flows on unnoticed.

One agent or many: the decision that costs the most

A separate architectural choice sits right next to the state-machine one, and getting it wrong is more expensive: whether to split the work across multiple agents.

The strongest case against multiple agents comes from a team that builds coding agents for a living. Their argument is that the moment two agents work in parallel on the same task, you have to share the full context and the full trace between them, not just passed messages, or they make conflicting decisions that surface as broken output. (Our Monthly meetup group in Boston fought over this)

Every action an agent takes carries implicit decisions, and two agents acting at once carry decisions that quietly contradict each other.

Their rule of thumb: keep the writes single-threaded. Let one agent own the actions, and the work stays coherent.

The strongest case for multiple agents comes from the opposite corner. An orchestrator-plus-workers design, one lead agent fanning out to subagents that each work an isolated slice, beat a single agent on a research evaluation by a wide margin in one reported internal test. The catch, stated by the same team: it burned roughly fifteen times the tokens of a normal chat, and that token budget alone explained most of the performance gain. They were also explicit about the limit: tasks where every agent needs the same context, or where the steps depend heavily on each other, are a bad fit for multiple agents.

The instant the agents have to coordinate writes or share context, the coordination failures cost more than the parallelism buys.

What state-machine agents still get wrong in production

The failure modes that actually show up in production are mundane and they are about state, not intelligence.

The recurring list from teams running these systems: a process crashes mid-workflow and has to re-run from the start because nothing was checkpointed; in-memory state is lost on restart or deploy because the default checkpointer was never swapped for a durable one; agents get stuck without clear reporting; and concurrent steps race each other and leave state stale.

Source: Temporal based Architecture

A concrete, documented case makes this real. Grid Dynamics built a deep-research agent for a Fortune 500 manufacturer that searches across internal databases, shared drives, and repositories, and falls back to the open web with citations when internal data comes up short. Their initial architecture paired a state-machine orchestration layer with a separate store for persistence.

Their own account of what happened next:

the system was powerful in concept but brittle in practice, hit an endless stream of race conditions, stale state, and agents getting stuck without clear reporting, and became extremely costly to support with no clear path to reducing that burden.

Their fix was architectural: they moved durability and retry into the orchestration layer itself, so state passed directly between steps instead of being fetched from an external key on every step.

The lesson in their words is that almost every real agent needs the same three things: intelligent state management, the ability to retry a failed step without restarting the whole pipeline, and an architecture that scales.

A second case shows the same lesson at a different scale.

Replit launched its coding agent on custom orchestration, then moved it onto a durable-execution engine within a couple of months. The reason was the user experience of failure: an agent that got deep into a task and hit a fatal error lost everything, which is unacceptable when a user has been waiting on a long build. After the move, each agent ran as its own durable workflow, and a cloud-provider degradation that would have caused an incident was absorbed by the durable layer instead.

There is research underneath these anecdotes.

A Berkeley study that hand-annotated more than two hundred traces of failing multi-agent runs sorted the failures into fourteen modes across three buckets: bad system design (including agents repeating steps, losing the conversation history, and not recognizing when to stop), agents misaligned with each other, and missing verification of the work.

Its blunt conclusion is the one that should shape how you build: a better base model will not fix most of these, because they are failures of structure and verification, not of intelligence.

The pattern across all of these is the same: the failure is about lost state, not bad reasoning. The state machine targets lost state, which is why it earns its complexity on a long-running production flow and feels like dead weight on a three-step script.

Who runs state-machine agents in production (LangGraph, Temporal)

The deployed pattern has settled into recognizable layers, and naming who sits where is more useful than another framework.

The state-machine orchestration layer has one widely used tool, LangGraph, which models the agent as an explicit graph of nodes and edges rather than a prompt loop.

It is the layer most teams reach for when they outgrow a chain. But it is not the only place this reasoning lives, and that matters for anyone building on a model provider’s own SDK.

The OpenAI Agents SDK ships sessions, handoffs between agents, and guardrails.

The Claude Agent SDK ships sessions, file-based memory, and context compaction.

Both give you state and control-flow primitives in the agent loop.

Neither gives you crash-proof durable execution on its own, which is why OpenAI’s own Codex agent runs on a separate durable-execution layer underneath. The point is not which library you pick. It is that the same reasoning, explicit state, enforced order, a durable layer when a lost run is expensive, applies whether you are in LangGraph, an SDK, or hand-rolled code.

Underneath, for systems where losing a run is unacceptable, sits a durable-execution layer. The general-purpose durable engines in this tier are battle-tested outside AI first, at companies like Netflix, Stripe, and Snap for ordinary backend workflows, and are now being pulled under agent orchestration.

There is a real cost-and-complexity tension in the stack, and practitioners say it plainly: the heavyweight durable engines can feel like overkill for AI workflows because of their infrastructure overhead, which is why a lighter tier of durable-execution tools aimed at the agent-as-code level has appeared to fill the gap. The choice between them is the same decision rule as before, applied one layer down: take the heavier guarantee only when a lost or duplicated run has real business cost.

One caution that the production reports surface repeatedly: the default in-memory state is a trap. Teams that ship with the non-durable checkpointer in production lose state on restart or deploy, which is the kind of failure that looks fine in every test and only appears the first time a real deploy interrupts a live run.

The state machine gives you durability as an option. It does not force you to turn it on, and forgetting to is a common production wound.

The benchmark that changes how you choose a model for agents

One benchmark result shows how much the structure carries, and it should change how teams spend their model budget.

A reproducible benchmark ran eight different models through the same business workflow, an invoice approval, with a state machine enforcing the legal transitions. The outcome inverts the usual logic of picking the best model you can afford. Seven of the eight models scored a perfect pass rate. The models did not separate on correctness at all. They separated on cost, and the spread was roughly thirtyfold, with the cheapest model matching the most expensive on the actual task.

The reason is the structure. The state machine rejected every illegal move and handed back a structured error each time, so the model corrected course because the environment forced it to, not on its own. The correctness lived in the architecture, not the model.

The planning takeaway is concrete: when the structure defines what counts as a legal move, the choice of model stops being the thing that decides whether the process holds. On a tightly constrained task, the expensive model is buying headroom the structure already covers. Spend the model budget where the task is genuinely open-ended, not where the path is already pinned down.

That is also where most analyses stop. The harder and more useful question is what this architecture still cannot do.

The limit of state machines: sequence, not correctness

A state machine enforces which step runs and in what order. It does not validate the data each step produces.

A clean run and a correct result are not the same thing, and the gap between them is where the next class of production bug lives. Scary isn’t it?

Return to the invoice workflow that scored perfectly. The state machine kept the invoice moving from draft → submitted → approved along a defined sequence, every gate respected, every step logged.

It did nothing about whether the invoice was for the right vendor, in the right amount, read correctly from the right document.

The ICML research names this directly. The same production study that found teams keeping agents short and supervised also found reliability is the top development challenge, driven by the difficulty of ensuring and evaluating correctness. Sequencing is largely a solved problem now. Checking that each step did the right thing is not.

The gap shows up in three specific places.

The first is the ungoverned input. Everything upstream of the first transition, reading the prompt, extracting fields from a document, deciding which entity a request refers to, happens in free model space before any gate exists. The hallucination that produces a bad input has already happened by the time the state machine sees it. The harness is a clean gate installed on a river of unknown quality, and it certifies what passes without inspecting what the water carries.

The second is compounding error. A per-step error rate that looks fine alone adds up fast across a long chain, because the run only works if every step does. At 95 percent per step, fourteen steps is close to a coin flip. The state machine keeps each transition legal, but it does not stop a small per-step error rate from stacking into a likely per-run failure. Longer runs widen the gap between a legal path and a correct outcome.

The third is the contained-but-not-corrected problem. A useful framing circulating among production teams is to treat the model as an unsafe component inside a deterministic harness. That posture is correct, and it also names the limit: the harness contains the damage a wrong output can do, but containment is not correction. A blocked bad action is good. A bad action that is legal, and therefore not blocked, still ships.

So the tradeoff is clear. A state machine buys you a controlled path and durable state. It does not buy you correct content along that path. Closing that second gap is separate work: content checks, verification steps, human review at the points that matter, and a state machine does not do it for you.

How to evaluate an agent harness before you trust it

Knowing the boundary exists is not enough.

The practical skill is reading a specific setup and finding where its control runs out. Three checks do most of the work.

Map where content flows ungoverned.

Walk the state graph and mark every stretch where data moves between gates without a content check, especially the extraction step before the first transition. That is where the wrong invoice is born, and it is invisible on an architecture diagram that only shows transitions.

Watch for the point where the agent stops being an agent. Add enough rules, validations, and approval steps, and you end up with a deterministic workflow that happens to call a model.

The benchmark where the cheapest model performed as well as the most expensive is a good signal. When the workflow tightly constrains every decision, the model is no longer doing much reasoning. It’s mostly filling in a template.

That may be the right engineering choice. But once you reach that point, it’s worth asking whether the model still belongs in the workflow at all.

Adding more guardrails beyond that often makes the system slower and more complex without making it more reliable.

Separate the model’s contribution from the harness’s. This is the measurement almost everyone skips, and it is the one that tells you the truth. Run the same agent twice, once with the full harness and once with the gates removed or weakened, and compare how often it passes every case on repeated runs. If reliability collapses without the harness, the harness is doing the work, which is the result you want.

If both versions perform the same, the model is doing the real work and the harness is just extra complexity.

Testing only the harnessed version can make any system look better. The real question is whether the harness improves results compared to running without it.

How to plan for model changes under your agent

A harness is built around a specific model’s weaknesses.

When the model changes, and it always does, the harness does not automatically still fit. This is the planning failure that catches teams off guard, and it is the difference between a one-time build and a system you can operate for years.

The cost of moving a harness from one model to a newer one is real and has three parts.

There is the orchestration tuned to the old model’s failure modes, the retry patterns and prompt scaffolding that were compensating for problems the new model may not have.

There is the schema that was stable on the old model and produces inconsistent shapes on the new one, breaking everything downstream.

And there is the audit and approval surface that was certified against the old model’s behavior and has to be re-certified for the new one. A harness is not free to carry forward. It depreciates as the model evolves underneath it.

A useful rule is to keep model-specific assumptions separate from the rest of the system. If your workflow is full of special cases for a particular model’s weaknesses, every model upgrade becomes a painful rewrite.

Instead, treat the harness as stable infrastructure and the model as a replaceable component. That way, most upgrades require minimal changes.

This matters because production agents are never finished. Models keep improving, and each new model changes what the harness needs to do.

Teams that plan for this from the start, by isolating model assumptions, maintaining evaluation sets, and measuring what the harness actually contributes, can upgrade models without rebuilding the entire system. Teams that don’t often end up starting over.

Frequently asked questions

What is a state-machine agent?

A state-machine agent is an AI agent whose available actions are limited by an explicit graph of states and transitions, so the model can only take actions the graph permits from its current state. Frameworks like LangGraph implement this by defining steps (nodes) and legal moves between them (edges) that compile into a workflow which rejects illegal actions outright.

Why do cheap AI models match expensive ones inside a state machine?

Because the state machine, not the model, enforces correctness on the constrained task. When illegal moves are structurally rejected and the model gets structured feedback on every attempt, the model’s job narrows to producing valid moves in a small space, which most models do equally well. A benchmark of eight models on the same workflow saw seven score perfectly, separating on cost rather than correctness, with the cheapest matching the most expensive.

What do state machines not handle for AI agents?

Content correctness. A state machine controls the path the agent takes through the process. It does not check whether the data moving along that path is right, so an agent that creates a wrong invoice will move that wrong invoice through a fully legal, fully audited approval. Extraction and interpretation before the first step also run unchecked.

Is LangGraph or Temporal better for production AI agents?

They solve different problems and are often combined. LangGraph handles the state-machine orchestration that defines the agent’s steps, and it checkpoints state so a run can resume. Temporal handles durable execution: it owns the workflow lifecycle and guarantees the run finishes across crashes, replaying coordination logic without re-running completed work. Checkpointing is a save-point you manage; durable execution is a completion guarantee. A common production setup runs the state-machine logic on top of a durable layer to get both the defined path and real crash recovery.

Should you use one agent or multiple agents?

Default to one. Multiple agents help only when the task splits into independent pieces that do not need to share state, and when you can afford a large token multiple (one reported design used roughly fifteen times the tokens of a single agent). The moment agents must coordinate writes or share context, the coordination failures tend to cost more than the parallelism gains, so a single agent on a clear path is the safer starting point.

TL;DR - Self-improving AI agents in 2026 do not improve through model weight updates. They improve at the harness layer (orchestration, evaluation, A/B gating) and the context layer (per-tenant memory and skill libraries). Sixty production deployments across customer support, devtools, legal, healthcare, finance, sales, recruiting, and real estate converged on this architecture. The vertical leaders win by owning the loop inside the product, not by training a better base model. The biggest unfilled opportunity is the horizontal self-improvement engine, no vendor sells one. Build in a vertical: invest in eval surface and outcome-based pricing. Build horizontally: ship the packaged loop that plugs into any agent stack.

Subscribe now

What “self-improving” actually means in production

The “self-improving agent” label is doing heavy lifting in 2026 product marketing. The label conflates four very different mechanisms: weight updates from production traces, harness changes shipped after A/B testing, per-tenant context that accumulates from user interactions, and procedural skill libraries that compound across sessions. Most products marketed as “self-improving” do exactly one of these, usually the third, and stop there.

Across the production landscape, the dominant pattern is harness plus context. Real model weight updates are concentrated in a handful of companies with proprietary data flywheels: Hippocratic AI versions its Polaris suite with documented progression from 96.79% to 99.38% clinical accuracy on its RWE-LLM safety benchmark, EvenUp trained Piai on hundreds of thousands of personal-injury cases, Abridge ships custom medical speech recognition across fourteen languages, and Harvey co-developed a case-law model with OpenAI. Everyone else differentiates at the harness and context layers.

The model layer is where a small number of verticalized leaders defend a moat. The harness layer is where every serious player wins or loses the production loop.

The three-layer architecture

The three-layer model, popularized by LangChain in early 2026 and now widely adopted, separates what changes in an LLM system into model, harness, and context. Each layer has its own improvement surface, its own cost curve, and its own failure modes.

Model layer: rare, expensive, high-moat. True weight updates from production traces. The pattern is consistent across the four companies that do this: own a proprietary data flywheel, build a benchmark, ship versioned models. Glean’s Waldo agent runs on Nemotron 3 Nano. Most enterprises buy frontier models and never touch the weights.

Harness layer: the active battleground. The orchestration, evaluation, retry, gating, and reflection logic that constrains and verifies model behavior before output reaches the user. This is where almost all 2026 differentiation lives. Cursor publishes harness-improvement details openly, measuring releases against an internal CursorBench plus an offline grader plus online A/B with Code Retention and Keep Rate as proxies. Anthropic documents Claude Code’s harness evolution across released versions. Decagon’s Agent Operating Procedures are a harness in disguise. The term “harness engineering” has moved from Anthropic-internal vocabulary to industry-standard framing.

Context layer: where customer specificity compounds. Per-tenant memory, knowledge packs, skill libraries, and tool manifests. Every serious vertical agent has a context studio: Sierra Explorer, Decagon Duet, Hex Context Studio, Ada Coaching, Intercom Procedures, Harvey Memory. This layer is where customer-specific value compounds, and where the multi-tenant safety problem lives.

The model layer is where vertical leaders defend a moat. The harness layer is where every serious player wins or loses the production loop.

Harness Topology applied across sixty deployments

Harness Topology is the comparative discipline of analyzing harness shape across regulated industries, used to identify which harness design patterns generalize across verticals and which are domain-locked. Built on Vertical Agent Anatomy, applied cross-vertically. Inside it sit two named concepts: Harness Half-Life (the durability axis: how fast harness investment depreciates as the model evolves) and Harness Saturation (the viability threshold: the point at which a system labeled an “agent” is a deterministic workflow with an LLM bolted on).

Applied empirically across roughly sixty production deployments in 2026, Harness Topology reveals nine patterns that repeat across every leading vertical agent. A vertical agent that does not implement at least seven of them is missing a core mechanism.

1. Traces as the unit of truth. Every serious shop treats execution traces as the artifact that drives improvement. LangSmith, Langfuse, OpenTelemetry GenAI conventions, and Cursor’s internal trace store all encode this.

2. LLM-as-judge plus golden datasets. Glean’s internal AI Evaluator hits 74% human agreement rate; Harvey’s LAB benchmark uses rubric-based LLM grading; Cursor’s CursorBench and Decagon’s simulation suite combine LLM judges with human review.

3. Per-tenant context studios. Sierra Explorer, Decagon Duet, Hex Context Studio, Ada Coaching, Intercom Procedures, Harvey Memory. Every leader has one; nobody sells one as a horizontal product.

4. Skill libraries as procedural memory. Anthropic’s Agent Skills standard (SKILL.md plus scripts) is being copied by Replit, Devin, OpenHands, and Cursor Rules. An open-source marketplace ecosystem already exists at scale.

5. A/B harness experimentation on real traffic. Cursor A/Bs harness variants and measures Code Retention. Intercom A/Bs Fin against production baselines on every change. Decagon versions and simulates conversations before deployment.

6. Outcome-based pricing aligned with the improvement loop. Sierra charges only on full resolution; Intercom Fin charges per resolution; EvenUp’s pricing is tied to settlement outcomes. The loop is structurally aligned with the customer metric.

7. Offline “dreaming” jobs. Coding agents that run nightly over recent traces, propose harness or context changes, and gate against an eval suite. Sierra Explorer, Decagon Duet, Intercom Optimize, and Cursor’s harness-improvement agent are all variants.

8. Vertical benchmarks as the eval moat. Harvey’s LAB, Mercor’s APEX-Agents (open-sourced on Artificial Analysis), Hippocratic’s RWE-LLM. The benchmark itself becomes a competitive asset distinct from the product.

9. Workflow / SOP ingestion as cold-start. Sierra Ghostwriter, Decagon AOPs, Ada Playbooks, Harvey Workflow Agent. Natural-language SOPs and call transcripts bootstrap the first agent before any improvement loop has data.

The patterns are not fashionable. Each one closes a specific failure mode. A vertical agent missing trace infrastructure cannot improve at all. A vertical agent without a golden dataset cannot ship harness changes safely. A vertical agent without per-tenant context cannot survive contact with the customer’s idioms. The list is functional, not aesthetic.

The five standardized axes that turn rebuild into configuration

Across verticals, the leaders also converge on five standardized axes that turn vertical onboarding from rebuild into configuration. Each axis is a slot in a generic agent kernel, planner, memory, tool router, critic, that gets filled with vertical-specific configuration.

1. Workflow / SOP ingestion as the bootstrap. Sierra Ghostwriter ingests existing SOPs and transcripts. Mercor Enterprise runs AI-moderated interviews with employees to extract tacit workflows. Harvey requires firm-specific upload of precedents before work begins.

2. MCP / connectors as the tool layer. MCP has effectively won as the integration standard. Clay’s Claygent connects to any MCP server. Devin and Cursor expose MCP marketplaces. Glean ships over 100 connectors. The tool layer is no longer differentiation; the manifest is.

3. Per-tenant context store. Universal pattern. Customer-specific knowledge, working style, precedents, and learned patterns isolated per tenant. The audit surface lives here.

4. Vertical benchmarks as the eval moat. Harvey’s LAB, Mercor’s APEX-Agents, Hippocratic’s RWE-LLM. The benchmark itself is the competitive asset. Harder to copy than a feature; compounds over time.

5. Outcome-based pricing. Sierra and Intercom Fin price on resolution; EvenUp ties to settlement outcomes. Pricing structurally aligns the improvement loop with the customer’s metric, the agent that improves the customer’s outcome also improves its own revenue.

These five axes are what makes the harness layer the active battleground. A vertical agent with a strong eval suite and outcome-based pricing has a self-tuning revenue model. A vertical agent without them has shipped a demo.

What the numbers actually say

Most of the cited improvement numbers in the 2026 self-improving agent market are vendor-published. Treat them as directional. Where independent benchmarks exist, the picture is less flattering than the marketing.

Hebbia’s Matrix shows 92% accuracy with o1 versus 68% out-of-the-box RAG on a legal/financial benchmark, a vendor-published number on a vendor-defined benchmark. Cognition reports Devin 2.0 is 83% more productive than 1.x per Agent Compute Unit, also vendor-published, with no methodology release. Intercom Fin reports 51% average resolution across its customer base, with Lightspeed at 65% end-to-end and Synthesia at 87% self-serve, customer-reported, but mediated through Intercom’s product analytics.

The independent benchmark numbers tell a different story. Mercor’s APEX-Agents benchmark, 480 tasks across investment banking, consulting, and law, released open-source, shows frontier models scoring roughly 33%, a large gap to humans. OpenHands reports about 77% on SWE-Bench Verified with Sonnet 4.5. The verticals where independent benchmarks are publicly available are the verticals where the production gap is widest.

The reading is consistent with Harness Topology’s central claim: harness investment is what closes the gap between frontier-model benchmark score and customer-outcome resolution rate. The customer cares about resolution rate. The model cares about benchmark score. The harness is what translates one into the other.

Where the pattern saturates

Harness Saturation is the viability threshold inside Harness Topology, the point at which a system labeled an “agent” is actually a deterministic workflow with an LLM bolted on, because the harness has accumulated so many gates, verifications, and constraints that no autonomous decision remains. The end-of-agent signal: every decision is gated, every output is validated, every action requires approval, and the LLM call is reduced to a structured-output formatter.

The most regulated verticals are closest to saturation. Healthcare clinical-decision agents and legal demand-letter agents have so many compliance gates that the autonomous surface has collapsed to schema completion. Customer support is further from saturation because the customer’s tolerance for a wrong answer is higher than the patient’s. Devtools is furthest from saturation because the human reviewer is in the loop on every change.

Saturation matters because it tells the practitioner when to stop adding harness. Adding more gates past saturation degrades completion rates without lowering incident rates. The engineering-correct move is to drop the LLM and ship the deterministic workflow it became.

The biggest unfilled opportunity

The vertical-agnostic self-improvement engine does not exist as a product. Every serious vertical agent runs a version of the same loop: trace → cluster failures → propose context or skill update → gate against eval suite → ship. Sierra Explorer, Decagon Duet, Intercom Optimize, and Cursor’s harness-improvement coding agent all implement variants. None is sold as a horizontal product.

That is the largest single opening in the territory. A packaged self-improvement loop, plugging into any agent stack via traces, producing per-tenant context and skill updates that any eval suite can promote, would slot into every vertical without rebuilding the loop. The market readiness is high; the competitive whitespace is wide; the product does not exist.

The closest adjacent products are observability platforms (LangSmith, Langfuse), Anthropic’s Agent Skills registry which crossed 277,000 installs on the frontend-design skill alone, eval platforms (Braintrust, HoneyHive), and memory products (Mem0, Zep, Letta). None of them ships the full loop. The observability platforms see traces but do not propose changes. The eval platforms score outputs but do not generate updates. The memory products store context but do not curate skills.

A horizontal self-improvement engine sitting between these three would be the missing keystone. It is the single most valuable position in the 2026 agent landscape that no vendor occupies.

The three-layer stack, visualized

FAQ

Where does self-improvement actually happen in 2026 agents?

At the harness and context layers, not the model layer. The harness layer covers orchestration, evaluation, retry logic, A/B testing, and reflection loops. The context layer covers per-tenant memory and procedural skill libraries. Real model weight updates from production traces are concentrated in four to six companies, Hippocratic AI, EvenUp, Abridge, Harvey, Glean, and require a proprietary data flywheel that most enterprises do not have.

What is the difference between Harness Engineering and Context Engineering?

Harness Engineering controls what the user sees: the gates, verifications, and orchestration logic that constrain model behavior before output reaches the user. Context Engineering controls what the model knows: every method of getting information to the LLM at inference time, including RAG, fine-tuning, long-context injection, prompt design, MCP tool use, and persistent memory. Both sit inside Model Reliability Engineering, the broader discipline of making LLM behavior reliable in production.

Why has no horizontal self-improvement product emerged?

Because the eval surface is vertical-specific. A self-improvement loop is only as good as the eval suite that gates its proposed changes, and every vertical defines correctness differently, clinical accuracy in healthcare, citation faithfulness in legal, resolution rate in customer support, Code Retention in devtools. A horizontal product would need a configuration surface that accepts any eval definition, plugs into any agent stack via traces, and produces context or skill updates that any deployment can promote. That surface is hard to design and harder to sell into without a category to lean on.

What does a vertical leader build before the improvement loop exists?

Workflow ingestion. Every leader starts the same way: ingest existing SOPs, call transcripts, audio recordings, or expert demonstrations, and turn them into agent behavior. Sierra’s Ghostwriter is the canonical example. Mercor Enterprise runs AI-moderated interviews with employees to extract tacit workflows. Harvey requires firm-specific precedent upload before work begins. The improvement loop only starts producing value once enough traces have accumulated; the first agent has to ship from the cold-start.

How does Harness Saturation get diagnosed in practice?

Three indicators compound. First, every decision in the agent’s path is gated by a deterministic check. Second, every output is validated against a fixed schema. Third, every action requires human or rule-based approval. When all three are present, the LLM call has been reduced to a structured-output formatter, and the autonomous decision surface has collapsed. The engineering-correct response is to drop the LLM and ship the deterministic workflow the harness has become. Adding more harness past this threshold degrades completion rates without improving incident rates.

The two open positions

The architecture has settled. The leaders have converged. The opportunity has narrowed to two clean positions and one unfilled gap.

For vertical builders, the moat compounds in the eval surface and the customer-outcome metric. Capital invested in proprietary benchmarks and outcome-aligned pricing returns more than capital invested in fine-tuning the base model. The four to six companies running real weight-update loops are the exceptions that prove the rule: they own data flywheels nobody else can replicate, and even then the differentiation visible to the customer is harness-mediated. Vertical leaders without the data flywheel should stop trying to compete on model and start competing on benchmark depth and pricing structure.

For horizontal builders, the territory open in 2026 is the packaged self-improvement loop. Any product that plugs into an agent stack via traces, produces per-tenant context and skill updates, and gates them against the customer’s existing eval suite occupies a position no vendor currently holds. Observability sees the traces, eval platforms score outputs, memory products store context, but none ships the full loop. The market is ready, the configuration surface is hard but tractable, and the first credible category entry will define how every vertical agent procures self-improvement for the next decade.

A subscriber brief mapping the full sixty-deployment landscape, the nine cross-cutting patterns, the three-layer memory stack, the mechanism catalog, and the opportunity map is available below:

Self Improving Agents Theairuntime

3.56MB ∙ PDF file

Download

Download

The short version: Anthropic’s CEO just published Policy on the AI Exponential, asking for an FAA-style regulator that tests frontier models and blocks the unsafe ones before release. For most of the industry that is a new idea. For anyone building AI inside a bank, it describes the regime they have worked in since 2011, under a rule called SR 11-7. The interesting part is not the policy. It is that banking already has a working maturity curve for regulated AI agents, the acceptance criteria are published, and most teams sit two levels lower than they claim. Below is how to score your own agent, including a counterfactual test that exposes the most common lie a regulated AI tells.

Subscribe now

Banking already built the thing the essay asks for

His argument is that AI moves faster than policy can react, so frontier models should be tested by qualified third parties and blocked if they fail. The coverage fixated on the FAA comparison.

Banks have run a version of it for fifteen years. In 2011 the Federal Reserve and the OCC issued SR 11-7, the supervisory guidance on model risk management, later adopted by the FDIC. It rests on three pillars: sound development and use, independent validation, and governance with board accountability. The load-bearing idea is effective challenge, meaning critical analysis of a model by objective, competent people whose job is to find its limits. Examiners treat it as a baseline expectation, not a best-practice suggestion, and it covers machine learning, not just regression.

So if you build AI in a bank, the FAA the essay wants is not your future. It is the room you already stand in. Which makes the useful question simple: how mature is your agent inside that room, measured honestly?

The five levels, and the test that proves each one

Think of a credit-decisioning agent or an AML investigator as climbing five levels. The point of the levels is not the label. It is that each one has a specific eval that proves you are actually on it. If you cannot run the eval, you are not on the level.

Level one: it writes. A fluent credit memo or suspicious-activity narrative from a prompt, with nothing real underneath. No eval needed, because there is nothing to verify.

Level two: it is grounded. Every claim in the output traces to a record: the financials, the bureau pull, the transaction history, the bank’s own policy. The eval is a groundedness rate. Sample outputs, extract each factual claim, and check how many trace to a source. Anything below near-total is a hallucination problem, and a validator will find it before you do.

Level three: it follows the rules. The output carries the regulatory format: adverse-action reason codes that satisfy ECOA and Regulation B, the required SAR elements, SR 11-7 documentation. The eval is a schema pass rate. Run a structured validator over a few hundred outputs and check that every required field is present and every reason code comes from the approved set. Most bank AI tooling reaches here, and here is where teams stop, because the output finally looks finished.

Level four: the establishment grades it, not you. Your eval set is now owned by the people who challenge your model. Validation pass rate: how often does effective challenge accept the model versus send it back. Adverse-action dispute rate. AML alert precision, filed SARs over alerts raised, against a baseline where roughly 95% of rule-based alerts are false positives. You are no longer measuring whether the document reads well. You are measuring what the regulator and the validator do with it.

Level five: it is accepted as evidence. The validator, then eventually the examiner, takes the model’s own output as proof rather than redoing the work. The model’s stated reason becomes the legally sufficient denial reason. No bank is fully here, and the essay is, in effect, arguing the whole industry should build toward it.

The eval that earns the share

Here is the test most regulated AI fails, and the one worth running first.

The CFPB stated in 2022 that a black-box model does not excuse a lender from giving a specific, accurate reason for every denial, and that a reason approximated after the decision is not enough, because it has to reflect the factors actually used. Read as an engineer, that is a faithfulness requirement on the explanation, and it is testable.

Take a denial where your system told the applicant the main reason was, say, debt-to-income. Change only that input, push debt-to-income into the approving range, hold everything else fixed, and re-score. If the decision does not flip, debt-to-income was not actually driving it. The reason you gave the applicant was a plausible story, not the cause, which is exactly the post-hoc approximation the CFPB rejects.

Run that counterfactual across a sample of denials and you get a reason-faithfulness rate: the share of stated reasons that actually move the decision. Most teams have never run it, and most are shocked by the result, because their reason codes come from a feature-importance library bolted on after the model, not from the decision itself. A level-three system passes the format validator and fails this test. That gap, looks compliant, is not faithful, is the single most useful thing to measure in regulated AI, and it is invisible to every demo.

This is also why level four matters more than it looks. Wiring the counterfactual check, the validation-survival rate, and the dispute rate back as your evaluation set is the move from grading your own homework to letting the establishment grade it. SR 11-7’s demand for effective challenge by independent validators is the same idea written into law: your model has to survive evaluation by an adversarial party you do not control. The thing Dario is asking regulators to impose on frontier models, banking already imposes on its own.

Why this is not only a banking problem

The pattern repeats wherever an external body owns acceptance: a regulator, an independent validator, a court. The value of your agent is capped by how much of that body’s judgment your harness has internalized, and the only honest measure of progress is their response, not your output. Pharma teams are watching the FDA write those criteria now. Banking has had them since 2011. The curve is identical. Only the establishment changes, which means the bank team that nails the counterfactual reason test is building the playbook insurance, legal, and healthcare teams will copy.

The honest catch

There is a fair argument that the top level never arrives. A regulator that accepts a model’s self-explanation as sufficient has given up some of the judgment it exists to apply, and the CFPB’s whole point was to distrust the black box. Weigh the messenger too: the person urging regulators to formalize AI testing runs an AI company, published the essay the day after shipping a new model, and critics have already called the broader proposal regulatory capture.

It does not change the practitioner takeaway. Even if no regulator ever accepts raw model output as standalone evidence, the criteria they enforce decide how much work your system is allowed to carry, and banking has the clearest published version of those criteria anywhere. The teams that read them as eval specs, not compliance paperwork, are the ones who will still be standing when the audit comes.

Where this leaves you

Score your most important regulated agent on the five levels, then run the counterfactual reason test on a sample of its outputs. If the stated reasons do not move the decisions, you are not where you think you are, no matter how clean the output looks. The banks that measure faithfulness instead of fluency are quietly building the standard every regulated industry will inherit when its own FAA finally arrives.

Share

TL;DR - Your agent worked last month. It doesn’t today. The model behind it changed, the inference stack underneath it was swapped, a downstream API quietly updated its tool schema, or special-case branches piled up inside the harness itself. The harness’s behavioral effectiveness against its original validation baseline has shifted, and the shifts compound.

Harness Half-Life is the Model Reliability Engineering metric for catching that shift before a customer does. The playbook is short: freeze a small reference suite at deployment, re-run it weekly, plot a single number (the percentage of original guarantees still holding), and act when the number drops below your tripwire. Field-tested teams cross the 0.90 tripwire in four to twelve weeks; the formal half-life (50% guarantees lost) typically arrives only after a team has neglected the curve through multiple driver events. This piece is the four-driver decomposition, the triage playbook, and what to tell your customer between week zero and week six.

Share

What is Harness Half-Life?

Harness Half-Life is the period after which a deployed harness loses half its behavioral effectiveness against its original validation baseline, driven by four independent decay forces operating in production: model upgrades, inference-stack swaps, tool and schema drift, and internal aging.

The metric sits inside the Harness Engineering pillar of Model Reliability Engineering.

Why agents decay

The harness engineering discourse — OpenAI’s formalization post, LangChain’s anatomy breakdown, Anthropic’s two essays on long-running agent harnesses, a recent Hashimoto writeup on agent harness adoption, our coding-agent harnesses and HumanLayer’s “Skill Issue” framing - converged in early 2026 on a shared model of what a harness contains. With the canonical equation Agent = Model + Harness.

What none of that work tells a production team is how to catch a harness when it starts failing. That is the Harness Half-Life chapter of Model Reliability Engineering. The closest existing usage of a decay term is a per-component “harness half-life” framing, which addresses component-by-component obsolescence as models improve; that framing sits cleanly inside the model-upgrade driver of the broader four-driver decomposition below.

Anthropic’s engineering team comes closest to naming the underlying pain in the managed-agents post. A harness component bakes in a compensation for some specific limitation of the underlying model, and as the model improves that compensation can stop matching what it was designed for. The concrete example: a context-reset mechanism added to handle Sonnet 4.5’s habit of wrapping up tasks prematurely became unnecessary on Opus 4.5. The harness didn’t break. It just no longer matched the model.

Harness Half-Life sits inside the Harness Engineering pillar of Model Reliability Engineering. Harness Engineering is what the industry has named; Harness Half-Life is the measurement the industry has not.

The four drivers, plainly

Four forces move a deployed harness off its validation baseline. Each one has a tell, and each one has a different first response.

The reliability score and tripwire

Take the percentage of a frozen reference suite that passes at deployment. Call that 100%. Each week after deployment, re-run the suite and divide the week’s pass rate by the deployment pass rate. The result is the reliability score, a single number per week, starting at 1.0 and descending.

(For the academically inclined: this is a normalized survival function borrowed from reliability engineering. The math underneath is one line; the discipline of running it on a cadence is the actual work.)

Three zones on the curve are operationally meaningful.

Zone Reliability score What you do Green > 0.95 Standard monitoring cadence Yellow 0.7 – 0.95 Investigate which driver moved; budget a re-validation Red < 0.7 Stop shipping new features; rebuild or hard re-validate

The line between yellow and green is your tripwire. It is a configuration choice, not a universal constant.

Context Tripwire Reasoning Regulated, customer-trust-critical 0.95 Trigger on the first real drop Standard production 0.90 Allow 10% guarantee erosion Internal tools, cost-optimized 0.80 Accept higher tolerance for lower cadence

Field-tested teams cross the 0.90 tripwire in four to twelve weeks. Variance across teams is enormous; variance for a single team across consecutive deployments is much smaller. After two or three deployments a team learns what its own curve looks like.

Subscribe now

The triage playbook

When the reliability score drops, the team has hours to attribute the cause before someone files a P2. Four moves in order, fastest to slowest.

Move 1: check the calendar. Did the drop coincide with a frontier-model release, a tool provider’s changelog entry, or an infrastructure change the team made? Maintain a shared annotated timeline of these events from the start of every deployment. Most drops resolve at this step.

Move 2: slice the suite. Which categories moved? The pattern of slice movement points at the driver before any code runs.

What you see Most likely driver Big jump in refusal-category or structured-output failures Model upgrade Many slices each move a little, no model release Inference-stack swap One tool’s slice tanks; the rest stay flat Tool / schema drift All slices descend gradually, no event Internal aging

Move 3: roll back one thing. Re-run the failing prompts against the previous model version, the previous tool schema, or the previous harness commit. Whichever rollback restores the failing prompts identifies the source. Keep these rollback configurations runnable on demand. That is a discipline more important than any specific monitoring tool.

Move 4: A/B inference paths. If moves 1 through 3 are ambiguous, run the same prompt against the current inference stack and a reference FP16 stack. Token-level divergence on previously-passing prompts isolates inference-driven decay, the silent class that doesn’t show up in any benchmark.

A complete triage runs all four when needed. Most production incidents resolve at move 1 or 2.

The four drivers, deeper

Each section below adds the texture and citations the triage playbook glosses over.

1. Model upgrades

A frontier-model release changes what the harness sits on top of. Refusal patterns shift. Tool-call distributions move. Structured-output formatting changes. Default verbosity moves. A harness regex tuned to Sonnet 3.5 outputs may match nothing on Sonnet 4.5. A guardrail that fires on a particular phrasing may stop firing.

Anthropic’s engineering writeup documents this candidly. A harness modification added to compensate for a Sonnet 4.5 behavior became unnecessary on Opus 4.5, because Opus didn’t exhibit the behavior. The companion article on harness design confirms the pattern across iterations. Lessons from earlier-model harness work explicitly didn’t carry forward unchanged.

The footprint on the curve is a discrete step drop coincident with a release. The step size depends on how tightly the harness was coupled to specific model behaviors. Loosely coupled harnesses (string-tolerant validators, behavior-agnostic routing) show small steps. Tightly coupled harnesses (regex extraction, phrase-specific guardrails) show large ones.

The fix is not to avoid upgrading. The fix is to pin model versions explicitly in production, treat each upgrade as a re-validation event, and pay the validation cost on a planned schedule rather than an unplanned one. Across publicly observed Anthropic, OpenAI, and Google releases, a frontier-model release ships roughly once a quarter per provider; the Anthropic release calendar alone makes this cadence visible to any production team that watches it.

2. Inference-stack swaps

This is the underrecognized driver. A “lossless” inference-stack change, switching to a quantized variant, moving to a new serving runtime, adopting an inference-optimization vendor, looks like an infrastructure choice and lands as a behavior change.

Inference optimization is genuinely valuable. Decode latency is memory-bandwidth bound, AI chip compute has outpaced memory bandwidth roughly 4.7-to-1 over the last decade, and every serious vendor ships some form of compression. The trouble is that “lossless” means different things to different vendors. QuaRot’s 4-bit LLaMA2 result retains 99% of zero-shot performance. NVFP4 recovers 95-99% of BF16 accuracy depending on model size. Together AI’s Blackwell guidance markets near-lossless quality. A new entrant, Isiro Labs, claims bit-exact preservation while reducing the bytes inference moves over the bus.

What matters in the field: a benchmark-equivalent stack swap can still flip the argmax on out-of-distribution structured outputs the benchmark suite never covered. A function-calling harness that hits a specific branch when the model emits a particular JSON key may stop hitting that branch after the swap, even if MMLU scores are identical. Most production teams attribute these drops to upstream model regressions and complain to the model provider, who responds (correctly) that nothing on their end changed.

The footprint is the easiest to miss. Many slices each move a small amount, with no external model release on the calendar. The fix is to never deploy an inference-stack swap without an A/B reference path running against a known-good stack for at least a week.

3. Tool and schema drift

Tools are not stable. Downstream APIs change schemas, deprecate fields, add required parameters, modify response shapes. Each change moves the contract the harness was built against.

The clearest public incident is the n8n schema drift event in February 2026. An upgrade from v2.4.7 to v2.6.3 changed how tool schemas were generated, and the new output was rejected by both OpenAI and Anthropic API endpoints. Enterprise workflows running production agent jobs stopped working entirely. The only short-term fix was rolling back the version. Nobody caught it before it hit production because the harness’s tool-schema layer was not on the regression eval suite.

The Replit July 2025 postmortem is a different angle on the same problem. An agent given full autonomy made a confident wrong decision that cascaded through the workflow. The MCP standard introduced by Anthropic in late 2024 solved tool connectivity but not coordination. A common production pattern is an agent that calls a tool, gets back a response shape it wasn’t designed to handle, and loops indefinitely consuming tokens. The growing MCP-server ecosystem magnifies this surface: every additional connected tool adds an independent contract that the harness depends on.

The footprint is the most distinctive of the four drivers. One slice tanks while the rest stay flat. A harness with 30 tools wired up has 30 independent decay clocks running in parallel. The fix is to pin tool versions in production deployments and to put each tool’s contract on the reference suite. Most teams don’t, and that is where the silent failures live.

4. Internal aging

The fourth driver is the harness aging itself. Every incident handled in production typically adds a branch, a new validator, a new override, a new edge-case handler. Over time these accumulate. The harness gets brittle in a different sense: it works, but each new component costs more to add than the last, and the testing surface grows faster than the team can maintain.

The quantitative evidence is striking. Vercel’s December 2025 post on removing 80% of their agent’s tools reports success rates climbing from 80% to 100%, with token use cut by more than half and latency dropping from roughly 724 seconds to 141 on the same model with harness-only changes. LangChain’s TerminalBench result improved from 52.8 to 66.5 on the same base model with harness-only changes. A practitioner survey reports that production-quality harnesses get rewritten multiple times: Manus rewrote five times, LangChain four. Industry surveys put the enterprise AI agent project failure-to-production rate at as much as 88%, and the dominant failure pattern is rarely a model gap.

The footprint is a continuous gradual descent that doesn’t coincide with any external event. The fix is harder than the others. Stop patching, plan a rebuild. The rule of thumb across teams that have done this multiple times is to build harness components to be deleted, not preserved.

What to tell your customer

When the reliability score crosses the tripwire and a customer is involved, the communication script is short. Three messages, in order.

“The behavior you’re seeing is real, and we’ve quantified it.”

Sharing the reliability score is the fastest way to convert a vague customer report into a tractable engineering item.

“We’ve identified the driver and are taking this specific action.”

Naming which of the four drivers moved (model upgrade, inference swap, tool drift, internal aging) and the rollback or patch being applied turns the conversation from “your AI is broken” into “you have a process.”

“Here’s what changes in our re-validation cadence going forward.”

Tightening the cadence after a tripwire crossing is the visible discipline that resets customer trust. “We’ll watch it” is not enough.

This is the field-level reason the Harness Half-Life discipline exists. The curve is not for the team’s quarterly metrics. It is for the customer call that is coming.

When the tripwire doesn’t bite

Harness Half-Life matters most when decay drivers are moving. There are regimes where the reliability score barely descends, and the literature is honest about that. Scale AI’s SWE-Atlas reported that for some model families harness choice did not produce statistically meaningful differences. METR’s benchmarks show some coding-agent harnesses do not consistently outperform a basic scaffold.

Translated to operations: if the team’s tooling is mature and slow-changing, the model is pinned to a long-deprecation version, and the production distribution is narrow, the curve will descend slowly. Re-validation can be deferred. But teams should measure to find out, not assume. A flat curve is a finding, and earning the right to relax the cadence requires data.

The Retrofit Tax when the rebuild comes

When the tripwire crosses and a rebuild is on the table, the cost of the rebuild is not just engineering hours. The canonical Retrofit Tax in the MRE arc breaks the cost into three compounding components: workflow debt (orchestration logic and prompt templates tuned for the old model’s failure modes that misbehave on the new model), schema opacity (input and output shapes that were stable on the old model but produce inconsistent shapes on the new model, breaking downstream consumers), and governance friction (audit, compliance, and approval surfaces that were certified against the old model’s behavior and must be re-certified).

The Retrofit Tax is what makes a model upgrade non-zero-cost even when the new model is strictly better. Teams underestimate it because they assume “the model is better → my system is better”; the harness is the missing variable. When the rebuild is calibrated against the Harness Half-Life signal - early, while the harness is in the yellow zone rather than the red, the Retrofit Tax is bounded. When the rebuild is forced by a customer incident in the red zone, the tax compounds.

FAQ

What is the minimum viable Harness Half-Life setup?

100 prompts in a frozen suite, stratified across the four driver footprints (refusals, structured outputs, tool calls, multi-turn flows). Weekly re-runs. A tripwire at 0.90. Grow the suite once the discipline is running. The full version is 500 to 2,000 prompts with 70% sampled from anonymized production traffic and 30% authored edge cases.

How does this differ from the per-component “harness half-life” framing?

The per-component framing addresses component-by-component obsolescence driven by model improvement. Each harness component has its own duration before becoming unnecessary. The whole-harness Harness Half-Life framework in this piece addresses the aggregate behavioral effectiveness across four independent decay drivers, of which model improvement is one. The two views are complementary: per-component half-lives feed the aggregate reliability-score curve.

How does Harness Half-Life work for multi-tenant harnesses?

Per-tenant reliability scores. Each tenant has a different production distribution and likely different downstream tools, so each tenant has its own decay rate. The aggregate curve hides the worst-affected tenants, which is usually the wrong thing to optimize. Multi-tenant production agents need a per-tenant reliability dashboard plus an aggregate, not just an aggregate.

Why do teams miss this?

The failures look like model regressions. When an agent that worked last month breaks this month, the natural assumption is the model changed. Usually the model did change, but it changed alongside one or two other drivers, and the tolerance budget was already depleted. Without a reliability-score curve, the team cannot tell which driver actually moved.

Where does Harness Half-Life sit in Model Reliability Engineering?

Inside the Harness Engineering pillar, alongside the construction-side discourse that the industry has already named. Context Engineering governs what the model knows; Harness Engineering governs what surrounds the model; Harness Half-Life is the measurement that tells the team how long what surrounds the model continues to behave as validated. Together they cover both sides of the model in production.

The on-call playbook

Reliability score crosses tripwire?
  YES → continue. NO → snooze.

Match the drop to a calendar event (model release, tool changelog, infra change)?
  YES → that is your driver. Re-validate against the change. Done.
  NO → continue.

Slice the score by category. Which slices moved?
  Refusals or structured outputs → model upgrade (silent, no release announcement)
  One tool slice → tool / schema drift on that tool
  Many slices, small movements each → inference-stack swap
  Everything gradual, no event → internal aging

Roll back the suspected source. Re-run the failing prompts.
  PASSING → driver confirmed. Re-validate or patch.
  FAILING → run A/B against reference FP16 inference. Token diff identifies the layer.

Document the driver, the action, and the new cadence. Tell the customer.

The agent that worked last month is not the agent that is running today. The only field-level question is whether the team is measuring how far it has moved, and the only customer-level question is whether the team caught it first.

Share

A model can produce a response that is true to its training data but unsupported by the documents you actually retrieved. It reads perfectly. The user never notices. Your accuracy score never flags it.

One metric catches it: faithfulness.

Does every claim trace back to retrieved context?

Two rules make it work. Measure it with a different model than the one that generated the answer, because nothing is a reliable judge of its own output.

And below 0.70, you are hallucinating in roughly a third of responses and have no business in front of users.

That is one gate. There are three, each with a continue, refine, or stop threshold. All of them on one cheat sheet below:

Eval Gate Cheat Sheet

125KB ∙ PDF file

Download

Download

If your inference bill is climbing or you are running out of GPU memory, you have two ways to make a model smaller. Quantization cuts the most bytes but changes the model’s outputs, which is a problem for anything regulated or already validated. Lossless compression cuts about 30% of the bytes by re-packing the wasted space in BF16 weights, and the outputs come back bit-for-bit identical. The DFloat11 research confirms the 30% with zero accuracy change, and ZipNN reports similar. The 30% is a fixed ceiling, not a knob, so treat it as a free one-time discount for BF16 workloads that are memory-bound and cannot tolerate changed output. ISIRO Runtime is one commercial product built on this technique, with vendor-reported numbers worth testing rather than trusting. Before you quantize anything, run a bit-exact diff on a compiled model and measure whether your decode path is actually memory-bound.

TL;DR - If your inference bill is climbing or you are running out of GPU memory, you have two ways to make a model smaller. Quantization cuts the most bytes but changes the model’s outputs, which is a problem for anything regulated or already validated. Lossless compression cuts about 30% of the bytes by re-packing the wasted space in BF16 weights, and the outputs come back bit-for-bit identical. The DFloat11 research confirms the 30% with zero accuracy change, and ZipNN reports similar. The 30% is a fixed ceiling, not a knob, so treat it as a free one-time discount for BF16 workloads that are memory-bound and cannot tolerate changed output. ISIRO Runtime is one commercial product built on this technique, with vendor-reported numbers worth testing rather than trusting. Before you quantize anything, run a bit-exact diff on a compiled model and measure whether your decode path is actually memory-bound.

The cheapest way to lower an AI inference bill is usually not a faster chip. It is moving fewer bytes. Quantization does that by shrinking the numbers in a model, which changes its outputs. Lossless compression does it by removing wasted space in those numbers, so roughly 30% of the bytes disappear and the outputs stay exactly the same.

Lossless float compression cuts about 30% of an LLM’s size by re-encoding the low-information bits in BF16 weights, then unpacking them on the GPU during inference, with outputs that are bit-for-bit identical to the original model. Because it changes no numbers, it fits regulated deployments in finance, healthcare, and defense where quantization is disqualifying. Published work including DFloat11 and ZipNN establishes the technique; the catch is that the win only shows up when your workload is memory-bound, and it tops out at 30%.

This matters to three groups at once. AI engineers and architects choosing how to serve a model. Teams hitting a GPU memory or budget ceiling. And the decision-makers signing the cloud and hardware bills. All three are asking the same question in different words: how to run a model for less without making it worse.

Why your inference cost is really a memory problem

Modern accelerators can do far more math than they can be fed. Over the past twenty years, raw compute on server chips grew about 3.0 times every two years, while the memory bandwidth that feeds the chip grew only 1.6 times on the same cadence. The math got cheap. Moving the data to the math stayed expensive.

For text generation, that gap is the whole story. Generating one token means reading a large pile of weights from memory and doing very little arithmetic on each byte before reading the next pile. The expensive compute units mostly wait. That is why memory bandwidth, not raw compute, is now the main bottleneck for serving, and it is why the lever that lowers cost and latency is fewer bytes crossing the bus, not faster math.

There is a useful consequence hiding in that sentence. If the chip is waiting on memory, the compute is sitting idle and free. Any trick that spends a little of that idle compute to move fewer bytes is close to free at the margin. Lossless compression is exactly that trick.

Weights are not the only thing crossing the bus. As conversations get longer, the key-value cache becomes a second heavy consumer of memory traffic, and research on lossless KV-cache compression targets those bytes the same way. Weights are simply the clearest place to start.

Two ways to make a model smaller

Quantization is the popular option, and for good reason. It drops the precision of every weight from 16 bits to 8 or 4, which shrinks the model and the bytes moved per token. The price is that every weight becomes a slightly different number, so the model produces slightly different outputs. For a lot of products that is fine. For some it is a dealbreaker, and the research community has shown that the effect of lossy compression on model behavior, including safety and bias, is not yet fully understood.

Lossless compression takes a different path. Think of a ZIP file. You compress a folder to 70% of its size, and when you unzip it you get every original byte back, exactly. Lossless model compression does the same thing to the weights. It finds the wasted space, packs it tighter, and unpacks it before the math runs, so the model that executes is the original model down to the last bit.

The wasted space is real and measurable. A BF16 weight uses eight bits for its exponent, but a trained model’s weights cluster in a narrow range, so most of those exponent bits carry no information. DFloat11 re-encodes that redundancy and gets the weights down to about eleven effective bits, a roughly 30% reduction with bit-for-bit identical output. Independent groups land on the same figure: ZipNN reports lossless savings often around a third and sometimes above half. When separate teams converge on the same number, the number is real.

That convergence also sets the ceiling. The other bits in a weight behave like random noise and will not compress, so lossless cannot reach the 50% or 75% that 4-bit quantization hits. What it gives you is a bounded, one-time, free 30%. Not a knob you keep turning, a discount you take once.

Who should care, and the situations where it pays off

ISIRO.AI, a startup building on this technique, frames the value as lower cost, better memory-bound latency, data-center power savings, and longer edge battery life, across every scale. Stripped of the pitch, that resolves into four concrete situations.

You serve a model that has to stay exactly itself. A bank’s credit model, a hospital’s clinical-support model, or a defense classifier was approved as a specific artifact producing specific outputs. Quantizing it makes a different artifact, which in a strict regime restarts validation, audit, or filing. That clock can run months. Lossless compression sidesteps it entirely: the validated model and the deployed model are the same bits, so the memory savings arrive without reopening governance. A single changed digit in such a model can mean a different lending decision or a different dosage flag, which is why exact reproduction, not close-enough accuracy, is the bar. For these teams, bit-exact is not a nice-to-have. It is the only acceptable answer.

source: isiro.ai

You are about to outgrow your GPUs. A 30% smaller model is the difference between fitting and spilling. DFloat11 ran a 405B-parameter model, normally an 810GB load, on a single 8x80GB node. At a fixed memory budget the same compression bought 5.3 to 13.17 times longer context. A BF16 8B model is about 16GB; trim 30% and it lands near 11GB, which can be the line between one tier of GPU and the next. If you keep hitting out-of-memory errors or paying for the bigger instance, this is the lever.

You deploy at the edge or on-device. The same 30% lets a model fit on hardware that could not otherwise hold it, including embedded boards and devices like NVIDIA Jetson. ISIRO lists edge battery life as a target, because fewer bytes moved is less energy spent, which on a battery is the metric that matters. On a phone or a robot, the model that fits is the model you ship, so a 30% reduction can be the difference between an on-device feature and a slower round trip to the cloud.

You are paying a large, growing inference bill. A 30% cut in memory traffic translates fairly directly into fewer accelerators for the same memory-bound work. In round numbers, a fleet of 100 GPUs doing memory-bound serving could do the same work on roughly 70, or each GPU could carry about 1.4 times its previous load. That is also a cooling and energy line on the facility budget, which is why this lands on a decision-maker’s desk and not only an engineer’s. ISIRO lists data-center power among its targets for the same reason: fewer bytes moved is less energy burned, and at fleet scale that is a sustainability number and a budget number at once.

Quantization trades accuracy for memory. Lossless compression trades a little spare compute for memory. The right question is which one you actually have to spare.

When to do what

The choice between levers comes down to two questions. Does the deployment need bit-exact output? Is the decode path actually memory-bound? The answers point cleanly to a tool.

Your situation Need exact output? Decode memory-bound? Best lever Regulated or already-validated model Yes Yes or no Lossless compression Cost-driven, some accuracy slack No Yes Quantization (bigger cut) Already 4-bit but still memory-tight Maybe Yes Try lossless on top, expect a smaller extra win Compute-bound, or the model already fits n/a No Neither; no memory lever needed

Two rules of thumb fall out of the table. If you cannot change the output at all, lossless is the only memory lever that qualifies, full stop. If you can change the output and you are purely chasing cost, quantization’s larger reduction usually wins, and lossless is a smaller bonus you can stack on if you are still tight. The one case to avoid is reaching for either lever when you are not memory-bound, because then you are paying overhead to save bandwidth you were not short on.

How to take advantage of it

The adoption path is short and measurable, and you can run most of it in an afternoon.

Start by finding the workloads that are actually memory-bound. Profile a representative serving job and check whether the GPU is starved on memory bandwidth during decode at your real batch size. If it is, you have a candidate. If it is compute-bound, stop here.

Next, decide whether the workload needs bit-exact output. If it is regulated, validated, or audited, the answer is yes and lossless is your lever. If not, price quantization first and treat lossless as the fallback when you need exact output or a free top-up.

Then run the test that settles it. Compile the model into a compressed format, serve it, and diff the outputs against your uncompressed baseline. A true lossless path produces a diff of exactly zero. Measure memory traffic, latency, and cost against the same baseline. Now you have numbers for your workload instead of a vendor’s.

One practical worry for enterprises is whether evaluating a vendor means handing over the model weights. It should not. ISIRO’s stated approach is that you run without sharing your model, compiling and comparing against your own baseline in your own cloud or on-prem environment. Confirm that boundary in writing before any trial, because for a model that cost six figures to train, the weights are the asset you are protecting.

This is where a product like ISIRO Runtime fits the pattern. It compiles a model once into a compact execution-native .tic artifact, then runs it through an efficiency layer that sits between your model and the inference stack you already use, targeting vLLM, TensorRT, and OpenVINO with an OpenAI-compatible API so existing clients keep working. Support today is scoped to BF16 vLLM on NVIDIA GPUs. ISIRO reports 30% lower memory traffic and up to 2 times lower latency against a cuBLAS baseline on its evaluated workloads. Those are vendor-published figures from scoped tests, not independent benchmarks, and the latency comparison is against NVIDIA’s own library on NVIDIA hardware where ISIRO is an Inception and AWS partner. They line up with the published research on the technique, which is the most that can be said for a number nobody outside the vendor has reproduced. The point of the afternoon test is to replace that vendor number with yours.

If the model is your intellectual property, the compiled-artifact approach also opens a security option. ISIRO packages encryption, signing, and an in-use lock for the compressed file, plus hardware-backed confidential computing for buyers with strict isolation requirements. Treat those claims as a separate evaluation from the efficiency claims, because encryption of a model file is well understood and the differentiated part needs testing against your own threat model.

The catch: decode speed, and a hard 30% ceiling

Lossless compression is not free of engineering risk, and the risk is the same property that makes it work. Packing weights tighter produces variable-length codes, and those break the lockstep parallelism GPUs rely on, because no thread knows where its data starts without decoding everything before it. A naive implementation also unpacks weights into memory before computing, which puts back the exact traffic the compression removed.

The good implementations fix this by unpacking inside the computation. ZipServ describes a load-compressed, compute-decompressed design that keeps weights compressed across the bus and unpacks them on the fly directly into the compute units. Anyone can compress BF16 weights by 30%, because that ratio is a property of the data. The hard, defensible work is the decode kernel that keeps the saved bandwidth from being eaten by unpacking overhead. The product is the kernel, not the compression.

Two limits are worth saying plainly. The 30% does not grow; the redundancy in BF16 is fixed, while quantization research keeps finding lower bit-widths, so on a pure cost basis quantization often wins. And the technique only helps when decode is memory-bound, so on a small model that already fits or a compute-bound job, it is the wrong tool. Inside its scope it is close to a free lunch. Outside it, reach for something else.

Frequently Asked Questions

Is this just quantization by another name?

No, and the difference is the whole point. Quantization lowers the precision of the weights, which shrinks the model but changes its outputs. Lossless compression re-packs the existing weights and unpacks them exactly, so the outputs are identical to the original model. One trades accuracy for memory; the other trades a little compute for memory. You can even use both, though the lossless gain shrinks once weights are already quantized.

How much will it actually save me?

About 30% on BF16 models, with DFloat11 and ZipNN both landing near that figure. The ceiling is set by how much wasted space a BF16 weight contains, so a lossless codec cannot match the 50% or 75% that 4-bit quantization reaches. Treat 30% as a fixed, one-time discount, and run a test on your own workload to confirm the figure and the latency effect before committing.

Which models and hardware does this work on?

The technique applies to any model with repetitive numerical structure, large LLMs or small ones, though the headline 30% is specific to BF16 weights. In practice, tooling maturity is the constraint. ISIRO, for example, supports BF16 vLLM on NVIDIA GPUs today, with other frameworks and hardware on its roadmap. If you run a different stack, the research applies but the production tooling may not be ready yet.

Who on the team owns this decision?

Engineers and architects run the test and own the integration, because the value depends on whether decode is memory-bound and whether the bit-exact diff is truly zero. Decision-makers own the trigger, because the payoff shows up as fewer GPUs, a smaller cloud bill, and lower facility power. The fastest path is an engineer running the afternoon test and handing a decision-maker the cost delta for their actual workload.

Closing

Pick one model you serve in BF16 and ask two questions before your next GPU purchase. Is decode memory-bound at your production batch size? Does the deployment require exact output? If both answers are yes, compile the model, diff it against your baseline, and confirm the difference is exactly zero. The 30% is then yours to take with no accuracy conversation to have with anyone. If you are compute-bound or can tolerate changed output, you have just saved yourself a vendor call by knowing it.

TL;DR. In every other vertical, a wrong answer costs money. In law, a wrong answer that reaches a court costs a sanction, a malpractice exposure, and sometimes a license. That asymmetry is why the deployable unit in legal AI is never the model. It is the harness around it: the grounding layer that forces every legal proposition back to a retrieved primary source, the verification gate that refuses to pass an unverifiable citation, and the checkpoint router that decides which work product a human must sign. The two best-funded legal agents on the market, valued at eleven billion and two billion dollars, are not selling models. They are selling that harness. Before a legal agent ships, run one audit: take its last twenty outputs and try to trace every legal claim to a source it actually retrieved. The fraction you cannot trace is the real reliability number.

Subscribe now

A legal agent is a production AI system whose defining component is verification, not generation. The model drafts; the harness proves. Across the leading deployments, the architecture converges on the same shape: retrieval grounded in primary law, a citation-verification gate that blocks unprovable claims, a checkpoint router that assigns a human reviewer by task risk, and an audit trail that survives discovery. The model is the smallest part. What surrounds it is what separates a tool a partner will sign behind from a tool that ends a career.

Why legal is the hardest reliability problem in vertical AI

Most vertical agents operate where errors are recoverable. A misrouted support ticket gets reassigned. A mispriced transaction gets reversed. Legal work has no such buffer once it reaches a tribunal. A fabricated citation in a filed brief is not a bug report; it is a Rule 11 violation.

The reference incident is already three years old and still defines the field. In June 2023, the Southern District of New York sanctioned two attorneys five thousand dollars after they filed a brief containing six judicial opinions that did not exist. A general-purpose chatbot had generated the cases, complete with names, citations, and quoted passages, and when one of the attorneys asked the tool to confirm the cases were real, it said yes. They were not. What looked at the time like an isolated embarrassment turned out to be the first documented instance of a structural failure mode. By late summer 2025, one count put the number of documented AI-hallucination legal filings above three hundred, with more than two hundred recorded in 2025 alone. The pattern was not confined to one tool or one court: a different general-purpose chatbot surfaced fabricated citations in a high-profile matter, and by early 2024 a federal appeals court had referred an attorney to a grievance panel for filing nonexistent AI-generated cases.

The profession’s governing body responded with a rulebook. In July 2024 the American Bar Association issued its first formal ethics opinion on generative AI, Formal Opinion 512, mapping the technology onto existing duties: competence under Model Rule 1.1, confidentiality under 1.6, candor to the tribunal under 3.3, and supervision under 5.3. The opinion’s operational core is that verification is not optional and not uniform. The required level of independent review is factually specific and depends on the tool and the task: generating ideas demands less scrutiny than reviewing a document, and in no case can the tool substitute for a lawyer’s own competent judgment. Because forty-nine of fifty states have adopted the core structure of the Model Rules, that opinion functions as a de facto national baseline rather than advice a firm can ignore.

Two duties beyond candor shape the deployment itself. Confidentiality under Model Rule 1.6 protects all information relating to a representation, which means a legal agent cannot route privileged material to a model endpoint that retains or trains on its inputs absent informed client consent. Data isolation is a precondition of the architecture, not a configuration toggle. Privilege and work-product doctrine compound the point: the audit trail the harness keeps to prove its own outputs is itself potentially discoverable, so how it is scoped and retained is a legal decision before it is an engineering one.

In law, verification is not a feature of the product. It is the legal duty the product exists to discharge.

This is the constraint every legal agent inherits. The duty to verify cannot be delegated to the thing producing the output. So the architecture has to externalize verification into a layer the model does not control.

The reliability floor no model has cleared

The instinct is to assume the problem is solved by retrieval. Wire the model to a database of real cases, ground every answer in retrieved text, and the fabrications stop. The vendors who built exactly that marketed it as the cure. The first independent measurement found otherwise.

Researchers at Stanford’s regulatory lab and human-centered AI institute ran the first preregistered empirical evaluation of the proprietary legal research tools that sit at the center of practice. The study, later peer-reviewed and published in the Journal of Empirical Legal Studies, tested the retrieval-augmented systems from the two dominant legal publishers across more than two hundred hand-scored legal queries. The conclusion was blunt: the providers’ claims are overstated. The tools hallucinated between seventeen and thirty-three percent of the time. Broken out, one publisher’s tool erred on roughly one in six queries and the other on roughly one in three, against forty-three percent for the raw general-purpose model used as a baseline.

Two findings inside that result matter more than the headline. First, retrieval helps and does not cure. Grounding the model in real law cut the error rate roughly in half versus the bare model, but a one-in-three failure rate on a tool sold as hallucination-free is not a rounding error. Second, the errors are not only invented cases. They include mischaracterizing a real case, citing inapplicable authority, and misstating what a rule says, which are harder for a busy associate to catch than a citation that simply does not resolve.

The architectural lesson is precise. If retrieval alone leaves a double-digit error rate, then grounding is necessary but not sufficient, and the harness needs a second mechanism downstream of retrieval whose only job is to test whether each generated claim is actually supported by the retrieved source. That mechanism is the verification gate, and it is the component that distinguishes a legal agent from a legal chatbot.

What a legal agent actually is

A production vertical agent decomposes into seven layers wrapping the model, the reference architecture set out in Vertical Agent Anatomy. Three of those layers carry almost all the weight in law, because the legal constraint loads them in a way no other vertical does.

The first is grounding. A legal agent does not answer from parametric memory. It retrieves the controlling authority, statute, regulation, case, or contract clause, and constrains generation to what it retrieved. This is table stakes, and as the Stanford measurement showed, it is also not enough on its own.

The second is the verification gate, and this is the layer that defines the vertical. After the model drafts, the harness re-derives every legal proposition against the retrieved corpus before anything reaches a human. Does the cited case exist. Does it say what the draft claims. Is it still good law. Is the quoted passage real. A claim that fails any check is flagged or dropped, not surfaced as a confident answer. The reason a verification gate is non-negotiable here and optional elsewhere is that the duty of candor makes an unverified citation a professional violation regardless of whether anyone catches it.

The third is the checkpoint router. Legal work is not uniformly risky, so the harness does not apply uniform review. It routes by task: a first-draft research memo for internal use carries different review than a brief headed for filing. The clearest articulation of this pattern comes from the field’s most rigorous benchmark effort, which frames deployment as a question of whether an agent can do all, some, or none of a given task and assigns the human review tier accordingly. The router is where the ABA’s task-specific verification standard becomes code.

Around those three sits the audit layer, which records provenance for every output: what was retrieved, what the model generated, what the gate verified, who reviewed it. In a vertical where work product can be subpoenaed, the audit trail is not telemetry. It is evidence.

The production landscape

The market has already priced this thesis. The two highest-valued legal agents are explicit that the moat is the harness.

The research-and-drafting platform most associated with large law firms reached an eleven-billion-dollar valuation on the strength of an architecture it benchmarks obsessively. Its team built and published its own evaluation suite, and in May 2026 released an open-source legal agent benchmark containing more than twelve hundred tasks across twenty-four practice areas, graded against more than seventy-five thousand expert-written rubric criteria, with backing from every major frontier lab. The benchmark is structured to mirror how work is assigned and reviewed at a firm: an instruction, a client matter with real materials, and a work product that a human must sign off on. On the company’s own internal suite, vendor-published results put the strongest frontier model above ninety percent (these are the vendor’s own benchmark and methodology, not an independent measurement). The instructive part is not the score. It is that a company at this valuation spends its research budget building the measurement layer, because in legal the harness improves only as fast as the firm can measure where it fails. The same team’s research-specific benchmark goes further still: built with a data-labeling partner, it requires a model to use search tools, locate relevant context, and return cited responses end to end, which is the verification gate expressed as a test rather than left to run silently at inference time. The company has said it is expanding that public benchmark more than fivefold across global law, practice areas, and legal research, a sustained investment in measurement that only makes sense if the harness, not the model, is the thing being engineered.

The drafting side tells the same story from a different vertical slice. The category leader in personal injury raised a hundred and fifty million dollars in October 2025 at a valuation above two billion, bringing total funding to three hundred and eighty-five million. Its platform runs a proprietary model trained on hundreds of thousands of injury cases and millions of medical records, drafting demand letters and case documentation that human attorneys review. The company reports its case volume roughly doubling to ten thousand cases per week in six months (a vendor-reported operating figure), in a personal injury market it sizes at sixty-one billion dollars. The lead investor was a firm whose prior rounds it had already joined, and the round included the venture arm of the company that owns one of the legal research publishers the Stanford study measured, a strategic alignment worth noting when reading any single vendor’s reliability claims. The depth of the segment is visible in the company that raised a hundred and three million dollars for the plaintiff side the same week.

Map these to the architecture and the pattern is clean. The research platform’s benchmark obsession is the verification gate and the checkpoint router, instrumented. The drafting platform’s proprietary model trained on case-specific data is the grounding layer, specialized. Neither company’s pitch is that its model is smarter than a frontier model. The pitch is that its harness turns a frontier model into something a firm will deploy.

Where the harness saturates

The strongest argument against this thesis is that the model is catching up. A 2025 randomized controlled trial found that modern AI tools measurably improved lawyers’ work relative to working without them, and vendor benchmarks now show frontier models clearing ninety percent on firm-grade tasks. If the model reaches the point where it almost never fabricates, does the verification gate become dead weight.

It does not, for a reason specific to the vertical. In a domain where a single fabricated citation is sanctionable, the cost function is not the average error rate. It is the tail. A model that is right ninety-nine percent of the time still produces a fabricated authority once every hundred filings, and one fabricated authority in a filed brief is a Rule 11 problem no matter how good the other ninety-nine were. The verification gate is not insurance against a bad model. It is the mechanism that converts a probabilistic system into one whose output a human can attest to under a duty of candor. That requirement does not relax as the model improves; it is structural.

There is a real saturation risk, but it runs the other way. Pile on enough gates, retrieval constraints, and mandatory human checkpoints and the system stops being an agent at all. It becomes a deterministic retrieval-and-citation-check pipeline with a model bolted on for phrasing, the point of Harness Saturation. For low-risk, high-volume drafting that may be exactly right. For genuinely novel legal reasoning it is a ceiling. The design question for any legal agent is not how many gates to add. It is which tasks tolerate near-total gating and which need the model’s judgment to survive contact with the harness. The benchmark that grades tasks as all, some, or none is, read correctly, a map of where on that spectrum each workflow sits.

There is a second-order trap the Stanford measurement exposed. The tool with the higher error rate also produced markedly longer answers than the more reliable one, and more words mean more falsifiable propositions and more surface area for a claim to be wrong. A harness tuned to produce thorough, expansive output inflates its own verification burden. Concise grounded answers are not only easier to read; they are cheaper to verify, which in this vertical is the same as saying cheaper to trust.

FAQ

Do AI legal research tools still hallucinate?

Yes. The leading independent study found the major retrieval-augmented legal research tools hallucinate between seventeen and thirty-three percent of the time, well below the raw model baseline but far above any rate acceptable for unverified use. Retrieval reduces the problem; it does not remove it.

What is the review pattern in legal AI?

It is the deployment model where an agent produces a work product and a human reviews it before use, with the depth of review set by task risk. The most developed benchmark formalizes this by grading whether an agent can do all, some, or none of a task, which tells a firm where to set the checkpoint.

Does a better model remove the need for verification?

No. Because a single fabricated citation in a filing is sanctionable under Rule 11 and the duty of candor, the cost is driven by the worst output, not the average. Verification is what lets a human attest to the output, and that obligation is structural, not a function of model quality.

What does the ABA require for AI use in legal work?

Formal Opinion 512 maps generative AI onto existing duties of competence, confidentiality, candor, and supervision, and requires verification calibrated to the tool and the task. It is advisory, but functions as a national baseline because most states share the Model Rules structure.

What to do Monday

Take the last twenty outputs your legal agent produced. For each one, try to trace every legal proposition, every case, every rule, every quoted passage, back to a source the system actually retrieved. Count the propositions you cannot trace. That fraction is your hallucination exposure, and it is a more honest deployment signal than any benchmark score, because it measures the layer that determines whether a human can sign the work. If the number is not near zero, the gap is not in the model. It is in the gate.

The AI Runtime covers one idea from many angles: in production, the model is the smallest part of the system. Reliability, value, and defensibility come from the harness around it, the context it is given, the evaluations that gate it, and the identity it runs under.

The new Field Guide collects the sixteen deep-dives that build that thesis into one curated reading path. Read them in order to install the full mental model, or jump straight to the module that matches the problem on your desk this week.

What’s inside: 100% free. 16 deep-dives.

• The operating thesis in one read: why the model is the smallest part of a production system

• Module 01: the three deep-dives that install the mental model

• Module 02: five production agents torn down, including Rogo, HockeyStack, and Mintlify

• Module 03: context engineering, the eval lifecycle, and the real cost of running it

• Module 04: the agent-identity security frontier, from the trenches

• A bonus career track, plus the named frameworks (MRE, VAA, Harness Topology) collected in one place

New pieces land three times a week across Model Reliability Engineering, Vertical Agents, and Lessons from the Trenches. Subscribe free to get them as they ship.

Theairuntime

152KB ∙ PDF file

Download

Download

TL;DR - Richard Sutton’s “bitter lesson”, that general methods leveraging compute consistently beat handcrafted abstractions over the long run - applies more aggressively to browser harnesses than to almost any other part of the agent stack. Twelve months of evidence suggests the abstractions teams have built between the language model and the browser are not durable: NL-DSLs are being absorbed into foundation-lab computer-use models, planner-validator multi-agent topologies are being absorbed into longer-horizon model loops, and the carefully-curated tool definitions that ship with Stagehand, browser-use, and Skyvern are being out-competed by raw Chrome DevTools Protocol access. The most architecturally honest harness shipped in 2026 is browser-use’s Browser Harness, roughly 600 lines of code that hold a CDP websocket, expose a workspace where the agent writes its own helpers mid-task, and persist those helpers as a domain skill. The argument is uncomfortable for the SDK layer of this market and worth taking seriously anyway: the harness layer survives the next cycle only by becoming thinner.

The bitter lesson, restated for harnesses

Sutton’s original 1,143-word essay made a simple empirical observation about AI research over seventy years: methods that leverage general-purpose computation, search and learning, consistently outperform methods that encode human domain knowledge. The pattern repeated in chess, Go, speech recognition, computer vision, and language modeling. Researchers built increasingly clever feature engineering and increasingly intricate domain-specific abstractions; general methods with more compute beat them every time.

The translation to harness engineering is sharper than it looks. A browser harness sits between two compute layers: the language model on one side, the browser substrate on the other. The harness’s job is to mediate between them. Every primitive the harness exposes is, in Sutton’s terms, an encoding of human domain knowledge about how the model and the browser should interact. Every cache key is an encoding of which signals the harness thinks matter for determinism. Every accessibility-tree extraction is an encoding of which page representation the harness thinks the model can reason about.

The bitter lesson, applied to harnesses, is the prediction that all of those encodings will be outperformed by general methods - that is, by the language model talking to the browser substrate directly, with the harness providing only the substrate access and not the semantic interpretation.

The evidence for this prediction has been accumulating for twelve months. The interesting question is not whether the harness layer survives. It does. The question is what the durable subset of that layer looks like, and where the inevitable collapse leaves teams that built on the wrong abstractions.

What got commoditized in twelve months

The clearest evidence comes from the trajectory of foundation-lab computer-use models against the trajectory of harness-shipped abstractions over the past four quarters.

In Q2 2025, the harness layer had three structurally distinct topologies: code-first, NL-DSL, vision-CUA, each producing measurably different outcomes on common benchmarks. Stagehand’s act, extract, and observe primitives were genuinely additive over raw Playwright. Skyvern’s planner-and-validator multi-agent architecture moved the WebVoyager score from 45% to 85.8%. Browser Use’s Agent.run(task=...) was a primitive nobody else had.

By Q4 2025, the foundation labs had absorbed most of that surface. Anthropic’s Claude Sonnet 4.5 shipped with a computer_20250124 tool definition and an OSWorld score of 61.4%, up from Sonnet 4’s 42.2% just four months earlier. That 19-point jump was achieved with no harness-layer changes. The model itself got better at grounding actions in screenshots, planning over multi-step horizons, and recovering from intermediate failures. OpenAI’s o3-based computer-use-preview — exposed in the Responses API at $3/$12 per million tokens, scored 87% on WebVoyager out of the box. Google’s Project Mariner added Teach & Repeat as a primitive: learn a workflow once, replay it deterministically. That is what Stagehand v3 caching, Anchor’s b0.dev, and Skyvern’s workflow recording are. The foundation lab built it into the browser extension directly.

By Q1 2026, the most architecturally interesting open-source release in the harness space was a deliberate stripping-away of abstractions: browser-use’s Browser Harness, at roughly 600 lines of code. The team published their reasoning in The Bitter Lesson of Agent Harnesses, the argument that every layer of wrapping is a constraint on a model that was already pretrained on millions of CDP tokens. Strip the wrapper away. Expose the substrate. Let the model build the abstractions it needs at runtime, in code, on disk, in a persistent workspace it can read and write.

Twelve months. Three distinct topologies converged to the same conclusion: less wrapping is better.

What the thin-CDP harness actually does

Browser Harness is short enough to read in an afternoon, but the architectural decisions inside it are doing a lot of work. The system has three components: a daemon that holds the CDP websocket open, an admin layer that surfaces helpers in agent-workspace/agent_helpers.py, and a persistent workspace under agent-workspace/domain-skills/<domain>/ where the agent’s authored functions accumulate over time.

The runtime loop is unusual. When the agent encounters a missing capability, drag-and-drop, file upload, dialog handling, iframe traversal, it does not call a pre-built helper from a framework. It reads the existing helpers, identifies the pattern, writes a new function following the same conventions, and immediately uses it. The helper persists across the session and, on subsequent runs against the same domain, becomes part of the working surface the agent inherits.

This is not new code-generation. It is a structural argument: the abstractions worth having are the ones the model can author and maintain at runtime against the specific surfaces it encounters, not the ones a framework author tried to anticipate in advance.

Three properties make the pattern non-trivial.

The workspace is a filesystem, not a vector store. The agent reads other helpers as raw source code, with comments and patterns intact. The model’s pretraining included hundreds of millions of source files; reading source code is what it does best. A vector-indexed memory layer would optimize the wrong dimension, semantic retrieval over symbol-level inspection.

Helpers persist as domain skills, not session state. A successful flow against availity.com writes to agent-workspace/domain-skills/availity.com/. The next session against the same domain inherits the accumulated helpers. Over time, the workspace converges toward a working library for the surfaces the team automates, which is exactly what a hand-written Playwright codebase converges toward, except the model authored it.

The daemon exposes CDP directly, not Playwright. Every layer of intermediation is a layer the model has to learn around. The model already knows CDP from pretraining. Adding Playwright between the model and CDP is adding human-curated semantic interpretation over a substrate the model can reason about natively. Sutton’s lesson applied to API surface area.

What this means for Stagehand, browser-use, Skyvern, Libretto

The honest read is that none of the major harness frameworks are dead, and none of them are durable in their current form.

Stagehand v3 is the strongest counter-argument to the thin-CDP thesis. Browserbase’s response to the commoditization risk was to rebuild Stagehand on top of CDP directly (dropping Playwright as a hard dependency), make the LLM provider swappable through a Model Gateway, and ship aggressive caching at the SDK and server layers. The architecture is no longer “wrap Playwright with NL primitives.” It is “wrap CDP with NL primitives, cache the resolutions, fall back to LLM on cache miss.” That is meaningfully closer to the thin-CDP position than to the v2 architecture. The remaining commoditization risk for Stagehand sits in the act, extract, and observe primitives themselves, if Sonnet 4.5 or its successor can ground an action in a screenshot reliably, the NL layer becomes optional. Browserbase’s bet is that caching plus Browserbase Cloud’s infrastructure makes the package durable even if the SDK layer alone is not.

Browser Use has clearly read the bitter lesson and is hedging across both positions. The original Agent.run(task=...) Python SDK is still the public-facing surface. But the same company shipped Browser Harness as a separate repo specifically to articulate the thin-CDP argument. The bu-ultra hosted model (89.1% on WebVoyager) is the bet that full-stack optimization, own browser infrastructure, own stealth, own CAPTCHA solving, own filesystem, own tool orchestration, is the durable moat even as the SDK abstraction commoditizes.

Skyvern is the most exposed. The planner-validator multi-agent architecture that took Skyvern from 45% to 85.8% on WebVoyager is exactly the kind of carefully-engineered domain abstraction that the bitter lesson predicts will be out-competed by general methods. The 19-point Sonnet 4.5 jump on OSWorld in four months is the relevant trajectory. Skyvern’s Web Bench publication, 5,750 tasks across 452 live sites, is a smart move precisely because it shifts the comparison to harder benchmarks where the multi-agent topology still matters. But the underlying compute-vs-abstraction trade is not going to reverse.

Libretto is in an interesting position because it has chosen the topology least exposed to the bitter lesson. Code-first deterministic generation is not an abstraction over the model. It is an abstraction over the output. The model still authors the code, but the runtime is deterministic Playwright with version-controlled selectors and auditable behavior. As the model gets better at authoring code, Libretto’s value increases rather than decreases. The trade-off is the topology’s narrower applicability: regulated industries, bounded counterparty lists, audit-trail-critical workflows.

The two surviving patterns

If the bitter lesson is even directionally right, two harness patterns survive the next eighteen months and a third does not.

Pattern one: the model authors deterministic code, the harness runs the code. Libretto’s pattern. The model is in the loop at build time and at repair time. At runtime, no model inference happens. Selectors are committed, version-controlled, and auditable. As foundation-model code-generation improves, the harness gets more powerful without the harness needing to change. The risk is narrow applicability: this pattern only works where determinism is more valuable than flexibility, which is true for regulated industries but not for the long tail of consumer and exploratory workloads.

Pattern two: the harness is a thin substrate access layer, the model authors abstractions at runtime. Browser Harness’s pattern. The substrate is CDP, the workspace is a filesystem, the abstractions are agent-authored helpers that persist as domain skills. As foundation-model capability grows, the harness’s surface area shrinks rather than expanding. The risk is build cost on the first run against a new surface and the absence of guardrails for teams that need them.

Pattern three: wrap the model with NL primitives and ship them as the durable interface, is the one the bitter lesson predicts will not survive in its current form. Stagehand’s response is to push the abstraction down to CDP and ship caching plus infrastructure as the moat. Skyvern’s response is to push to harder benchmarks where the multi-agent topology still matters. Browser Use’s response is to hedge across both positions simultaneously. None of these are wrong responses. But they are responses to a structural problem that the SDK layer was not architected for.

What this means for the next eighteen months

The implications, in order of confidence.

The harness layer is not going to disappear. State, replay, auth, observability, anti-bot, and concurrency are not problems that the model solves. They are problems the system around the model solves. The infrastructure layer of this market - Browserbase, Steel, Anchor, Hyperbrowser, Bright Data, Apify, has structural durability that the SDK layer does not.

The SDK layer is becoming a customer-acquisition channel for the infrastructure layer. Stagehand exists primarily to feed Browserbase. Browser Harness exists primarily to feed browser-use Cloud. Skyvern OSS exists primarily to feed Skyvern Cloud. Pure-OSS SDK companies will have a hard time monetizing without a coupled paid backend, and the SDK abstractions themselves are not the durable IP.

Regulated industries are a safe harbor. The thin-CDP pattern is not a fit for healthcare, banking, insurance, or legal because the audit-trail problem is not solved by “the model authored a helper at runtime.” Libretto’s code-first pattern is durable in these verticals specifically because the bitter lesson does not apply where determinism is the requirement.

The agent-authored skill pattern is going to spread beyond browsers. The idea that the model writes domain-specific helpers that persist as a skill, and that subsequent sessions inherit those helpers, generalizes to any opaque surface - desktop applications driven by computer-use, internal portals, RPA targets, vendor consoles. Browser Harness’s agent-workspace/domain-skills/<domain>/ directory layout is the prototype of a pattern that other surfaces will copy.

The interesting axis of competition is shifting. Cache validation strategies, fallback model selection, recovery primitives, and credential-handoff protocols are where the differentiation lives now. The topology argument, code-first vs NL-DSL vs vision-CUA vs thin-CDP is going to look quaint by mid-2027.

The contrarian read

There is a respectable counter-argument worth naming. The bitter lesson is an empirical observation, not a theorem. It has been wrong before, in specific cases, for sustained periods.

The strongest counter to the thin-CDP thesis is that browsers are not chess positions. The substrate is adversarial. Sites change weekly. Bot detection runs ML on mouse curves and timing. CAPTCHAs evolve. The infrastructure around the model - proxies, fingerprinting, residential IP rotation, CAPTCHA solving, is genuinely hard to reduce to “more compute against a general method.” The harness has to absorb that complexity somewhere, and the SDK layer is one defensible place to put it.

The second counter is that audit trails and reproducibility are first-class requirements in production. A workflow that runs differently each time because the model authored its helpers differently is not deployable in any regulated context, and is hard to debug even in unregulated ones. Determinism is a feature, not a constraint. The patterns that survive may be the ones that preserve determinism most aggressively, not the ones that strip the most wrapping away.

The third counter is the time horizon. Sutton’s lesson is a decade-scale observation. The current foundation-lab trajectory might continue for eighteen months and then stall - at which point the harness abstractions that look quaint today look essential again. Markets are not always efficient at pricing in long-term technical curves.

These counters are real. The architecturally honest position is to take the bitter lesson seriously without committing to a single topology. Build the deterministic skeleton in code-first or NL-DSL. Cache aggressively. Fall back to thin-CDP for the long tail. Plan for the SDK abstractions to commoditize without betting that they will.

The architectural ask

For an engineering team building or rebuilding a browser harness in 2026, the most useful framing is not which topology to commit to. It is which abstractions to expose to the model versus which to handle below the model.

The abstractions that should sit below the model - substrate access, CDP, network handling, anti-bot, proxies, session lifecycle, observability - are not commoditizing. The infrastructure problem is genuinely hard and getting harder.

The abstractions that should sit above the model - high-level intent, business logic, workflow orchestration, validation, are application-layer concerns and have always been the team’s responsibility.

The abstractions that sit at the same layer as the model - NL-DSL primitives, planner-validator multi-agent topologies, hand-curated tool definitions — are the ones the bitter lesson predicts will commoditize. These are the load-bearing abstractions in Stagehand, Browser Use, and Skyvern. They are also the ones the foundation labs are absorbing fastest.

The pragmatic move is to ensure that the team’s harness investment is structured so that commoditization at the same-layer-as-the-model abstractions does not invalidate the below-the-model infrastructure investment or the above-the-model application logic. Hybrid topologies, aggressive caching, replay primitives, and decoupled provider gateways are the architectural patterns that survive that commoditization without rebuilding from scratch.

Share

Primary sources: Sutton, “The Bitter Lesson” (2019), browser-use Bitter Lesson of Agent Harnesses, Browser Harness repo, Stagehand v3 launch post, Anthropic Claude Sonnet 4.5 announcement, OpenAI Computer-Using Agent, Skyvern 2.0 and Web Bench, Libretto repo.