Crossing the Data Divide: Data Governance Agent Team Working Example (Part 2)

In my last column, I introduced a working example of a data governance agent team. The basic idea was that governance should stop being something humans periodically review and start becoming an operational control plane that sits directly in the path of activity.

The example used a deterministic decision-rights matrix to decide which governance agents should evaluate a change. Those agents then used probabilistic reasoning to determine whether the change should pass, be blocked, or be escalated to a human steward.

I was pretty happy with the example, but it was only half of the solution.

The decision-rights matrix only works if it already knows something about the data’s state. Does the asset contain PII? What geography is involved? Is data moving outside the company? What is it being used for?

In the example, I simply supplied those attributes as part of the test scenarios.

That was fine for demonstrating the control-plane architecture, but obviously that is not how an enterprise works. Something has to determine those attributes first.

That “something” is the subject of Part 2. I call it state resolution.

Before You Can Govern Something, You Have to Know What Is Happening

That sounds painfully obvious, but it turns out to be a much more interesting problem than simply looking up metadata.

Consider a customer email address stored in a CRM system. Nothing particularly exciting is happening while it sits there. It has a classification, an owner, a location, some access controls, and a business purpose.

Now copy exactly the same email address to a marketing SaaS platform operated by an external company in Germany.

The value didn’t change, but almost everything that matters from a governance perspective may have. It may now be outside the company, in another geography, under a different processing relationship, available to different people or systems, and used for a different purpose.

That led me to an idea that became increasingly important as I worked through the example:

The data does not have to change for its governed state to change. Context is part of the state.

In fact, the data does not even have to move. If access to an existing customer dataset is expanded from customer service to marketing, the values may remain in exactly the same database, on exactly the same server, in exactly the same country. The governed state still changed.

That distinction matters if we want machines to perform governance.

State Is Not Policy

I need to draw a line here because otherwise state resolution quickly turns into a giant AI agent that tries to do everything.

State describes what is true. Policy describes what must be true or what is permitted.

For example, “customer personal data is being transferred from the United States to Germany” is state. “Cross-border transfers of personal data must meet defined organizational requirements” is policy.

“The recipient is an external data processor” is state. “External processors receiving sensitive data must have an approved agreement” is policy.

“The processing purpose is marketing” is state. “Marketing use requires the appropriate authorization” is policy.

The state resolver should establish the facts. It should not quietly decide whether those facts are acceptable. That job still belongs to the governance control plane I described in Part 1.

This creates what I think is a useful division of labor:

State resolution asks: What is happening?

The decision-rights matrix asks: Who has authority?

The governance agents ask: Is it permitted?

Keeping those three questions separate is one of the most important architectural decisions in the expanded example.

A Working Scenario

Rather than turn this into a theoretical exercise, I expanded the working example from Part 1.

The scenario is intentionally ordinary. A U.S.-based CRM contains customer data used for customer service. A new API integration sends customer names and email addresses to an external marketing platform. The receiving environment is in Germany, and the integration supports outbound marketing.

The before state looks roughly like this:

Customer PII → internal CRM → United States → internal use → customer service

The after state becomes:

Customer PII → external SaaS provider → Germany → external processing → marketing

Once again, the customer information itself did not change. The context did.

The first thing the system sees is not all of that rich business context. It sees a technical event: an integration was created, with a source, destination, fields, API mechanism, description, and some technical metadata.

That event is evidence. It is not yet a resolved state.

Four Resolvers, Not One Giant Agent

My first instinct was to create one state-resolution agent and give it everything.

After thinking about it, I decided that was the wrong architecture. Instead, the example uses a small team of specialized resolvers.

The reasoning is similar to why I used specialized governance agents in Part 1. Narrow responsibilities make the system easier to understand, test, maintain, and audit. They also allow independent resolution work to happen in parallel.

The example currently uses four.

Classification Resolver

The Classification Resolver determines what kind of data is involved. In the demo, it resolves attributes such as whether the data contains PII and how it is classified.

For our CRM scenario, this one is easy. The enterprise metadata already says that full_name and email_address are personal information. There is no reason to ask an LLM to rediscover a fact we already know.

That is another design principle worth emphasizing: Just because reasoning models are available does not mean every problem should become a reasoning problem. If authoritative metadata exists, use it.

Location Resolver

The Location Resolver establishes where the data originates and where it is going.

The source-system metadata tells us the CRM environment is in the United States. Destination metadata tells us CampaignCloud is operating the receiving environment in Germany.

Again, those are facts. The Location Resolver does not decide which laws apply. That belongs to the Policy & Jurisdiction Agent downstream.

