Table of Contents

A clean equation in AI engineering right now is also the most useful one for data leaders:

Agent = Model + Harness

A raw model can reason and generate. A harness turns that capability into a working system by supplying context, tools, state, permissions, feedback, and limits. When an agent succeeds repeatedly (thousands of times in production instead of once in a demo), the harness deserves much of the credit.

Bar chart comparing raw model capabilities (52.8%) with a model enhanced by harness engineering (66.5%), highlighting a 13.7% improvement achieved solely through changes to prompts, tools, middleware, context, and verification rather than modifications to the underlying AI model. | The Modern Data Company
How harness engineering drives performance of AI agents

Vivek Trivedy ran the same model against the same benchmark twice. He kept GPT-5.2-Codex fixed and changed only the system around it: the prompt, the tools, the middleware, the context injection, the verification loop.

The score on Terminal Bench 2.0, a benchmark for coding agents, rose from 52.8% to 66.5%. That single change moved the agent from outside the top 30 to the top five.

This was a substantially better system. Trivedy gave this discipline a name: harness engineering.

Coding agents made the pattern visible first, but the pattern is not specific to code. An enterprise data agent also needs instructions, bounded tools, enforceable permissions, curated context, verification, and an audit trail.

Much of that machinery already exists in the modern data platform. The opportunity is not to relabel every platform feature as AI, but to wire the relevant features into the agent's execution loop.

The distinction between having controls and putting them in the loop is where most enterprise AI architecture will succeed or fail.

What Is an AI Agent Harness in a Data Platform

An effective coding-agent harness has a few load-bearing components:

  • Instructions define conventions and constraints.
  • Context management supplies the smallest useful slice of information.
  • Tools give the model bounded ways to act.
  • Hooks and policy gates run deterministic checks before or after actions.
  • Sandboxes limit the blast radius.
  • Evaluators and observability test whether the result matches the intent.
  • A ratchet converts recurring failures into permanent rules.

The enterprise data equivalents are concrete.

Comparison diagram mapping generic AI harness components to enterprise data platform capabilities. Instructions align with semantic layers, context maps to lineage and operational knowledge, tools correspond to governed data products, hooks become data contracts and policies, sandboxes become isolated compute environments, and evaluators translate into quality signals and telemetry. | The Modern Data Company
Comparison diagram mapping generic AI harness components to enterprise data platform capabilities.

The instruction layer is the semantic layer

The layer that maps business terms to their approved meaning, combined with active metadata: definitions, ownership, sensitivity, freshness, and accepted use, kept current rather than frozen in a static catalog. It tells an agent what *net_revenue* means, which source is authoritative, and whether a metric is valid for the requested region.

The context manager is not a catalog dump

It is a service that selects the definitions, lineage (the record of where a dataset came from and how it was transformed), examples, and operational knowledge relevant to the current task. More context is not automatically better. Irrelevant metadata competes for the model's attention.

The tools are governed interfaces to data products

Packaged and governed datasets built for a specific use case, plus query services and operational systems. A tool should expose a narrow capability with a typed contract, not hand the agent a warehouse credential and wish it luck.

Contracts and policies act as hooks

They validate schemas, freshness, purpose, entitlements, budgets, and action parameters at the moment the agent tries to use them. Success can stay silent. Failure must return a structured reason the agent can understand and respond to.

Scoped compute, short-lived credentials

Row and column controls, and isolated workspaces provide the sandbox. Lineage, traces, quality signals, and spend telemetry form the evaluation plane.

The mapping is useful, but an analogy is not an architecture. To become one, the controls must participate in every consequential action.

How an AI Agent Harness Processes a Single Request

Consider an agent helping a support manager investigate a spike in refund requests and draft a remediation plan.

The manager asks: "Why did refunds jump in Germany last week, and which affected customers qualify for proactive credits?"

The model can decompose the task. It should not decide on its own what "refund," "affected," or "qualify" means. It should not have unrestricted access to customer records. It should not have the authority to issue credits on its own.

Here is what the harness must do:

Process flow diagram illustrating an enterprise AI agent execution pipeline. Sequential stages include identity binding, semantic resolution, planning, policy evaluation, work execution, result verification, action gating, and audit recording. Policy decisions determine whether actions are allowed, denied, masked, or require approval before execution. | The Modern Data Company
How a data platform acts as a harness in the AI Agent Execution Loop
  1. Bind identity and purpose.
    The request carries the manager's identity, the agent's identity, the support-investigation purpose, and a correlation ID, a single identifier that ties every step of the request together for later review. The agent is a principal, an identity the system can track and constrain in its own right, not an invisible extension of a superuser.
  2. Resolve semantics.
    The context service returns the approved refund metric, the Germany market definition, the relevant time zone, the authoritative order and payment data products, and their current quality status.
  3. Plan with bounded tools.
    The agent can query approved aggregates, inspect lineage, and request a customer-level cohort. It cannot run arbitrary SQL across the warehouse.
  4. Evaluate policy before execution.
    The cohort request reaches a policy enforcement point, the checkpoint that intercepts the action before it runs. A policy decision point then weighs the manager's entitlements, the investigation purpose, data sensitivity, requested fields, and geographic restrictions, and returns one of four outcomes: ALLOW, DENY, MASK, or REQUIRE_APPROVAL.
  5. Meter the work.
    The system attributes query cost, model tokens, retries, and downstream API calls to the support workflow and checks them against a budget policy while the work happens.
  6. Verify the result.
    An evaluator checks the agent's explanation against source freshness, query results, and the refund metric's definition, and tests separately whether the conclusion is actually supported.
  7. Gate the action.
    Drafting a credit policy is low risk. Issuing credits is not. The latter requires approval and runs through a transaction-specific tool with amount and customer limits.
  8. Record the chain.
    The system logs identity, context versions, policy decisions, queries, costs, approvals, tool calls, and outputs under the same correlation ID.

