Harness-1 Architecture Framework

• Harness-1 Architecture is a modular template integrating layered verification, self-calibration, and persistent memory to ensure reliable AI-native software production.
• Its design features a seven-layer stack that coordinates calibration, contract compilation, and adversarial verification for continuous improvement.
• The framework supports agentic AI and reinforcement learning applications, enhancing transfer performance through explicit audit logs and dynamic memory management.

The Harness-1 architecture is a designation for a class of modular, explicitly structured system and software “harnesses” that mediate between models, agents, the environment, and verification substrates in both software engineering and agentic AI. Across its lineages, Harness-1 embodies the progression from ad hoc prompt chaining to auditable, self-improving engineering substrates, incorporating layered meta-engineering, persistent memory, adversarial verification, closed-loop calibration, and systematic tool mediation. Its instantiations define not a narrow implementation but an architectural template underpinning reliable AI-native software, persistent agent scaffolds, and state-externalizing RL agents (Sengupta et al., 25 May 2026, Seong et al., 22 Apr 2026, Gu, 25 May 2026, Jiang et al., 1 Jun 2026, Zhong et al., 13 May 2026).

1. Architectural Foundations and Scope

Harness-1, as formalized in “Meta-Engineering Harnesses for AI-Native Software Production” (Sengupta et al., 25 May 2026), establishes the harness as the first-class operating substrate for continuous AI-driven software production. Rather than addressing only individual models, Harness-1 architecturally integrates requirement formalization, multi-role orchestration, contract-driven work routing, adversarial and independent verification, persistent memory, structured arbiter-based failure handling, and harness-level self-calibration. This design is motivated by the necessity for continuous, verifiable, and adaptive infrastructure, with applications extending from service-as-a-software (“CTO-as-a-service”) to reinforcement learning–driven retrieval agents and automated code engineering.

Harness-1’s modularity extends to agentic AI, where it defines the persistent control and verification layer between a foundation model and its environment—abstracting away application specifics in favor of reusable, independently verifiable harness modules (Gu, 25 May 2026, Jiang et al., 1 Jun 2026). In software engineering applications, the harness progressively structures the action, observability, and verification substrate, moving from baseline tool gating (“H1” level) to full-on contract-driven and runtime auditable frameworks (Zhong et al., 13 May 2026).

2. Layered Architecture and Modular Components

In its production software meta-engineering form (Sengupta et al., 25 May 2026), Harness-1 is instantiated as a seven-layer stack:

Layer/Module	Core Functionality	Key Mechanism/Abstraction
Calibration Layer	Systematic outer-loop improvement based on outcome analysis	Retrospective agent, template/specialization update
Verification Layer	Dual regime: independence-based adversarial CI, multi-role review	Structural/attention-based checks
Execution Layer	Implementation, migration, UI artifact production	Builder/tester agents
Context & Memory Layer	Persistent Markdown memory, specialization repository	Rolling/permanent sections, confidence-scored domain injections
Contract Layer	Two-pass compiler from free-form requests to unambiguous contracts	Completeness, then ambiguity/elision
Role & Orchestration	Assignment of functional roles, work/task routing	Role-typed agents: compiler, builder, arbiter, etc.
Model Layer	Dynamic selection of appropriate model per role	Claude, Codex, open/open-source LLMs

This strict separation aligns with harness architectures in general agentic AI (Gu, 25 May 2026). There, the key modules are:

• Reasoning Substrate (ℛ): Model-driven reasoning and plan generation
• Persistent Memory (ℳ): Structured, durable, queryable working memory
• Context Governance & Constructor (ℂ): Dynamic and efficient context assembly per step
• Skill-Routing Layer (𝒮): Selection and structuring of API/tool/subagent calls
• Orchestration Loop (𝒪): Sequential and cyclic control over agent operation
• Verification & Governance (𝒢): Enforcement of external and internal safety, audit, and correctness

Standardized module APIs and performance metrics enable pluggable, auditable deployments and upstream calibration.

3. Contract Compilation, Persistent Memory, and Specialization

Harness-1’s contract-driven engineering pipeline highlights a rigorous two-pass compilation:

