Data contracts governance by hand vs with an AI agent: what changes and what doesn't

Data contracts governance by hand means a person writes each contract in YAML, negotiates it between producer and consumer, and checks it against reality on a schedule. With an AI agent, the agent drafts the contract from the live schema and observed data, then evaluates it continuously, and a person approves the result. The contract format is the same either way. The Open Data Contract Standard defines schema, quality and ownership fields that both approaches can target. What changes is who does the repetitive work.

Key Takeaways

• •A data contract binds a producer to schema and quality guarantees that consumers rely on. Writing one is cheap. Keeping hundreds of them accurate is where manual governance fails.
• •An agent can author a first-draft contract from a table's actual schema and data, and evaluate existing contracts against current state. Our Governance Agent does this through the dw-data-contracts-governance skill.
• •Humans still own the decisions: which guarantees to promise, who owns the contract, and whether a breaking change ships.
• •Evaluate an agent for this job on four things: whether it reads the real schema, whether it explains each rule, whether it is read-only by default, and whether every action is audited.

The job: who does data contracts governance today

In most teams the job lands on whoever feels the pain first. That is usually an analytics engineer or a platform engineer, sometimes a data steward in larger organisations. They are asked to make a producing team (an application team, an ingestion pipeline, an upstream analytics model) commit to a schema and quality bar that downstream consumers can depend on.

A contract typically covers the schema (columns, types, nullability), semantic rules (what a status value means), quality expectations (uniqueness, freshness, completeness, valid ranges), an owner, and a change process. The point is not the file. The point is that a breaking change becomes a conversation before it ships, not an incident afterward.

The manual workflow, step by step

We see the same sequence in most teams that run this by hand. Each step has a handoff, and each handoff is a place where the contract drifts from reality.

• •Pick the interface. Someone decides which tables or topics deserve a contract. This is usually driven by the last incident, not by a systematic ranking of consumer impact.
• •Reverse-engineer the schema. An engineer reads the DDL, samples the data and writes the schema section by hand. Types in the warehouse often differ from what the producer's code intends.
• •Guess the quality rules. Without a profile of the data, rules are either too loose to catch anything or too strict and fire constantly. Engineers tune them by trial and error.
• •Negotiate with the producer. This happens in a ticket or a meeting. The producer rarely knows who consumes the data, so consumers are chased down one by one.
• •Commit and wire up enforcement. The YAML goes into a repository, and someone connects it to CI or a test runner.
• •Maintain. Every schema change, new consumer and renamed column needs a contract edit. This step never ends, and it is the one that gets dropped.

Where the manual approach breaks

The first break is coverage. Authoring a contract takes real effort per table, so teams cover their top handful of tables and leave the long tail unguarded. The second is staleness. A contract is a snapshot of an agreement, and the schema keeps moving. Once the file and the table disagree, people stop trusting the file.

The third is rule quality. Quality thresholds written without looking at the data's actual distribution tend to be arbitrary. The fourth is the integration burden: the schema lives in the warehouse, consumers live in dashboards and models, and the contract lives in a repository. The engineer ends up as the integration layer between them. This is the same pattern we described in our post on why a coordinated agent swarm beats point tools.

What an agent does instead

Our Governance Agent carries a skill, dw-data-contracts-governance, described as authoring and evaluating data contracts that bind producers and consumers to schema and quality guarantees. We limit this section to that description. The agent does two things.

• •Authoring. Given a table, the agent reads the live schema and the data, and drafts a contract with the schema section filled in and proposed quality rules grounded in what the data actually looks like. A person reviews a draft instead of writing from a blank file.
• •Evaluating. Given an existing contract, the agent checks it against current state and reports where the schema, the data or the rules disagree with what was promised. You can ask it in plain language, such as "What's the blast radius if I drop this column?" or "Is the customer_id join safe after the migration?"

Every Data Workers agent is an MCP server, so you invoke this from Claude Code, Cursor or any client that speaks the Model Context Protocol. The open-source edition (dw-claw) is Apache 2.0 and read-only by default, which means the agent can draft and evaluate contracts without being able to change anything in your warehouse. Our Schema Agent covers the neighbouring job of detecting column-level drift and projecting downstream impact, and the two share context when a change touches a contract.

Data contracts governance by hand vs with an AI agent: side by side

We are deliberately not quoting hours saved. We have no public benchmark for this specific job, and we would rather describe the effort shift honestly: the agent moves the work from authoring and monitoring to reviewing.

What still needs a human approval

A contract is a commitment between teams, and an agent cannot make that commitment for you. We keep these decisions with people.

• •Which guarantees to promise. An agent can propose a freshness rule. Whether your team will staff an on-call rotation to honour it is a business decision.
• •Ownership. Who is accountable when the contract is breached is an organisational call.
• •Breaking changes. When a producer wants to change a promised column, someone has to weigh the cost to consumers.
• •Any write. In Pro, writes sit behind approval workflows and are recorded in a tamper-evident audit trail. In the open-source edition nothing is written at all.

How to evaluate an agent for this job

Whether you choose us or build something yourself, we would test any agent for contract work against the following questions.

• •Does it read the real schema and data, or does it work from documentation and descriptions that may be out of date?
• •Can it explain each proposed rule? A rule with no stated reason is a rule nobody will defend in a producer negotiation.
• •Is it read-only by default, with writes gated by approval?
• •Does it leave an audit trail of what it proposed, who approved it and what changed?
• •Does it output a standard format such as the Open Data Contract Standard, so the contracts are not locked inside one tool?
• •Does it run where your engineers already work, so reviewing a draft doesn't mean opening another dashboard?

A good test is to point the agent at five tables you already have contracts for and compare its draft with what your team wrote. Differences are informative either way. Where the agent found a rule you missed, that is a gain. Where it missed a rule that came from business context, that shows why the human review step exists.

Frequently Asked Questions

What is a data contract? A data contract is a written agreement between a data producer and its consumers that specifies the schema, quality expectations, ownership and change process for a dataset. Formats such as the Open Data Contract Standard give those fields a common structure.

Can an AI agent write a data contract on its own? An agent can draft one from the live schema and data, and propose quality rules. It should not finalise one alone. The guarantees are promises to other teams, so a person reviews and approves them.

Does the agent change my warehouse? Not in the open-source edition, which is read-only by default. Pro adds writes with approval workflows and audit trails, so each change is reviewed by a person before it happens.

How is this different from writing contracts in YAML myself? The format can be identical. The difference is who produces the first draft and who notices drift. By hand, both depend on an engineer remembering to do it. With an agent, drafting and evaluation are requests you can make at any time.

Where do I start? Pick a handful of high-consumer tables, ask the Governance Agent to draft contracts for them from your terminal, and compare the drafts with any contracts you already have. Our open-source edition runs locally, so you can try this without sending data anywhere.