This is what "the platform is the harness" means in practice.

Each data platform component changes what the agent can do.

What a Data Platform Can't Govern in AI Agent Actions

There is an important boundary to draw. A data platform cannot govern an action it never sees.

If the refund agent can call a SaaS admin API directly, browse the public web, send Slack messages, or execute code outside governed infrastructure, data-layer controls are insufficient.

Identity, an agent or API gateway (the checkpoint that authorizes calls to tools outside the data estate), application-level authorization, network policy, sandboxing, and human approval may sit outside the data platform while still belonging to the overall harness.

The right claim is therefore narrower, and more credible, than "the data platform is the entire AI control plane."

For data-intensive agents, the platform is the context, data-access, execution, and evidence core of the harness. An authorization fabric or agent gateway must connect that core to non-data tools.

Microsoft's reference architecture for agent authorization uses the same pattern: a policy enforcement point sits in front of the action, a policy decision point evaluates identity and context, and the tool executes only after an ALLOW decision or required approval.

This boundary also explains why a catalog, by itself, is not a harness. A catalog informs a human. A harness intervenes in execution.

A quality alert that lands in Slack after an agent has acted is observability instead of preventive control. A policy PDF is simply guidance and does not act as authorization.

How DataOS Implements the Agent Harness Framework

DataOS helps users map to this framework directly with modular platform components that create an environment for AI to optimize performance.

Architecture diagram showing three connected platform components (Lens, Data Product Hub, and Modeling Layer) linked by a shared data flow. The illustration explains how DataOS provides contextual understanding, governed data products, and policy enforcement as the core infrastructure supporting AI harness engineering. | The Modern Data Company
Implementing Agent Harness Framework with DataOS

Lens: The Semantic Layer

Lens acts as the context and instruction layer. It resolves business terms like net_revenue to their approved definitions and serves the slice of metadata an agent actually needs, rather than handing over the entire catalog.

Data Product Hub: The Data Product Marketplace

The DataOS Data Product Hub packages data products as governed, typed interfaces. An agent calls a data product the way it would call any bounded tool, not a raw connection to the warehouse.

The Modeling Layer Enforces Contracts.

Schema, freshness, and entitlements are checked at the moment of use, and a failed check returns a structured reason instead of a silent drop. None of this replaces the authorization fabric or agent gateway described above. It is the context, access, and evidence core those systems connect to.

How to Turn AI Agent Failures Into Permanent Controls

Harness engineering treats failure as input to system design. If an agent uses a stale table, the fix is not a reminder to check freshness next time.

The relevant tool should reject stale inputs or make freshness part of its contract. If an agent repeatedly requests an expensive model for a trivial classification, model routing should become policy.

If a valid workflow keeps hitting a poorly designed permission boundary, the answer may be a safer, purpose-built tool rather than a broader credential.

Each incident should produce one of four outcomes:

  • a better semantic definition
  • a narrower or more useful tool
  • a new deterministic check
  • a revised boundary between autonomous action and human approval

Failures become durable improvements to the operating environment.

The goal is not to accumulate rules forever. Every control encodes an assumption about what the model, tool, or organization cannot safely do on its own. As capabilities improve, obsolete scaffolding should come out, and new failure modes should get addressed as they show up.

Models will keep differing in quality, price, latency, and deployment options. Enterprises will not literally receive the same models on the same terms. But model advantage will stay rented and portable.

Topics: 
Curious how to make AI more reliable in your organization?
Cover of The Modern Data Report 2026 titled The Data Activation Gap with abstract blue and red gradient background.
Get the Report
Find out what your peers are saying.

Continue reading

Why AI gets it wrong and how data products fix that
Data Products

Why AI gets it wrong and how data products fix that

Srinivasa Mathkur
Jun 30, 2026
Context Native: The Data Product Foundation AI Agents Need
AI-Ready Data

Context Native: The Data Product Foundation AI Agents Need

Srinivasa Mathkur
Jun 18, 2026
Adding the Missing Layer: How Banks Are Activating the Data Stack They Already Built
Data Products

Adding the Missing Layer: How Banks Are Activating the Data Stack They Already Built

Darpan Shah & Srini Nirmalgandhi
Mar 27, 2026
See how DataOS can put data to work for you
Get started →