• Pass 1 (Completeness): Expansion of each raw issue clause into tuples $\langle$spec, type, state-transitions $\delta$, edge cases $\epsilon$, error taxonomy $\tau\rangle$.
• Pass 2 (Ambiguity/Scope): Pruning unsupported (U) and ambiguous (A) elements, with ambiguous clauses clarified or rewritten as $$C_2 = (C_1 \setminus U) \cup \{\text{rewrite}(a) \mid a \in A\}$$.

This contract is recorded in the persistent Markdown memory, with domain specializations (“specialization records”) indexed by module and confidence score $\sigma$; above a threshold $\theta$ the contract compiler auto-injects domain constraints (e.g., idempotency keys for payments). Institutional knowledge is codified in permanent memory sections, while new observations and patterns populate rolling memory. Domain specialization directly influences subsequent contract expansions, enabling incremental and self-calibrating harness improvement (Sengupta et al., 25 May 2026).

4. Verification Regimes and Failure Arbitration

Adversarial, redundancy-enforcing verification is a central guarantee of Harness-1. Two orthogonal regimes are employed:

• Independence-Based Verification: A “builder” agent and a structurally independent “tester” each operate only on the final contract $C_2$, constructing the artifact $A$ and the test suite $S$, respectively. The continuous integration (CI) runner executes $\delta$0 on $\delta$1: $\delta$2.
• Attention-Based Verification: Sequential multi-role reviewers (product, architecture, security, QA, etc.) analyze $\delta$3 from discipline-specific perspectives, flagging gaps not detectable with pure testing.

Failures are routed through a four-way arbiter: errors are classified as Bug (contract invariant violated), SpecGap (missing coverage in contract), Noise (environmental flake), or Ambiguity (multiple valid behaviors allowed by contract). Each class prompts a targeted action—ranging from implementation patching and regression test promotion to contract/template refinement and pipeline re-entry (Sengupta et al., 25 May 2026).

5. Outer-Loop Calibration and Evolution

Harness-1 incorporates an explicit retrospective calibration layer. Post-deployment logs and failure histories are parsed for (failure type, agent/instrumentation ID, contract region). For each failure class, the outer loop implements:

• Contract template upgrades (if SpecGap prevalence rises)
• Regression test promotion (for Bugs)
• CI/verifier tuning (for Noise)
• Compiler rule tightening (for Ambiguity)
• Promotion of memory (rolling $\delta$4 permanent) and specialization updates

Metric tracking (e.g., spec-gap rate, ambiguity detection rate, mean cycles/feature) supports harness-level optimization and self-improvement.

In Harness-1’s meta-engineering generalization, this calibration is formalized as a meta-evolution loop: an outer agent $\delta$5 evolves the entire protocol ($\delta$6) that itself evolves per-task harnesses $\delta$7 in an inner loop, maximizing average task performance across $\delta$8 (Seong et al., 22 Apr 2026).

6. Systemic Impact: State Externalization and Harness-Level Benchmarks

Harness-1’s explicit “harness as system object” principle generalizes to agentic AI and RL-driven retrieval agents (Gu, 25 May 2026, Jiang et al., 1 Jun 2026). In RL settings, the harness maintains all mechanical working memory and environmental state—candidate pools, curated sets, evidence graphs, verification logs, and compressed state rollups—delegating only semantic/strategic actions to the policy network. This state-externalizing yields higher in-domain and stronger transfer performance (+17 points in held-out transfer benchmarks vs. context-1), and ablation studies demonstrate losses in end-task performance (3–8% recall) with any harness module removed (Jiang et al., 1 Jun 2026).

Harness-1 further motivates a new family of harness-level benchmarks: trajectory quality, memory hygiene, context efficiency ($\delta$9), verification cost, and safe agent evolution over time (Gu, 25 May 2026). Explicit harness modularity and audit log design enable rigorous evaluation and attestation that model-only evaluation cannot provide.

7. Comparative Perspective and Levels

Within the harness-level taxonomy (H0–H3) for software code agents, Harness-1 (at H1) manifests as the minimal point where tool usage is explicitly whitelisted, invoked with uniform API, and monitored/logged with permission boundaries and timeouts (Zhong et al., 13 May 2026). It stands in contrast with H0 (no explicit tool/protocol) and H2/H3 (introduction of project memory, context-selection, structured verification).

Harness-1 thus operationalizes the control boundary between unconstrained model operation and the incremental layering of structured, verifiable, and auditable runtime support, forming the backbone of reliable foundation-model deployment in high-assurance, agentic, and continuous software domains.