Why Your Data Platform Isn't Wired for AI
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

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.

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.
.png)
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:
.png)
- 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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.
- The semantic layer supplies meaning
- Data Products supply trusted interfaces
- Policy supplies decisions
- Compute supplies bounded execution
- Observability supplies evidence
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.
.png)
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.




