Crossing the Data Divide: Data Governance Agent Team Working Example

Crossing the Data Divide is a quarterly TDAN column published on DATAVERSITY.

A few years ago, I wrote a book called The Goal is Autonomous Governance. My argument was simple to state but hard to implement: The traditional, human-centric model of data governance had reached its limits, and the only way forward was to shift from governance performed by humans, assisted by tools, to governance performed by machines, supervised by humans. I called that destination “autonomous governance.”

When I wrote it, the vision was clear, but achieving it would have been a heavy lift, combining workflow engines, rule engines, classifiers, quality monitors, and lineage trackers.

The rise of reasoning models has made one of the book’s central ideas easier to build: the idea that governance, in an enterprise where machines do the work, stops being advisory and becomes operational. It becomes a control plane.

In this column, I want to explain what that means, demonstrate it, and provide the code of a working example you can run yourself.

Moving Governance from Passive to Active

For decades, governance councils have defined policies, issued guidelines, and attempted stewardship. The stewards had little real authority to enforce and were massively overwhelmed by the scope of their responsibility and the pace of constant change.  The result has been governance as a passive activity used to inventory and classify as a “box-checking” exercise. There was little operational relevance.

That model cannot survive what is coming. When agents execute business processes autonomously, governance must be an active process and not a set of guidelines. Policies must become machine-enforced constraints that the agents cannot violate. The governance decision and the operational outcome become the same event. When a council sets a data quality threshold, every agent validates against that threshold before it acts. When a council defines an approval limit, that limit is automatically enforced everywhere, every time. That is how governance becomes the control plane for autonomous operations.

This is not a tooling upgrade. It is a change in what governance is. A control plane is the layer that decides what is permitted to happen and then makes that decision binding. Moving governance into that layer is the difference between a policy that lives in a document and a policy that lives in the path of every action.

A Working Example

To make this tangible, I built a small working example of a data governance agent team.  You can find the recording of the demo here.

I want to walk you through the behavior, because that is the point and the argument. It is an illustrative reference implementation, not a production system, but the reasoning in it is real, and the code is freely available (link at the end).

The premise is a control plane around changes to data. Two kinds of change flow through it.

• The first is a synchronous gate: when someone proposes a change to a data structure, adding a column, dropping a constraint, the change is evaluated before it is allowed to proceed, the same way a pull request is checked before it can be merged.
• The second is an asynchronous monitor: data also arrives outside any orderly change process, a file lands, a vendor feed updates, someone edits a table by hand, and those changes have to be caught after the fact.

A complete control plane needs both. The gate governs what comes through the front door; the monitor watches the windows.

When a change appears, a team of agents evaluates it. Each agent has a narrow, explicit job, and each is defined by a contract: what it is authorized to examine, what data it may access, the guardrails it operates under, the condition that triggers escalation, and its obligation to log its reasoning.

That contract structure is exactly how I argued governance work should be delegated to machines. The team I built has five members:

• A Classification & PII agent that detects personal data in a change and enforces the rule that PII cannot exist without the protections policy requires.
• A Data Quality agent that checks whether a change preserves the quality rules and constraints already in force.
• A Policy & Jurisdiction agent that evaluates a change against security, sharing, retention, and cross-border rules.
• An Assignment & Steward agent that resolves which human owns a change or an escalation, across the compliance, technical, and business dimensions.
• A Relationship & Lineage agent that traces how a change propagates to related assets and whether sensitivity is inherited across those relationships.

These five agents, the policies, and the routing are not three separate things sitting side by side. They are a single mechanism, and the relationships between them constitute the whole design.

• Policies define what must be true: PII cannot exist without its protections, retention cannot fall below a floor, and a cross-border transfer needs a lawful basis. But a policy in a file does nothing on its own.
• An agent contract is what gives a policy force. Each agent is bound by its contract to enforce a specific subset of the policies, within a stated authority and with a defined escalation point.
• The decision-rights matrix is what connects the two to the actual change: from an asset’s state, attributes like contains PII or crosses jurisdictions, the matrix determines which agents have authority over this change, which in turn determines which policies come into play. The same matrix, when an agent escalates, determines which human steward owns the decision.

So the chain runs cleanly in one direction: The state of an asset selects the agents, the agents carry the policies, and the policies define the verdict, with the matrix also holding the answer to who decides when a machine should not.

Every evaluation ends in one of three verdicts: pass, block, or escalate.

• Pass is the routine majority. The change is fine and proceeds with no human involvement.
• Block is a clear violation. The change is stopped, and the reason is logged.
• Escalate is the interesting one. It means the agents have hit something that genuinely requires human judgment, so instead of guessing, they name the responsible steward, hand over everything they have already determined, and hold.

That three-way split is not a technical detail. It is the 80/20 principle that runs through all of this. Roughly 80% of governance decisions are routine and can be resolved by machines. The remaining 20%, including jurisdictional judgment calls, novel situations, and decisions with real downstream consequences, is exactly where you want scarce human expertise focused. The control plane’s job is to handle the 80% cleanly and to route the 20% to the right person with the analysis already done.

The Point Most People Miss: What Is Deterministic and What Is Not

Here is the critical part that causes a lot of anxiety about letting AI make governance decisions.

In this example, two very different things are happening, and they are designed to have opposite characteristics.

The routing is deterministic. Which agents evaluate a given change is determined by a decision-rights matrix that maps roles, assets, and the state of those assets. For instance, a change to an asset that contains PII and is consumed across jurisdictions wakes the Classification and the Policy & Jurisdiction agents. A change to a table with quality rules and a foreign key wakes the Quality and the Relationship agents.