Recipient Resolver

The Recipient Resolver determines who or what is receiving or processing the data.

In this case, vendor and application metadata indicate that CampaignCloud is an external processor. That becomes another part of the routing state.

Purpose Resolver

This one is more interesting because most enterprises are considerably better at knowing where data is moving than why it is moving.

The integration might be named crm_to_campaigncloud_contact_sync. Its description might say, “Synchronize eligible CRM contacts for outbound campaigns.” The destination is a marketing automation platform owned by Marketing.

A reasoning model can look across that evidence and conclude that the most likely processing purpose is marketing. It can also attach confidence and explain what evidence led to the conclusion.

That is exactly the kind of work where probabilistic reasoning is useful.

The four resolvers can operate largely in parallel. One establishes classification, another location, another the recipient relationship, and another purpose. They are each responsible for a small piece of reality.

State Needs Provenance

There is another lesson buried in this design.

It is not enough for an AI system to say:

processing_purpose = marketing

Sooner or later, someone is going to ask, “Why?” If the answer is “the AI said so,” we have built ourselves a new governance problem.

Every state attribute, therefore, needs provenance. At minimum, I want to know the resolved value, confidence, evidence used, which resolver produced it, and when it was resolved.

For example, the Purpose Resolver might return:

Processing purpose: Marketing

Confidence: 96%

Evidence: integration description, destination application category, Marketing ownership

That does not make the result infallible. It makes it inspectable.

Governance does not require machines never to make mistakes. Human governance certainly does not meet that standard. It requires decisions and assumptions to be transparent enough to be reviewed, challenged, corrected, and audited.

Putting the Pieces Together

Once the specialized resolvers finish, their outputs go to something intentionally boring: a deterministic State Assembler.

I mean “boring” as a compliment.

The State Assembler does not reason. It validates the resolver results, normalizes the attributes into a common structure, derives simple facts, and compares the result with the prior state.

For the CRM scenario, the resolved state might look like:

• Contains PII: true
• Classification: personal data
• Origin: United States
• Destination: Germany
• Recipient: external processor
• Processing purpose: marketing

From that, deterministic logic can derive that the data is crossing a geographic boundary, the transfer is external, and the processing purpose has changed.

No AI is required to determine that the United States and Germany are different destinations or that an external processor represents an external transfer.

Use reasoning where reasoning is necessary. Use rules everywhere else.

The State Delta

The next step turned out to be more important than I originally expected.

Knowing the current state is useful, but also knowing what changed is often more useful.

The prior state of our customer data was personal data in the United States, used by an internal application for customer service.

The new state is personal data in Germany, held by an external processor, for marketing purposes.

That gives us a simple delta.

I think this is a better way to think about change awareness than continuously asking AI to reevaluate every piece of enterprise data.

The question is not, “What do we know about everything?”

The more useful operational question is, “What changed that might alter our governance obligations?”

That is a much more scalable problem.

Not Every Change Matters to Governance

This introduced another problem. Technology changes constantly.

A table may move to another server. A pipeline may be redeployed. A connection string may change. A process may generate a new execution ID.

If every technical event wakes five governance agents and an LLM, we will build something expensive, noisy, and probably unpopular.

That sounds suspiciously like traditional governance.

So the expanded architecture includes a governance materiality filter. Its purpose is simple: determine whether anything changed that could alter governance obligations.

For our scenario, the destination changed, the recipient type changed, and the purpose changed. All three are material.

If only the physical server name changed while classification, purpose, location, recipient, and access remained the same, the system could log the change and move on.

That filter should also be deterministic whenever possible. Organizations should define what state changes are governance-relevant rather than asking an LLM for an opinion every time a server moves.

This gives us another useful rule:

AI resolves ambiguous reality. Rules determine whether a known change is material.

Now Part 1 Takes Over

At this point, Part 2 connects directly back to Part 1.

The state-resolution layer hands the governance control plane something compact: the data contains PII, it is personal data, it is moving cross-border to an external processor, the purpose is marketing, and the change is material.

The decision-rights matrix can now do what it was designed to do. It deterministically determines which governance agents have authority over the event.

In this example, the Classification & PII Agent and Policy & Jurisdiction Agent become involved.

Now the governance agents can retrieve the additional evidence they need to make the decision.

That distinction between routing state and decision evidence is subtle but important. The state resolver needs to know that the purpose is marketing. The Policy Agent may then need to know whether marketing is an approved purpose.

Those are different questions.

In the demo, the organization has an approved vendor agreement and a data-processing agreement with CampaignCloud. However, the available evidence does not establish that customer data collected for customer service may also be used for marketing.

