Would you give an AI agent production data access?
A model can draft SQL, explain a failed pipeline and propose a fix. The dangerous question is what happens when that reasoning is allowed to become an action.
No email gate. The chapter unlocks after the four questions.
Can you separate reasoning from authority?
Four scenarios drawn directly from the book's engineering model.
What Is Harness Engineering?
The opening failure
A prototype agent receives a SQL warehouse credential and a Git token. During a cleanup task it interprets a staging note as an instruction, runs a write statement against the wrong catalog, and replaces a table. The model did not bypass the system. The system exposed an unsafe capability under an over-privileged identity and accepted a natural-language decision where deterministic policy was required.
Harness engineering is the discipline of designing the runtime and control environment in which model reasoning can become action. A production harness owns:
- tool discovery, schemas, versions, and trust classification;
- identity, credentials, authorization, and policy enforcement;
- context selection, provenance, isolation, and memory;
- planning, state transitions, retries, timeouts, and stopping conditions;
- budgets for tokens, compute, money, and operational impact;
- validation, approvals, deployment gates, recovery, and rollback;
- traces, evaluations, audit evidence, and incident reconstruction.
OpenAI has used harness engineering for the repository structure, tests, feedback loops, and controls that make agent-first software development effective. Microsoft Agent Framework defines an Agent Harness as runtime scaffolding for model and tool calls, context, state, approvals, and long-running work. Those sources support the term; they do not justify claiming that every vendor uses one identical definition.
A harness is not a prompt
A prompt can tell a model not to modify production. A permission boundary can make modification impossible. A prompt can request a cost estimate. A gateway can reject a query whose plan exceeds a byte-scan limit. A prompt can ask for a rollback plan. Delta table history and a tested RESTORE procedure can provide one.
Instructions shape behavior; controls constrain behavior. Reliable systems use both, but never substitute the former for the latter.
A harness is not a framework
An agent framework supplies programming abstractions: agents, handoffs, graphs, sessions, or tool decorators. The harness is the deployed control system assembled from those abstractions plus identity, policy, data governance, CI/CD, observability, and operating procedures. Replacing a framework should not erase the permission model, audit schema, or production gates.
Control plane and execution plane
The control plane interprets intent, builds a plan, computes risk, selects tools, requests approvals, and records state. The execution plane runs bounded deterministic operations: catalog reads, SQL statements, quality suites, Lakeflow Jobs, bundle deployments, and rollback commands. The model participates in the control plane. It never becomes the ultimate authority in either plane.
Every side effect must be attributable to a principal, a policy decision, a versioned artifact, and a verification result. If one is missing, the action is not production-ready.
The next 23 chapters turn this principle into an operating system.
The rest of the book moves from model/agent/harness anatomy and the Minimum Agency Principle into Data Agent task taxonomy, reference architecture, context engineering, multi-agent orchestration, Unity Catalog, Lakeflow, Delta, MCP gateways, data contracts, quality gates, production autonomy budgets, security controls, observability, evaluation, failure handling, CI/CD and the autonomous data platform maturity model.
Continue reading on Amazon Kindle →Opens the official Amazon Brazil page for the book.