Your AI Model Isn't Dumb, Your Harness Is Broken: How Harness Engineering Bridges the Enterprise Information Gap
TL;DR: When a coding or data agent hallucinates a table name, loops endlessly on a failing test, or breaks a build, our first instinct is to blame the model weights. Yet 2026 engineering benchmarks prove the opposite: changing the harness around the exact same model routinely yields 10+ point capability jumps. While studying the History of Harness Engineering and Bridging the Information Gap, we distilled the core equation of modern AI systems: Agent = Model + Harness (which means Harness = Agent - Model). Below are our architectural evaluation notes covering the three eras of AI engineering (Prompt → Context → Harness), why standalone models fail on enterprise repositories, how the Open Knowledge Format (OKF) and Model Context Protocol (MCP) close the information gap, and how to build a 6-layer self-verifying harness with Antigravity CLI (agy), Google ADK, Gemini 4 Argon (gemini-4-argon), and Gemini 3.8 Flash (gemini-3.8-flash).
Imagine hiring a principal software engineer on Monday morning, locking them in a room with no Wi-Fi, no repository access, no compiler, and no schema documentation, and slipping a sticky note under the door: "Fix the checkout latency bug and close the Q4 enterprise deal."
When they hand back a broken guess an hour later, you would never conclude that the engineer lacks intelligence. You set them up to fail by starving them of context, tools, and verification feedback.
Yet that is how most teams run LLMs in production. They send a raw prompt to a stateless API call, get a hallucinated SQL column or an uncompilable patch, and immediately ask when the next model checkpoint is coming out.
The turning point in modern agentic engineering is recognizing a simple structural equation popularized by Mitchell Hashimoto and formalized across Martin Fowler's Harness Engineering analyses:
$$
\text{Agent} = \text{Model} + \text{Harness} \implies \text{Harness} = \text{Agent} - \text{Model}
$$
The harness is every piece of code, configuration, and execution logic that is not the neural network weights. It is the control loop, the filesystem memory (AGENTS.md, SPEC.md, SKILL.md), the tool schemas and MCP servers, the sandbox permissions, the deterministic lifecycle hooks, and the automated test suite wrapping the core model.
1. The History of Harness Engineering: Three Eras of AI Systems (2022–2026+)
To understand why harness engineering now dominates production AI work, trace how the core engineering question evolved over the past five years. Each era did not replace the previous one; it wrapped the previous layer inside a larger control system.
| Dimension |
Era 1: Prompt Engineering (2022–2024) |
Era 2: Context Engineering (2024–2025) |
Era 3: Harness Engineering (2026+) |
| Core Question |
"Did I phrase the instruction clearly?" |
"Does the model see the right information?" |
"Does the system run reliably without me?" |
| Everyday Metaphor |
Writing a single email |
Curating and organizing an inbox |
Designing the entire email & routing system |
| OS Analogy |
A single CLI command (Input → Model → Output) |
RAM & virtual memory management |
The complete Operating System (scheduler, permissions, IPC, verification) |
| New Hire Analogy |
Saying "Close the big deal" with zero background (Result: panic) |
Handing over the instruction + historical case file (Result: smarter, but prone to rogue decisions) |
Instruction + case file + milestone checklist + approval gate + validation script (Result: repeatable delivery) |
| Primary Metric |
Subjective single-turn output quality |
KV-cache hit rate & retrieval precision |
End-to-end task completion rate & cost per verified outcome |
| Primary Failure Mode |
Blind Prompting (fragile phrasing sensitivity) |
Context Pollution (attention dilution & stale chunks) |
Orchestration Bugs (infinite loops, unguarded tool calls, state races) |
Industry Proof: Same Model, Different Harness
The strongest evidence that the harness is the primary engineering lever comes from controlled 2026 production benchmarks:
- Terminal Bench 2.0 (+13.7 Percentage Points with Zero Weight Changes). LangChain's Deep Agents team took their coding agent from 52.8% to 66.5% on Terminal Bench 2.0 (climbing from #30 to #5 on the leaderboard) while keeping the exact same underlying model. They changed only three harness mechanisms: a pre-completion self-verification checklist, upfront directory/environment context discovery, and loop-detection middleware that forces a strategy pivot after repeated identical test failures.
- Zero-Manual-Code Delivery at Scale. OpenAI's internal Harness Engineering team (3 to 7 engineers) shipped roughly 1 million lines of production code across 1,500 pull requests in 5 months with zero manually typed application code. Whenever the agent made an architectural mistake, the engineers never fixed the code by hand. Instead, they upgraded the harness: adding custom linters with remediation instructions in the error message, tightening
AGENTS.md, or wiring a stricter CI check.
- Multi-Hour Generator-Evaluator Loops. Anthropic's long-running harness research compared a solo coding agent against a 3-agent harness (
Planner + Generator + Evaluator) building a 2D game engine. The solo run finished in 20 minutes ($9) with broken gameplay; the harnessed trio ran for 6 hours ($200) and delivered a playable, verified application because the independent Evaluator tested the live UI in a browser after every sprint.
2. Why Standalone Models Fail: The 6 Cracks in the Single-Turn Prompt Monolith
Relying purely on a model's standalone weights and a clever prompt fails in production repositories for six structural reasons:
- The Static Information Ceiling (Anterograde Amnesia). A pre-trained model is frozen at its training cutoff. Without live retrieval tools, it cannot know about an API change shipped yesterday or an incident unfolding right now.
- Blindness to Proprietary Context. Public training corpora do not contain your company's private schemas, internal microservices, deployment policies, or team naming conventions. Left to guess, the model invents plausible-sounding tables and flags that do not exist.
- The "Stateless Function" Constraint. Every raw LLM call starts from zero. Without an external state store, session ledger, or git-backed progress file, a multi-hour refactor loses its thread the moment a session restarts.
- Lack of Environmental Grounding (Silent Failures). A naked model has no compiler, no type-checker, no SQL
EXPLAIN dry-run, and no test runner. It outputs confident code with zero feedback on whether that code actually compiles or passes tests.
- Vulnerability to Security Exploits. Prompt-only safety instructions ("Never run destructive SQL or shell commands") are probabilistic suggestions. When an agent processes untrusted external data alongside privileged tools, prompt guardrails can be bypassed unless backed by deterministic code hooks.
- Attention Dilution ("Lost-in-the-Middle" Syndrome). Dumping every company policy, database DDL, and API spec into one 30,000-token system prompt degrades recall on the exact rule needed for the current step.
3. Bridging the Enterprise Information Gap: Semantics, Memory, and Protocols
Between a frontier model (gemini-4-argon or gemini-3.8-flash) and your enterprise environment sits a massive Information Gap. The model reasons in tokens and public patterns; your enterprise runs on tribal SQL definitions, fragmented internal APIs, and unwritten team rules.
A modern harness bridges that gap across three distinct layers: Standardizing Semantics (OKF), Fetching On-Demand Memory (RAG + Skills), and Unifying Action Discovery (MCP vs. Function Calling).
graph LR
subgraph ModelLayer["Frontier Model Layer"]
M["Gemini 4 Argon (Orchestrator)\n& Gemini 3.8 Flash (Fast Worker)"]
end
subgraph Bridge["The Harness Bridge (Closing the Information Gap)"]
direction TB
S["1. Standardize Semantics\nOpen Knowledge Format (OKF)\nYAML Frontmatter + index.md Graph"]
K["2. On-Demand Memory\nRAG Semantic Search +\n3-Tier SKILL.md Disclosure"]
P["3. Unified Action Protocol\nDirect Function Calling (Fixed) &\nMCP Servers (Dynamic Discovery)"]
H["4. Deterministic Guardrails\nbefore_tool_callback Hooks,\nSandboxes & make verify"]
end
subgraph Enterprise["Enterprise Environment"]
DB[("Private Data Warehouses\n& Cloud SQL Schemas")]
REPO["Internal Git Repos,\nCI/CD & Linters"]
API["Internal Microservices\n& Cloud APIs"]
end
M <--> S
M <--> K
M <--> P
P --> H
S --> DB
K --> REPO
H --> DB
H --> REPO
H --> API
Pillar A: Standardizing the Semantics with the Open Knowledge Format (OKF)
A model cannot reason accurately over enterprise metrics (like Daily Run Rate, Net Revenue Retention, or Active Account Eligibility) if those definitions are buried in 80-page PDFs or scattered across Slack threads.
The Open Knowledge Format (OKF) gives the model a native language it can browse deterministically: a Git-versioned directory of Markdown files with structured YAML frontmatter that represents tables, APIs, and business metrics as an interconnected graph.
Building an OKF living wiki follows a five-step pipeline:
- Extract & Segment (
Map concepts 1-to-1). Pull raw definitions from PDFs, docs, and SQL views, splitting them at natural conceptual boundaries so one file equals one atomic concept (one table, one metric, or one API contract).
- Normalize Layout (
Convert to clean Markdown). Strip broken formatting and standardize headings, join keys, and canonical SQL snippets.
- Inject Queryable Frontmatter (
YAML Index Cards). Prepend strict metadata fields (type, title, description, tags, updated_at) to the top of every file.
- Generate the Master Catalog (
index.md). Compile a lightweight index containing only the title, type, description, and relative path of every concept file.
- Expose Navigation Tools (
list_concepts() & read_concept()). Instead of stuffing 200 table schemas into the system prompt, the agent scans index.md (~50 tokens per concept) and reads only the exact concept files required for the query.
Alongside OKF domain concepts, keep your repository instructions split across Four Files for Four Audiences:
README.md (For Humans): Project overview, setup, and architecture summary.
AGENTS.md (For the Agent Across the Whole Repo): Compact (< 300 lines) build/test commands (make verify), directory boundaries, and non-negotiable rules.
SPEC.md / PLAN.md (For One Feature or Track): The explicit requirements, target files, and verification criteria for the current change.
SKILL.md (For On-Demand Workflows): Reusable procedural playbooks loaded progressively when a task matches their description.
Pillar B: Fetching Proprietary Knowledge On-Demand (RAG + Progressive Disclosure)
Where OKF structures known architectural entities into a browsable graph, Retrieval-Augmented Generation (RAG) and Agent Skills (SKILL.md) provide on-demand memory for unstructured runbooks and procedures:
- RAG for Unstructured Corpora: Documents are chunked, embedded into a vector index, and retrieved at query time (
top-k semantic match) so the model answers with grounded citations rather than parametric guesses.
SKILL.md for Procedural Workflows: As covered in my previous post on Agentic Coding Skills, SkillToolset keeps procedural playbooks out of startup memory until the agent activates them.
Pillar C: Unifying Action Discovery (MCP vs. Direct Function Calling)
Giving an agent read/write access to enterprise systems used to mean writing bespoke glue code for every service. Think of the difference between Traditional APIs, Direct Function Calling, and the Model Context Protocol (MCP) like ordering food for an engineering team:
- Traditional Siloed Integrations (Separate Orders): Ordering pizza, sushi, and coffee from three separate restaurant websites means managing three custom auth flows, three incompatible JSON payload schemas, and three error-handling loops.
- Model Context Protocol / MCP (The Unified Aggregator): MCP acts like a single unified delivery protocol. An agent connects to any compliant MCP server (
BigQuery, Cloud SQL, GitHub, Playwright) through one standardized client-server interface, discovering available tools and schemas dynamically at runtime.
Use this Architectural Rule of Thumb when wiring your harness:
| Workload Pattern |
Recommended Integration Mechanism |
Why It Fits |
| Simple, Fixed Tasks (2–5 tightly scoped tools inside one service) |
Direct Function Calling (tools=[my_func]) |
Lowest latency, zero external server overhead, explicit one-to-one Python type signatures. |
| Deterministic Program-to-Program Pipelines (cron jobs, ETL, fixed webhooks) |
Traditional REST / gRPC APIs |
Code queries backends directly; no LLM reasoning or tool schema tokens needed in the loop. |
| Complex, Multi-System Enterprise Agents (dynamic discovery across databases, docs, and cloud infra) |
Model Context Protocol (MCP) |
Standardized client-server discovery, reusable across agents, decoupled security boundaries. |
4. Anatomy of a Production Harness: The 6 Core Building Blocks
When you zoom out from individual prompts and look at a production agent runtime like Antigravity or Google ADK, every reliable harness is built from six components:
- Instructions & Rules (
AGENTS.md, SPEC.md, SKILL.md). Defines the agent's identity, architectural constraints, and lazy-loaded domain playbooks.
- Tools & APIs (
FunctionTool, McpToolset). The action primitives the model can invoke, paired with crisp docstrings that tell the model when and why to call each tool.
- Sandboxes. Isolated execution environments (containers, temporary git worktrees, read-only database roles) that bound the blast radius of any command the agent runs.
- The Orchestrator (
Sequential, Parallel, Loop, Coordinator, AgentTool). Routes work across specialized models. A high-leverage pattern in Google ADK is pairing gemini-4-argon as the lead coordinator or critic with gemini-3.8-flash subagents wrapped in AgentTool (which returns control to the lead agent, unlike sub_agents=[...] which transfers the conversation away) or inside a LoopAgent critic cycle.
- Deterministic Guardrails & Hooks (
before_tool_callback, PreToolUse, Linters). Code that runs outside the LLM at lifecycle boundaries. If an agent tries to run DROP TABLE or commit unformatted code, a deterministic hook blocks it with 0 extra LLM tokens and returns an actionable error message so the model can self-correct.
- Observability & Scientific Evaluation. Tracing token spend, KV-cache hit rates, and evaluating trajectories through a three-step progression:
- Step 1 — Deterministic Code Gates: Fast, free checks (compiler exit codes,
pytest, JSON Schema validation, regex checks).
- Step 2 — Human Gold-Standard Baselines: Domain experts grade ~50 representative trajectories to establish an explicit, high-agreement rubric (scoring
1 to 5 on Groundedness, Completeness, and Conciseness).
- Step 3 — Calibrated Autoraters (
LLM-as-a-Judge): Once the rubric reaches human agreement, scale offline and online evaluations using an LLM judge calibrated against that human baseline.
5. Lab: The 3-Minute Self-Verifying Harness (Google ADK + Gemini)
To demonstrate the power of a harness over a raw prompt, we at DO-AI have distilled a 'Minimum Viable Harness' lab. This setup prevents SQL hallucinations by grounding the agent in a local knowledge file and a deterministic guardrail.
Step 1: Define the Knowledge (OKF)
Create knowledge/drr.md to define a proprietary metric:
# Concept: Daily Run Rate (DRR)
- Table: `finance.revenue_daily`
- Rule: MUST filter by `usage_date` and `region = 'APAC'`.
Step 2: The Harness Logic (agent.py)
This script uses Gemini 3.8 Flash to draft and Gemini 4 Argon to verify.
from google.adk.agents import LlmAgent, LoopAgent
from google.adk.tools import exit_loop
# 1. The Drafter (Flash)
drafter = LlmAgent(name="drafter", model="gemini-3.8-flash",
instruction="Draft SQL using knowledge/drr.md. Use usage_date filter.")
# 2. The Verifier (Argon)
verifier = LlmAgent(name="verifier", model="gemini-4-argon",
instruction="If SQL has 'usage_date' and 'APAC', call exit_loop. Else, give feedback.",
tools=[exit_loop])
# 3. The Loop
agent = LoopAgent(name="harness", sub_agents=[drafter, verifier], max_iterations=2)
import pathlib
import re
from typing import Any
from google.adk.agents import LlmAgent, LoopAgent
from google.adk.apps import App
from google.adk.tools import BaseTool, ToolContext, exit_loop
from google.genai import types
KNOWLEDGE_DIR = pathlib.Path(__file__).resolve().parent.parent / "knowledge"
# --- Layer 1 & 2: OKF Knowledge Bridge Tools ---
def list_okf_concepts() -> dict[str, str]:
"""Lists all enterprise concepts in the Open Knowledge Format (OKF) catalog.
Call this first to discover proprietary table schemas and metric definitions.
"""
index_file = KNOWLEDGE_DIR / "index.md"
if not index_file.is_file():
return {"status": "error", "reason": "knowledge/index.md not found"}
return {"status": "success", "catalog": index_file.read_text(encoding="utf-8")}
def read_okf_concept(relative_path: str) -> dict[str, str]:
"""Reads a specific OKF concept markdown file from the knowledge/ directory.
Args:
relative_path: Path relative to knowledge/, e.g. 'metrics/daily_run_rate.md'.
"""
target = (KNOWLEDGE_DIR / relative_path).resolve()
if not str(target).startswith(str(KNOWLEDGE_DIR)) or not target.is_file():
return {"status": "error", "reason": "Invalid or out-of-bounds OKF path."}
return {"status": "success", "content": target.read_text(encoding="utf-8")}
def dry_run_analytics_sql(sql_query: str) -> dict[str, str]:
"""Validates a read-only BigQuery SQL query against schema and governance rules.
Args:
sql_query: The candidate SQL query string to validate.
"""
return {
"status": "success",
"message": "Dry-run passed: query is read-only and partition-pruned on usage_date.",
"validated_sql": sql_query,
}
# --- Layer 5: Deterministic Guardrail Hook (Runs Outside the LLM) ---
FORBIDDEN_SQL = re.compile(
r"\b(DROP|DELETE|TRUNCATE|UPDATE|INSERT|ALTER|GRANT)\b", re.IGNORECASE
)
def enforce_sql_harness_policy(
tool: BaseTool, args: dict[str, Any], tool_context: ToolContext
) -> dict[str, str] | None:
"""Deterministic pre-tool hook that blocks unsafe or unscoped SQL queries."""
if tool.name != "dry_run_analytics_sql":
return None
sql = str(args.get("sql_query", ""))
if FORBIDDEN_SQL.search(sql):
return {
"status": "blocked_by_harness",
"remediation": "Mutating SQL is forbidden. Rewrite as a read-only SELECT query.",
}
if "usage_date" not in sql.lower():
return {
"status": "blocked_by_harness",
"remediation": (
"Missing partition filter on 'usage_date'. Read 'metrics/daily_run_rate.md' "
"via read_okf_concept and include a usage_date filter."
),
}
if "gross_revenue_usd" in sql.lower() and "pct" not in sql.lower():
return {
"status": "blocked_by_harness",
"remediation": (
"Governance violation: do not select raw gross_revenue_usd without computing "
"relative percentage change (drr_pct_change)."
),
}
return None # Return None to allow tool execution
# --- Layer 4: Multi-Model Orchestrator (Gemini 3.8 Flash + Gemini 4 Argon) ---
sql_drafter = LlmAgent(
name="sql_drafter_agent",
model="gemini-3.8-flash",
description="Fast analytics SQL drafter grounded in the OKF knowledge graph.",
instruction=(
"You draft production BigQuery SQL for enterprise metrics.\n"
"1. Always call list_okf_concepts and read_okf_concept first.\n"
"2. Apply any prior critic feedback: {critic_feedback?}\n"
"3. Validate your query with dry_run_analytics_sql before finishing."
),
tools=[list_okf_concepts, read_okf_concept, dry_run_analytics_sql],
before_tool_callback=enforce_sql_harness_policy,
output_key="candidate_sql",
generate_content_config=types.GenerateContentConfig(
max_output_tokens=32768,
temperature=0.1,
),
)
principal_critic = LlmAgent(
name="principal_harness_critic",
model="gemini-4-argon",
description="Verifies SQL drafts against OKF governance rules and exits the loop when clean.",
instruction=(
"Review the drafted query in {candidate_sql?}.\n"
"Verify that it:\n"
"- Queries analytics_prod.finance.revenue_daily\n"
"- Filters on usage_date, region = 'APAC', and sub_region = 'SEA'\n"
"- Outputs relative percentage changes rather than raw dollar totals.\n"
"If all checks pass, call exit_loop. Otherwise, return concise remediation steps."
),
tools=[exit_loop],
output_key="critic_feedback",
generate_content_config=types.GenerateContentConfig(
max_output_tokens=32768,
temperature=0.0,
),
)
root_agent = LoopAgent(
name="self_verifying_analytics_harness",
description="Self-correcting analytics harness pairing Gemini 3.8 Flash with Gemini 4 Argon.",
sub_agents=[sql_drafter, principal_critic],
max_iterations=3,
)
app = App(root_agent=root_agent, name="harness_agent")
Step 3: Execution
Run via Antigravity CLI: agy --model gemini-4-argon. The harness will now automatically correct the drafter if it forgets the mandatory filters, ensuring 100% policy compliance without human intervention.
6. Key Takeaways for Your Next Agent Build
Whenever an agent underperforms in your repository, resist the urge to rewrite your prompt for the tenth time or wait for a new model release. Ask three harness engineering questions instead:
- Where is the Information Gap? Have we given the model a structured, Git-versioned Open Knowledge Format (
OKF) catalog and AGENTS.md map, or is it guessing our schemas in the dark?
- Which rules belong in deterministic Hooks instead of prose? If a rule must hold 100% of the time (no destructive SQL, mandatory partition filters, passing
make verify), enforce it in before_tool_callback or a PreToolUse hook rather than begging the model in capital letters.
- Is the agent verifying its own work before returning? Pair fast execution (
gemini-3.8-flash) with frontier reasoning and critique (gemini-4-argon) inside a bounded verification loop so errors are caught and repaired before you ever read the diff.