Architecture — The Third-Generation AI Harness Reference Architecture

1. Reading Guide and Positioning

1.1. The Three Questions This Chapter Answers

This chapter is one of the two with the heaviest technical weight in the white paper; it connects with Chapter 2 (Concepts and Development History) and answers three questions:

1. What a third-generation (runtime- and evaluation-centric) Harness actually looks like — which components make up each layer, and what contracts link the layers to one another;
2. Why each layer has its current shape — what failures it has to overcome, and what price was paid for that;
3. How an organization can judge what level its own Harness is at — providing a self-assessment tool that judges each layer against a five-level maturity scale.

For the timeline and background of the three-generation evolution, see Chapter 2; for the forms in which the six-layer model lands in each industry, see Chapter 4 (Practice).

1.2. Terminology and Baseline Conventions

• AI Harness (AI riding layer / agent runtime framework): the engineered carrying layer between the foundation model and real business systems, which turns the model's uncertainty into engineering predictability. The definition is unified throughout and must not be rewritten.
• Six-layer capability model: L1 Context Engineering Layer, L2 Tooling and Execution Layer, L3 Orchestration and Control Layer, L4 Memory and State Layer, L5 Evaluation and Observability Layer, L6 Governance and Safety Layer.
• Three-generation evolution: the prompt engineering era (2020—2023) → the tooling and orchestration era (2023—2025) → the runtime and evaluation era (2025—present).
• Distinguishing fact from judgment: every engineering parameter cited in this chapter is labeled with a source tier; conclusions derived by this project are explicitly marked "this document's judgment". Numbers from Tier-B/C sources are uniformly flagged as unverified and serve only as directional reference.
• Source tiers: Tier A is vendor or official primary; Tier B is authoritative secondary; Tier C is community paraphrase (numbers unverified and not quoted).

2. Overview of the Third-Generation Reference Architecture

2.1. The Basis for Layering: Layers Defined by Failures

The six-layer model is not an a priori functional division, but rather each layer corresponds to a class of independently emergent bottleneck. When a long-cycle agent task fails, the engineer's attribution almost always falls into one of the following six categories:

Layers are defined by failures, not by feature lists. (this document's judgment) This is the practical criterion for judging which layer a new component should belong to.

2.2. Overall Architecture Diagram

图 2-1｜第三代架构总览：六层分层设计

┌──────────────────────────────────────────────────────────────────┐
│  L6  治理与安全层    Governance & Safety                          │
│      权限 · 沙箱策略 · 凭据保护 · 机械强制 · 熵治理 · 预算护栏    │
│      （横向切面，对 L1~L5 全部施加约束并记录审计）                │
└──────────────────────────────────────────────────────────────────┘
   ▲               ▲               ▲               ▲
   │ 约束           │ 约束           │ 约束           │ 审计
┌──┴────────┐  ┌───┴────────┐  ┌───┴─────────┐  ┌──┴──────────┐
│ L1 上下文  │─►│ L2 工具与   │─►│ L3 编排与    │─►│ L5 评估与    │
│ 工程层     │  │ 执行层      │  │ 控制层       │  │ 观测层       │
│ 看到什么   │  │ 能做什么    │  │ 按什么顺序做 │  │ 做得好不好   │
└───────────┘  └────────────┘  └─────────────┘  └─────────────┘
        ▲                              │                   │
        │  反馈：改变下次看到什么       │                   │
        └──────────────────────────────┴───────────────────┘
        ▲
   ┌────┴───────────────────────────────────────────┐
   │  L4  记忆与状态层   Memory & State              │
   │       会话态 · 长期记忆 · 检查点 · 工件         │
   │       （时间维度的横向支撑层）                  │
   └────────────────────────────────────────────────┘

It should be emphasized that the feedback edge between L5 and L1 in the diagram is the structural difference between the third and second generations: in the second generation evaluation is bolted on (run a benchmark once, glance at the score), while in the third generation the output of evaluation flows back to change the next round of context assembly, forming a closed loop.

2.3. Six-Layer Responsibility Master Table

3. The L1 Context Engineering Layer

3.1. Responsibility and Problem Statement

The question L1 answers is: before this step of reasoning, which tokens should the model see. It is the only layer in the entire Harness that acts directly on the model's input interface.

The official definition given by Anthropic in "Effective context engineering for AI agents" (2025, Tier A) is: during LLM inference, the full set of strategies for curating and maintaining that optimal set of Tokens (information). The definition given by Andrej Karpathy on 2025-06-25 is the most widely cited:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

The two official theoretical foundations of this layer are:

This yields a counterintuitive but repeatedly verified conclusion (this document's judgment): cramming more information into the context is usually a negative optimization. The priority of building L1 is not "retrieve more" but "delete more".

3.2. Key Components

Besides Anthropic's official four-way split, another widely used industry taxonomy is the LangChain four pillars (Write / Select / Compress / Isolate, Tier B), which maps onto the official strategies: the first three correspond to compaction, notes, and retrieval; the sub-agent corresponds to Isolate.

3.3. Representative Implementations

3.4. Design Trade-offs

3.5. Typical Failure Modes

Quantitative supplement (Tier C): 2025 research found that "semantically consistent but irrelevant data can degrade performance by more than 45%"; Chroma Research tested 18 frontier models in 2025-07, and every one degraded as the context grew.

4. The L2 Tooling and Execution Layer

4.1. Responsibility and Component Composition

The question L2 answers is: what actions the model can apply to the environment, and where those actions execute. Three classes of components:

Tool design guidelines (Anthropic, Tier A): self-contained, robust to errors, extremely clear in purpose; avoid feature overload and ambiguous decision points; few-shot examples should be "diverse and typical". Echoing this is the "right altitude" principle for system prompts: specific enough to effectively guide behavior, yet flexible enough to leave the model room for judgment.

4.2. MCP: The Connection Standard and Its Evolution

MCP adopts a Host / Client / Server three-role architecture (Tier A): the Host is the top-level application, containing Clients; each Client maintains a 1:1 connection with a Server; the Server exposes Tools / Resources / Prompts. Transport: local stdio, remote Streamable HTTP, messages based on JSON-RPC 2.0.

The five-version specification evolution chain (MCP official protocol versions page, etc., Tier A):

Google's official division of labor between MCP and A2A ("A year of open collaboration", 2026-04-16, Tier A): MCP manages internal tool integration, A2A manages external coordination between agents. The two are connection protocols in different directions, not a competitive relationship.

From the evolution chain, three orientations can be read (this document's judgment): from stateful sessions to stateless requests; from "good enough" to "evolvable"; from "tools only" to "agents on the server side too".

4.3. Sandbox: The Engineering Implementation of the Side-Effect Boundary

The Claude Code sandbox is the most completely publicly disclosed Agent sandbox design to date (Tier A).

Core security axiom: filesystem isolation and network isolation are both indispensable — without network isolation, a compromised agent can exfiltrate SSH keys; without filesystem isolation, a compromised agent can escape easily and obtain network access.

Quantified effect (Tier A, the most core number in this layer): Anthropic's internal use found that sandboxing safely reduced permission prompts by 84%.

Horizontal comparison (Codex CLI, Tier B, specific parameters flagged as unverified): macOS uses sandbox-exec (Seatbelt), Linux uses Landlock + seccomp, Windows uses job objects; network disabled by default; approval tiers are Suggest / Auto-edit / Full-auto. In 2026-04 an Auto-review mode was added; internal sessions stopping for human approval occur at about 1/200 the rate of the manual mode, with a review approval rate of about 99%.

4.4. Design Trade-offs and Failure Modes

Typical failure modes: overlapping tool semantics cause random choice that is not reproducible; frequent use of dangerouslyDisableSandbox makes isolation a mere formality; child processes inheriting credential environment variables cause leaks; uncontrolled network egress exfiltrates data; an inflated tool count causes a double loss in accuracy and cost. The corresponding countermeasures: a "pairwise distinguishability" check in tool review, closing the escape hatch (Strict sandbox mode), explicit deny / mask for credentials, a mandatory proxy with an egress whitelist, and regular tool subtraction.

5. The L3 Orchestration and Control Layer

5.1. Responsibility and Orchestration Forms

The question L3 answers is: in what order to act, who does what, and how to recover after an interruption.

5.2. Two Generations of Official Solutions for Long-Running

First-generation official solution (Anthropic "Effective harnesses for long-running agents", Tier A): the Initializer Agent + Coding Agent dual-Agent division of labor. The Initializer produces the handoff package: init.sh (one-command environment startup), claude-progress.txt (progress file), the initial git commit (rollback base point), and a JSON feature list (the master task ledger with a passes field). The Coding Agent's three opening steps are fixed: pwd to confirm the directory → read the git log and progress file → read the feature list and select the highest-priority unfinished item. Two hard rules: removing or modifying tests is unacceptable; the session must end with the environment left in a mergeable clean state.

Second-generation official solution (Anthropic "Harness design for long-running application development", 2026, Tier A): the Planner / Generator / Evaluator three-role division of labor (design inspiration from GANs). The Planner turns 1~4 high-level prompt sentences into a complete product specification, deliberately staying high-level; the Generator implements one feature per sprint; the Evaluator scores four items — product depth, functionality, visual design, code quality — each with a hard threshold; if any falls below its threshold the iteration fails. Three key mechanisms:

1. Sprint Contract: before coding, reach consensus on "what to build + how to verify success" — agree on the definition of "done" before starting; this is the most important process design in this layer.
2. self-evaluation bias (self-praise): agent self-evaluation will "confidently praise" clearly mediocre work; this is the fundamental reason for separating the Evaluator.
3. context anxiety: when an agent's context approaches its limit, it tends to wrap up hastily and declare completion early.

Open question (officially acknowledged, Tier A): whether a single general-purpose coding agent is always optimal, or a multi-agent architecture split into specialized agents is better — this is currently unclear.

A third route: the managed runtime (supplemented in the 2026-09-12 snapshot; evidence tier upgraded in the 2026-09-13 snapshot). Both generations of solutions above are the self-built Harness methodology given by Anthropic — the team builds its own orchestration, manages its own state, and designs its own evaluation. In 2026 a third route emerged alongside them: the vendor manages the runtime itself. The two citable milestones are AWS Bedrock AgentCore reaching GA in 2026-06, and the OpenAI Agents API entering public beta on 2026-09-10 (Tier A — recorded in the OpenAI official Changelog, verified in the 2026-09-13 snapshot; the previous snapshot, following media reports, had recorded it as 09-11, now corrected; see 08-Development Outlook §4.3 and the research library 03-Market Research/02-AI-Agents Group/21-openai-agents-api.md for details). Its form is packaging L3 orchestration, L4 state persistence, and L5 tracing and observability as server-side capabilities; callers no longer build their own loop, and only submit tasks and toolsets.

The trade-offs among the three routes reduce to one trade-off:

Judgment: the managed runtime does not replace the self-built Harness, but moves the necessity of "self-building" upward — what it absorbs is the general orchestration and state persistence part of the non-differentiated capability, while the bottlenecks that recur throughout the 04-Practice chapter (industry criteria, evaluation sets, governance red lines) still cannot be managed and still require self-building. This is consistent with the white paper's core judgment that "the Harness is an independent engineering layer": precisely because it is an independent layer, it can be managed by a vendor, and self-built constraints can continue to be layered on top of the managed service.

5.3. Design Trade-offs and Failure Modes

Typical failure modes and countermeasures: infinite loop → iteration cap + anti-drift detection; goal drift → Sprint Contract + periodic re-injection of the original goal; early completion declaration → forced checklist-style self-verification; dirty environment state → return to a mergeable clean state before ending; tests modified to pass → declare "removing or modifying tests" unacceptable.

6. The L4 Memory and State Layer

6.1. Responsibility and Problem Statement

The question L4 answers is: how state is handed off across sessions and across context windows. Anthropic's official statement of this challenge is highly evocative (Tier A):

Imagine a software project staffed by engineers working shifts, where every new engineer, on arriving for their shift, has no memory of what happened on the previous shift.

This statement also explains why L4 only became an independent concern in the third generation: first- and second-generation task durations still fit within a single context window, so the problem simply does not arise.

6.2. Key Mechanisms

The official scheme for cross-window state handoff (Tier A):

Two accompanying disciplines: before starting to implement a new feature, an end-to-end health check must be run first (the rationale being that the model "tends to declare a feature complete without adequate testing"); equip the agent with browser automation tools (such as Playwright MCP) for human-level verification — officials explicitly state this significantly improved performance.

The division of labor between Compaction and Context Reset (Tier A): Compaction summarizes in place, preserving continuity, but "context anxiety" remains; Context Reset clears and re-injects, giving a clean whiteboard, but the handoff artifacts must be sufficiently complete. The relationship between the two can be summarized as (this document's judgment): Compaction is symptomatic treatment (slowing decay); Reset is radical treatment (complete debridement), but Reset's cost is transferred to the quality of the handoff in the L4 layer.

Git as the state carrier: a distinctive feature of the third generation is treating Git as the carrier of state and memory, rather than starting a separate memory database — the benefit is inheriting the entire toolkit already used by human engineering teams (diff, blame, revert, CI); the cost is needing extra conventions on commit granularity and branching strategy.

6.3. Design Trade-offs and Failure Modes

Typical failure modes and countermeasures: amnesiac restart → force the three opening steps; progress file decay → treat git history as the single source of truth, the progress file only summarizes; dirty handoff → wrap up in a clean state + an opening health pre-check; checkpoint granularity out of control → explicitly agree on commit granularity and branching strategy.

7. The L5 Evaluation and Observability Layer

7.1. Responsibility and First Principle

The question L5 answers is: how well it was done, how to judge it, how to regress-test it. This layer received the highest status elevation in the third generation; the reason can be summarized in one official judgment (Anthropic, Tier A):

"Harness design is key to performance at the frontier of agentic coding."

First principle: separate the evaluator from the evaluated. Official observation (Tier A): when an agent evaluates its own work, it will "confidently praise" it — even when human observers clearly see mediocre quality. The rationale given officially is:

Training an independent Evaluator to be skeptical is far easier than making the Generator self-critical. (Inspired by GAN)

Implementation: the Evaluator sets hard thresholds separately for four dimensions; if any falls below its threshold the iteration fails, and the detailed failure reasons are fed back to the Generator. This principle also holds for non-coding scenarios (this document's judgment): for any subjective-quality agent task, one should set up a judge isolated from the generator, whether it is a rule, a script, or another model.

7.2. External Benchmarks and the Built-in Closed Loop

The two components of L5 are mutually irreplaceable:

External benchmarks prevent self-congratulation (your own eval all green yet no competitiveness); the built-in closed loop prevents regression (external benchmarks can only be run a few times a year and cannot cover private business). SWE-bench (2023-10-10, 2,294 task instances, 12 Python open-source repositories, ICLR 2024 Oral, Tier A) established the principle of programmatic scoring: pass the tests to pass. Terminal-Bench's principle is likewise "either the automated tests pass or they do not".

Open observability to the agent is a highly inspiring practice given by OpenAI in "Harness engineering" (2026-02-11, Tier A): applications can be started independently per git worktree; the browser debugging protocol (Chrome DevTools Protocol) is wired into the agent runtime; metrics and logs are exposed via the local observability stack, and the agent can query directly with LogQL and PromQL; performance requirements are written as measurable acceptance conditions (example: "ensure the service starts within 800ms"). Its engineering significance is: feed L5's observability capability back to L1 as context — the agent is no longer a blind-writing black box.

7.3. Quantitative Evidence of Harness Differences

The evidence that best demonstrates the value of L5 is the quantification of the phenomenon "same model, different Harness, different score". Terminal-Bench (Stanford + Laude Institute, released 2025, Tier-A project) states directly in its methodology:

"Terminal-Bench does not score a model in isolation. Every result is a model plus an agent harness... the leaderboard is a ranking of systems, not of models."

The following comparison data all come from Tier-B/C sources and are uniformly flagged as unverified, serving only as directional reference:

The five-item change list behind LangChain's "52.8% → 66.5%" (Tier C, unverified numbers, but the changes themselves have engineering reference value) all involve no model swap:

1. Force checklist-style self-verification before allowing "done" to be said;
2. Scan the directory structure before startup and inject environment context;
3. Anti-drift detection — warn when repeatedly editing the same file;
4. Adjust the reasoning budget — think more for planning and verification, less for implementation;
5. Automated failure-mode analysis.

7.4. Design Trade-offs and Failure Modes

Typical failure modes and countermeasures: self-praise → separate the evaluator from the evaluated; evaluation set overfitting → rotate evaluation sets periodically, keep a held-out set; only looking at end-state scores → trajectory-level tracing; metrics disconnected from business → build your own Golden Dataset rather than only chasing public leaderboards.

8. The L6 Governance and Safety Layer

8.1. Responsibility and Governance Philosophy

The question L6 answers is: what must not be done, how to discover it if done, and what is the spending ceiling. It contains four categories of components — permission model (RBAC), guardrail models, audit logs, and budget guardrails — and acts as a cross-cutting aspect applying constraints to all of L1~L5.

A common misconception that must be clarified is "governance slows things down". Anthropic's sandbox evidence gives the opposite conclusion — permission prompts reduced by 84% with improved safety (Tier A). Constraints are not the opposite of autonomy; they are the precondition of autonomy.

8.2. Key Mechanisms

Layered permission configuration (taking Claude Code as an example, Tier A): project level .claude/settings.local.json distributed with the repository; user level ~/.claude/settings.json carrying personal preferences; organization level managed settings mandatorily pushed down, individuals cannot override. Among these, sandbox.failIfUnavailable can be set to hard failure — if the sandbox cannot start, refuse to run, rather than quietly degrading. This is an important lesson in governance robustness (this document's judgment): do not give safety mechanisms a silent degradation path.

Mechanical enforcement of architectural constraints (OpenAI, Tier A): the layered dependency rule is mechanically enforced rather than relying on verbal code review conventions —

Types  →  Config  →  Repo  →  Service  →  Runtime  →  UI

Cross-cutting concerns can only enter through the single Providers interface. Taste Invariants are statically enforced via a self-built linter — structured logging, schema and type naming conventions, file size limits. The most critical engineering trick is: the linter's error messages are written as repair instructions injected into the agent context — the linter does not just "report an error" but "reports an error + teaches the agent how to fix it". This directly converts L6's failure signal into L1's context input, forming a closed loop. Official summary:

In human-first workflows, these rules may feel pedantic; with agents, they become multipliers — once codified, they take effect everywhere immediately.

Garbage collection: countering entropy growth (OpenAI, Tier A): the doc-gardening agent periodically scans outdated documentation and automatically initiates repair PRs. The four major failure modes summarized officially: context is a scarce resource; too much guidance becomes no guidance (when AGENTS.md is written too long, the agent skips reading it, just like a human); documentation rots immediately; hard to verify mechanically.

8.3. Design Trade-offs and Failure Modes

Typical failure modes and countermeasures: permission fatigue → sandboxing + Auto-allow (−84% prompts); documentation decay → doc-gardening agent + bring documentation into CI validation; rules not machine-checkable → self-built linter, error messages written as repair instructions; audit not traceable → full-layer tracing + structured logs; budget out of control → Budget Guardrail + per-step / per-task cost caps.

9. Harness Loop: Converging Model Uncertainty into Controllable Iteration

The previous eight chapters took the six layers apart layer by layer; this chapter returns to the axis that strings them together — the main loop. One sentence to distinguish the two perspectives: the six-layer model answers "what the Harness consists of", while the Harness Loop answers "what the Harness is doing every second".

9.1. Why the Loop is the First Citizen of the Harness

For the judgment "the Loop is the first citizen of the Harness", there are three sets of mutually independent evidence (this document's judgment; evidence all labeled with source tiers):

First, official naming evidence. Anthropic's "Loop engineering: Getting started with loops" (2026-06-30, Tier A) takes the "loop" as its core proposition, with the official definition "loop = the agent repeatedly executes work cycles until the stop condition is met"; the Claude Agent SDK official documentation has a dedicated chapter "How the agent loop works" (Tier A); OpenAI directly equates the agent loop with the core of the harness — "the reusable part is the agent loop" ("Codex as a platform", Tier A). The two leading vendors, in unison, take the loop — not the model — as the center of their product and documentation narratives.

Second, evaluation-variable evidence. OpenAI officially disclosed (Tier A, information as of 2026-09-12): on the ARC-AGI-3 benchmark, retained reasoning + context compression raised GPT-5.6 Sol's score from 13.3% to 38.3%, while reducing output tokens by 6×. Same model, only the loop mechanism changed, a 25-percentage-point improvement — this mutually corroborates section 7.3's Terminal-Bench "the leaderboard ranks systems, not models": loop design is a performance variable independent of the model.

Third, failure-mode evidence. The long-task failure modes named officially by Anthropic — doing too much at once (one-shot) and premature completion declaration (premature completion) — are both loop-level failures: not that some step was done wrong, but that the loop's boundary was designed wrong (Tier A). The $47,000 multi-agent ping-pong loss-of-control incident circulating in the industry (Tier B, verified: partial, multiple posts consistent but no named victim company) shows the cost consequences of an unbounded loop; industry practice estimates an out-of-control loop's cost can reach 30× a normal task (Tier C).

The conclusion of combining the three sets of evidence is (this document's judgment): the model's uncertainty comes from the single call; the loop turns the single call into an observable, verifiable, terminable iteration unit — convergence does not happen inside the model, it happens inside the loop.

9.2. Loop × Six-Layer Model Comparison

The Harness Loop is not a "seventh layer" beyond the six layers, but the unfolding of the six layers along the time dimension. The unified comparison is as follows:

The correspondence is shown in Figure 9-1.

图 9-1｜Harness Loop × 六层模型对照

示意图：基于本文分析，对照口径沿用本库参数卡统一六层模型（信息截止 2026-09-12）。

9.3. Termination Conditions and the Governance Boundary: Writing L6 into the Loop

"When does the loop stop" is not an implementation detail but the core contract between the Harness and its users. The unified criterion divides termination conditions into five tiers:

The key action of third-generation governance is rewriting L6 from "the approver outside the loop" into "every turn inside the loop" (this document's judgment): hooks interception happens before tool execution, inside the loop (Tier A); approval tiers (untrusted / on-request / never) and sandbox tiers (read-only / workspace-write / danger-full-access) combine orthogonally, defining the feasible domain of each turn (Tier A); Auto-review automatically approves sub-agent actions according to the planned action and recent context, passing low-risk operations and halting high-risk ones (Tier A); in OpenAI's self-deployment practice, OTel telemetry exports every turn's prompt, approval decisions, tool results, and network events to SIEM (Tier A).

The official attitude toward budgets is worth quoting directly (Tier A): "a budget cap is a good default for production agents." The semantics of exceeding limits are also nuanced: LangGraph's recursion_limit is positioned by the official forum as "a circuit breaker rather than business logic"; exceeding it is "a recoverable pause" rather than death — with the Checkpointer it can continue from the last persisted state (Tier B); industry practice recommends returning partial results (a progress summary) rather than a bare error when exceeded (Tier C).

9.4. The Framework Loop Semantics Spectrum

Each framework's loop semantics falls on a spectrum: one end is structural bounded loops ("structure decides when to stop"), the other end is model-autonomous loops + governance as backstop ("the model decides when to stop").

• Structurally bounded: Dify's Iteration node traverses an array, materializing an independent sub-engine per element; parallelism defaults to 10, per-node maximum iteration defaults to 100; n8n / Coze visual loop nodes belong to the same pattern — iteration must be bounded by array length rather than an LLM stopping condition (Tier B; n8n / Coze official first-hand loop documentation was not directly obtained; see section 15's gap statement).
• Conditionally bounded: Dify's Loop node consists of loop_count + break_conditions + loop_variables inherited across rounds; MAF Workflow requires a loop to have at least one conditional exit edge + a max_turns backstop (Tier B). AutoGen GroupChat has unpredictable loops due to LLM speaker selection and can loop infinitely when termination conditions are ambiguous — this is the direct driver of the "implicit message loop → explicit typed graph" evolution (Tier B).
• Model-autonomous + backstop: LangGraph conditional edge to END + recursion_limit circuit breaker + Checkpointer recoverable (Tier B); the OpenAI Agents SDK's final_output + max_turns + guardrail tripwire (Tier A); the Codex harness's assistant message + approval gate (Tier A); Claude Code's response without tool invocations + budget / hooks (Tier A).

The spectrum distribution is shown in Figure 9-2.

图 9-2｜框架循环语义光谱

示意图：基于本文分析（信息截止 2026-09-12）。

9.5. Enterprise Deployment Recommendations

Building the Loop as a first citizen means that budget, telemetry, and human intervention should all be designed around the "turn", not around a single API call. Three main lines:

The common logic of the three main lines is consistent with the opening of this chapter: the uncertainty of a single call cannot be eliminated, but every turn can be assembled, observed, constrained, and terminated. The loop budget turns "loss of control" into "predictable stop-loss"; telemetry turns "black-box iteration" into "attributable trajectories"; the HITL gate turns "human approval" from a bottleneck outside the loop into a flexible gate inside the loop.

For the relationship between the Loop and inter-layer contracts (the data-flow conventions when crossing layers each turn), see Chapter 10.

10. Inter-Layer Contracts and Data Flow

10.1. The Main Execution Chain and Two Lateral Supports

The main execution chain is L1 → L2 → L3: first decide what to see, then decide what can be done, and finally decide in what order to do it. The lateral supports are L4 (time dimension: state across sessions and windows) and L6 (constraint dimension: permissions, budget, audit). The closed loop is L5 → L1: the output of evaluation and observability flows back, changing the next round of context assembly.

10.2. Two Key Feedback Loops

The third-generation architecture contains two cross-layer closed loops already evidenced officially (this document's judgment; both supported by Tier-A evidence):

10.3. Inter-Layer Contract Checklist

11. Key Leaps from Second to Third Generation

11.1. The Six-Item Leap List

The sixth item is the philosophical core of the whole leap: human work moves up from "operating" to "designing environments, feedback loops, and control systems" (OpenAI original: "Our most difficult challenges now center on designing environments, feedback loops, and control systems.").

11.2. The Complete Paradigm Sample of the Leap

The most complete public evidence of the third-generation Harness is the internal experiment disclosed in OpenAI's "Harness engineering" (2026-02-11, Tier A); the following numbers are all first-hand:

A counterintuitive observation: throughput actually rose after the team expanded from 3 to 7 people — this contradicts the traditional software engineering intuition that "adding people worsens PR conflicts", indicating that this Harness's coordination overhead is lower than the output brought by the added headcount.

Six key engineering decisions and their belonging layers:

There is also one universal selection principle (this document's judgment, worth remembering separately): prefer "boring technology" (composability, API stability, widespread presence in training corpora). In systems where agents write code, the technology's "model familiarity" is a real selection metric, alongside performance and ecosystem.

11.3. The Parts of the Leap Not Yet Completed

The following problems are officially acknowledged as unresolved (Tier A):

1. The single-Agent vs multi-Agent debate is undecided — Anthropic explicitly states "currently unclear";
2. Cross-domain generalization unverified — whether coding-scenario experience can generalize to other long-cycle tasks such as scientific research or financial modeling; "the answer is still being explored";
3. The Harness itself lacks evaluation methods — the open question raised on martinfowler.com: we need Harness coverage and quality evaluation methods analogous to code coverage and mutation testing (not yet appeared);
4. Entropy governance still relies on patches — doc-gardening is a remedy for decay, not a root cure for decay.

12. Cross-Layer Cross-Cutting Concerns

The following four classes of concerns belong to no single layer; they are cross-cutting aspects that pierce all six layers. They are given a chapter of their own because, in engineering practice, the most common failure is not that some layer was not built well, but that a class of cross-cutting need was handled in one layer and overlooked in the others (this document's judgment).

12.1. Cost: From Token Billing to Task-Level Budgets

How cost constraints pierce the six layers:

12.2. Latency: From Response Speed to End-to-End Closed-Loop Duration

The meaning of latency in agent scenarios has changed: a single call being a few hundred milliseconds slower is usually unimportant; end-to-end closed-loop duration (from task initiation to verifiable completion) is the key metric (this document's judgment). Cross-cutting manifestations:

• L2: Sandbox startup and tool round-trips are constant latency terms; the latency savings of non-sandbox execution should not come at the cost of safety.
• L3: Long-running architectures redefine "latency" as "hour-scale" — the longest single task exceeds 6 hours (OpenAI, Tier A); interruption and recovery capability therefore become the true solution to the latency problem.
• L5: Performance requirements are written as measurable acceptance conditions ("ensure the service starts within 800ms", OpenAI, Tier A); latency becomes an object of L5 judgment rather than an experience problem.
• L1: The longer the context, the slower and more expensive the reasoning; compaction is simultaneously a latency optimization.

12.3. Observability: From Application Monitoring to Trajectory Replay

• Pervasive requirement: The full-process Trace of any task must be replayable — tool invocations, file changes, command output summaries, reasoning step indices. Failures without a Trace cannot be post-mortemed, equal to the team tuning parameters in the dark (this document's judgment).
• Forward supply: Observational data is open to the agent (LogQL / PromQL); the agent uses it to self-verify — observability becomes "a feedback source from L5 → L1" rather than "for humans to see".
• Cost attribution: The Trace is the foundation of cost and quality attribution; without a Trace, one cannot answer "did this change make things better or worse".
• L6 dependency: The countermeasure for audit not being traceable is full-layer tracing + structured logs (OpenAI lists structured logging as a mechanically enforced taste invariant).

12.4. Safety: From Single-Point Defense to Depth Piercing All Six Layers

13. Architecture Maturity Self-Assessment Table

13.1. Framework Notes and Five-Level Definitions

Important note: the table below is an analysis framework constructed independently by this project based on the aforementioned public materials, not a specification published by any standards organization, nor an official model from any vendor. Its value lies in providing an actionable yardstick to help organizations locate their own Harness capability and perform generational alignment. Please do not use it as a compliance basis or an industry benchmark.

13.2. Six-Layer × Five-Level Self-Assessment Table

13.3. Result Interpretation and Usage Recommendations

The item inter-layer gap ≥ 2 levels is especially important (this document's judgment): the Harness's overall output is limited by the weakest layer, not the strongest — this is consistent with the bucket effect in software systems. For example, a system whose L1 is only at level L1 (manually pasting context) but whose L2 reaches level L3 will often perform worse than a system where both are at level L2.

Usage recommendations: self-assess once every six months, using the results for longitudinal comparison rather than horizontal scores; give specific evidence layer by layer, do not write abstract "medium"; prioritize the weakest layer; be wary of "evaluation inflation" — when a layer is rated L3 but has no regression-testable evidence (e.g., no Golden Dataset), it should be downgraded back to L2.

14. Conclusion

The architecture of the third-generation Harness can be summarized in one sentence: it is a system that narrows the model's output distribution, through a six-layer structure, into the engineeringly acceptable interval.

• L1 decides what the model sees — the key bottleneck is the attention budget; the core means is deletion, not addition;
• L2 decides what the model can do — MCP solved the connection standard; the sandbox solved the side-effect boundary;
• L3 decides in what order to act — from a single loop to the division of labor among Planner / Generator / Evaluator;
• L4 decides what to remember — Git became the mainstream state carrier; cross-window handoff is the lifeline of long tasks;
• L5 decides how well it was done — the first principle is separating the evaluator from the evaluated;
• L6 decides what must not be done — governance is not the enemy of speed; official evidence is an 84% reduction in permission prompts.

What strings the six layers together is nine characters: visible, stable, regressable. The four classes of cross-cutting concerns — cost, latency, observability, and safety — pierce the six layers; any layer's omission will be made up in the other layers in the form of incidents.

For the differentiated landing of the six-layer model across industries — whose center of gravity is in L4, whose is in L5, whose ground truth is physical law — see Chapter 4 (Practice).

15. Information Gap Statement

This document involves the following information gaps; they have been flagged in the corresponding places in the body and are summarized here:

1. Section 3.5: context degradation "performance drop exceeding 45%" and Chroma Research "all 18 frontier models degraded" (Tier C).
2. Section 4.3: Codex CLI sandbox parameters, about 95% Rust code share, Auto-review's 1/200 and 99% (Tier B).
3. Section 4.4: Vercel's tool count 15 → 2 accuracy 80% → 100%, Token −37%, speed 3.5× (Tier C).
4. Section 5.3: the comparison experiment numbers for single Agent (20 minutes / $9 / unusable) versus three Agent (6 hours / $200 / complete and playable) (Tier C).
5. Section 7.3: Terminal-Bench leaderboard numbers (77.3% / 75.1% / 74.7% / 71.9%), LangChain 52.8% → 66.5%; the official site's (tbench.ai) current leaderboard was not directly scraped; all are third-party paraphrases.
6. Differing wording on MCP's initial version: two criteria coexist — 2024-11-05 (the Ruby SDK records it as Initial protocol revision) and 2024-11-25 (public announcement); this document takes 2024-11-05 as the initial version and presents the difference in parallel.
7. The exact URL and publication date of Anthropic's "How we built our multi-agent research system" are unverified.
8. The ISO/IEC-level agent interconnection international standard number: no authoritative information currently.

Newly added this round (Chapter 9, Harness Loop)

1. The specific publication dates of OpenAI official blog posts such as "Unrolling the Codex agent loop", "Unlocking the Codex harness", and "Codex as a platform" were not directly returned in the search results (Chapter 9).
2. The $47,000 multi-agent ping-pong loss-of-control case is verified: partial (multiple posts consistent, no named victim company); the body has phrased it as "a representative incident post-mortem circulating in the industry" (section 9.1).
3. The triple hard-limit empirical values and "an out-of-control loop's cost is about 30× a normal task" are an industry practice compilation (Tier C); directional reference only (section 9.5).
4. n8n / Coze loop nodes lack independent first-hand official documentation; only indirectly covered via the common bounded-loop pattern of visualization workflows (section 9.4).

16. References

1. Effective context engineering for AI agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
2. Effective harnesses for long-running agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
3. Harness design for long-running application development — Anthropic, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps
4. Harness engineering: leveraging Codex in an agent-first world — OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/
5. Sandboxing: a safer and more autonomous approach — Anthropic, 2025. https://www.anthropic.com/engineering/claude-code-sandboxing
6. Introducing the Model Context Protocol — Anthropic, 2024-11-25. https://www.anthropic.com/news/model-context-protocol
7. Model Context Protocol official specification (2026-07-28) — MCP / AAIF. https://modelcontextprotocol.io/specification/2026-07-28/
8. A year of open collaboration: Celebrating the anniversary of A2A — Google, 2026-04-16. https://opensource.googleblog.com/
9. Equipping agents for the real world with Agent Skills — Anthropic, 2025-10-16 (2025-12-18 open standard update). https://www.anthropic.com/news/skills
10. Agent Development Kit: Making it easy to build multi-agent applications — Google, 2025-04-09. https://googledevelopers.blogspot.com/en/agent-development-kit-easy-to-build-multi-agent-applications/
11. Harness engineering for coding agent users — Birgitta Böckeler, martinfowler.com, 2026. https://martinfowler.com/articles/harness-engineering.html
12. SWE-bench — Jimenez, Yang et al. (Princeton), 2023-10 (ICLR 2024 Oral). https://www.swebench.com/
13. Terminal-Bench — Stanford / Laude Institute, 2025. https://www.tbench.ai/
14. Linux Foundation Announces the Formation of the AAIF — Linux Foundation / AAIF, 2025-12-09. https://aaif.io/
15. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-29. https://survey.stackoverflow.co/2025/
16. How the agent loop works — Anthropic, 2026. https://docs.anthropic.com/en/docs/agent-sdk/agent-loop
17. Building agents with the Claude Agent SDK — Anthropic, 2025. https://claude.com/blog/building-agents-with-the-claude-agent-sdk
18. Loop engineering: Getting started with loops — Claude Code team, Anthropic, 2026-06-30. https://claude.com/blog/getting-started-with-loops
19. A harness for every task: dynamic workflows in Claude Code — Anthropic, 2026. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
20. Unrolling the Codex agent loop — OpenAI, 2025—2026 (publication date unverified, see section 15). https://openai.com/index/unrolling-the-codex-agent-loop/
21. Codex as a platform: build on the open agent harness — OpenAI Developers, 2026. https://developers.openai.com/blog/codex-as-a-platform
22. Running agents — OpenAI Agents SDK official documentation, 2026. https://openai.github.io/openai-agents-python/running_agents/
23. Running Codex safely at OpenAI — OpenAI, 2026. https://openai.com/index/running-codex-safely/
24. Agent approvals & security — Codex official documentation, 2026. https://developers.openai.com/codex/sandbox
25. gemini-cli (open-source repository and ReAct loop documentation) — Google, 2025—2026. https://github.com/google-gemini/gemini-cli
26. What does recursionLimit actually count in createAgent? — LangChain official forum, 2025—2026. https://forum.langchain.com/t/what-does-recursionlimit-actually-count-in-createagent-langchain-js/3460
27. Dify node system documentation (Iteration / Loop nodes) — LangGenius, 2026 (via DeepWiki structured index). https://deepwiki.com/langgenius/dify-docs/1.3-node-system-overview
28. Iteration Node — Agent Patterns Catalog, 2026. https://www.agentpatternscatalog.org/patterns/iteration-node
29. Runaway Tool Loops — PolicyLayer, 2026 (case occurred in 2025-11, verified: partial). https://policylayer.com/attacks/runaway-tool-loops