Now we finally reach the governance verdict.

The machine understands what is happening, the correct agents have been selected, and the relevant policy evidence has been examined. But the system cannot confidently establish that the marketing use is authorized.

So it does exactly what I want it to do.

It stops and escalates.

Two Completely Different Reasons to Escalate

Working through this example revealed another distinction I hadn’t originally considered.

There are actually two fundamentally different escalation points.

State-Resolution Escalation

A state-resolution escalation means the system cannot confidently determine what is happening. Maybe two credible sources disagree about whether a field contains PII. Maybe the purpose is ambiguous. Maybe no one knows whether the destination is internal or external.

In that situation, the governance system should not proceed as though the uncertain state were fact.

Governance-Decision Escalation

A governance-decision escalation means the system understands what is happening, but deciding whether to allow it requires human judgment.

Our CRM example falls into this second category. We understand the state. We cannot establish whether the new marketing purpose is authorized.

Those are very different problems, and they should not be hidden behind the same generic “human review required” message.

One is an inability to understand reality. The other is a limitation on machine authority or available policy evidence.

That distinction will matter a lot if autonomous governance ever operates at enterprise scale.

Perception, Authority, and Judgment

At this point, the overall model has become clearer to me.

An autonomous governance control plane needs three distinct capabilities.

Perception is understanding what is happening. That is state resolution.

Authority is determining who or what has responsibility for evaluating it. That is deterministic decision-rights routing.

Judgment is determining whether the activity is permitted. That is the work of the bounded governance agents applying policy and evidence.

Humans remain responsible for cases where the state cannot be resolved, or where machine authority should end.

This is a much more deliberate model than simply dropping an LLM into a governance workflow and asking it to “decide.”

And that is the point.

Metadata Becomes Operational

This also has a broader implication for data leaders.

We have spent decades collecting metadata. Most of that metadata has been used descriptively. It tells people what something is, where it came from, who owns it, how it relates to something else, and perhaps whether to trust it.

That is useful. But in the architecture I am describing, metadata begins to control system behavior.

A location attribute brings one agent into play. A recipient relationship invokes another. A change in purpose creates a material governance event. A classification affects whether activity can proceed.

That is a very different role for metadata.

It becomes operational context.

The value is no longer simply that humans can find and understand metadata. The metadata becomes part of the mechanism by which machines decide what work needs to be performed.

That is one of the things I was trying to get at when I wrote The Goal is Autonomous Governance, but reasoning models have made the architecture far more practical than I expected when I wrote the book.

The Expanded Control Plane

The fuller architecture now looks like this:

Continuous collection → Change awareness → Evidence gathering → Specialized state resolvers → Resolved state → State delta → Governance materiality → Decision-rights matrix → Governance agents → Pass / Block / Escalate → Human judgment where required

There is probabilistic reasoning in the architecture, but notice where it lives.

It is used where interpretation is required. The resolver team may reason about ambiguous evidence, and the governance agents may reason about a policy question. State assembly, materiality, routing, and authority remain deterministic.

That division is intentional.

We should use the flexibility of reasoning models without surrendering predictability where predictability matters.

Where to Get the Code

As with Part 1, the full working example is available on GitHub. I am extending the same repository rather than creating a separate project, so the Part 1 control-plane example and the new state-resolution capability live together.

The repository includes the application, agent contracts, policy definitions, decision-rights matrix, and the new state-resolution components and example configuration.

You are welcome to clone it, run it with your own model API key, inspect the configuration, and modify the scenarios for your own experiments. As with Part 1, I built it to be read as much as to be run.

If you want to see the original Part 1 demonstration before running the code, the walkthrough is still available here.

What I Think Data Leaders Should Take From This

I don’t expect data leaders to run out and build this exact architecture next week. This is still an illustrative working example.

But I do think it has practical implications.

First, start looking at your metadata differently. Ask whether it is merely documenting your environment or whether it is sufficiently structured, current, and trustworthy to drive action.

Second, pay attention to change, not just inventory. An autonomous governance system ultimately needs to understand what has changed in context and whether that change matters.

Third, separate facts from policies. If your policies are vague and your state is poorly understood, adding agents will simply automate confusion faster.

Fourth, think carefully about which decisions should remain deterministic and where probabilistic reasoning genuinely adds value.

Finally, do not interpret autonomous governance as removing humans from governance. The architecture does the opposite. It uses machines to collect, interpret, route, evaluate policy, and make routine decisions so human expertise can focus on situations that genuinely require judgment.

That was the original goal. What has changed is that we can now actually build it.