This routing is rule-based, predictable, and auditable. Run the same change against the same matrix, and you get the same agents every time. There is no improvisation in the control logic.

The judgment is probabilistic. What each agent decides, for instance, is whether a field is really PII, whether a cross-border transfer has a lawful basis, and whether a quality change is acceptable, is genuine reasoning performed by a language model. It is not a lookup. It can consider nuance and surprise you.

Now notice why this division is exactly right. People worry about AI making governance decisions because they imagine the whole system behaving unpredictably. But you do not want emergent, improvised behavior in your control logic.  You want the routing of authority to be deterministic and rule-bound.  That is what the decision-rights matrix gives you.

The probabilistic reasoning is confined to the place where judgment is actually required: the verdict on a specific, routed question. The control plane is deterministic about who decides what, and probabilistic only within each bounded decision.

Governance leaders should find that reassuring, not alarming. It is the opposite of an unpredictable system; it is a predictable system with judgment applied precisely where judgment belongs.

Audit Trail and Log for Every Governance Decision

There is one more capability worth calling out, because traditional governance has always promised it and rarely delivered it: traceability.

In the example, every evaluation produces a relationship path that is a record of the asset that changed, the state attributes that triggered routing, the specific agents that were invoked (and, visibly, the ones that were not), the policies each agent weighed, the verdict, and the steward who was assigned. That path is stored with every entry in an audit log, and any past decision can be reopened and replayed as the exact route it took.

This is what auditability looks like when governance is a control plane rather than a committee. The question, “Why was this blocked?” has a precise, visual, replayable answer. The connective tissue between policy, data, agent, and outcome is not implied.

The Step Before the Agent Team Is Invoked: State Resolution

There is one complication I’ve not raised yet, but may be obvious to the astute reader. There is actually a third element that sits upstream of both the deterministic routing and probabilistic agent reasoning.

Before the decision matrix can route anything, something has to establish the state attributes it routes on. What I mean by state attributes is whether the asset contains PII, which jurisdictions apply to it, what its data quality characteristics are, etc.

Determining those attributes is partly a judgment call, which means the fuller picture involves probabilistic reasoning at two points, not one: probabilistically resolving an asset’s state, then routing on it deterministically, and finally rendering a verdict probabilistically.

This second, upstream probabilistic determination of state attributes is out of scope for this column and demo. In the demo, those attributes arrive already settled: The scenarios declare them. In a real enterprise, that has to be established first by examining the data’s content and context. I call this layer state resolution.

State resolution is not one operation. Detecting whether a field actually contains personal data means inspecting content. Determining jurisdiction, originating and consuming geographies, or cross-border consumption means drawing on context and lineage.

These are facts that are not visible in the data values themselves. Resolving this requires consulting the organization’s existing metadata and prior stewardship decisions. This is performed by two operations:

• Continuous collection of metadata
• Change awareness that notices when an asset has shifted

They feed into state resolution by supplying the raw signal. State resolution is the distinct step that turns that signal into the settled attribute set that the control plane can route on.

In my next column, I will expand the example code to demonstrate state resolution.

How to Make This Your Own

The example uses two tables, a handful of policies, five agents, and an invented set of stewards. None of that is the point. The architecture is the point, and it is deliberately built so that the governed parts are data, not code.  They are simply files you can read and change without touching the engine.

Adapting it to your enterprise means making three substitutions, each of which maps to something you should already have:

First, your policies. The demo encodes a small set – PII protection, usage, sharing, retention, cross-border, and quality. Yours are different and almost certainly more numerous. They live in a readable file that the agents consult; you rewrite that file to express your actual policy set.

Second, your agent roles. Five agents made sense for this illustration. Your governance may warrant a retention agent, a contractual-obligation agent, or an industry-specific compliance agent. Each is defined by the same contract shape with authority, scope, guardrails, escalation, and logging.  So adding one is a matter of writing its contract, not re-architecting the system.

Third, your decision rights. This is the heart of it. The decision-rights matrix encodes who is responsible for what, under which conditions.  It uses three dimensions of compliance, technical, and business, so that as an asset’s attributes change, or as people join and leave, responsibility re-resolves.

Your matrix should reflect the actual governance authority of your organization. Getting it right is most of the work, and it is work only your organization can do, because it is a statement of how you have decided to govern.

What does not change is the spine: a deterministic routing layer that decides who evaluates what, bounded probabilistic agents that render judgment within their authority, a three-way verdict that reserves human attention for the hard twenty percent, and an audit trail that makes every decision traceable. That spine is the control plane. Everything else is configuration.

Where to Get It

The full working example is on GitHub, including the agent contracts, the policy definitions, and the decision-rights matrix as readable files, along with the application that runs the agents and renders the relationship paths. You are welcome to clone it, run it with your own keys, and use it as a starting point. I built it to be read as much as to be run.  The governed data is meant to be legible, so you can see the whole argument as a set of files before a single agent fires.

github.com/jww316/data-governance-agent-team

If you would rather watch it run before setting it up yourself, I recorded a short walkthrough.

prenticegate.com/dg-agent-team-demo

And if you want the fuller treatment of where this is heading, the characteristics of autonomous governance, the decision-rights matrix, the role of stewards as supervisors rather than reviewers, that is what the book is for.

prenticegate.com/ag-book

What a Data Leader Can Take From This

We all have felt the pain and frustration of the data governance process. We know it is simply not sustainable given the pace of change, and we need something new.  The active governance control plane approach is a viable candidate and worthy of exploration and experimentation.