Home The signal Anatomy of an agent Reference architecture Risk-Tiers Guardrail stack Governance in action Best practices Standards and crosswalk Implementation From the field Roadmap Companion toolkit Straight answers Glossary References
10 · From the field

What a master data program taught me about agent governance

I spent several years delivering a multi-domain master data and data quality program: customer, membership, certification and product, across roughly a dozen source systems, built domain by domain from proof of concept to production.

THE MDM PROGRAMME AGENT GOVERNANCE Cross-reference tableswhich record is which customer Agent registry + decision logwhich agent did what, for whom Trust framework weightsa dial, not an argument Autonomy tiers earned on evidencea dial, not a veto Six tools, five consolesstewards worked around it Consolidate the operator viewfive tabs means nobody checks 24-hour freshness ceilingapps built local caches Control-plane latency budgetslow governance gets bypassed GOVERNANCE WORKS WHEN COMPLYING IS FASTER THAN AVOIDING
THE PARALLEL

Identity was the whole problem then, and it is now

The program's hardest work was not the pipelines. It was deciding which record represented which real customer, and keeping that decision stable as a dozen systems argued about it. Cross-reference tables and survivorship rules existed so that any downstream question could be answered with "this record, from this source, at this time, by this rule."

Agent governance asks the same question about actions. Which agent did this, on whose authority, using which entitlement, at what time. The agent registry and the decision log are the cross-reference table of the agentic era. Build them first, for the same reason.

THE PARALLEL

Trust scores beat binary rules

That program used a trust framework where each source system carried a confidence weight per attribute, set by hand in workshops with the business. It was slow to configure, but it turned an unwinnable argument about which system was right into a tunable dial.

Agent autonomy tiers work the same way. Binary allowed-or-not governance produces either paralysis or shadow adoption. A tier that an agent earns through evidence, and can lose, gives the business a dial instead of a fight.

THE LESSON

Console sprawl is a governance failure

Stewards on that program worked across six tools and five consoles to resolve one record. Each tool was defensible on its own. Together they made the daily job slow enough that people worked around the process, which is exactly what governance is supposed to prevent.

The same risk sits in front of agent platforms today: one console for identity, another for policy, another for traces, another for evals, another for cost. Consolidate the operator view early. If checking an agent takes five tabs, nobody checks.

THE LESSON

Design for the constraint you will hit

That hub loaded daily, which put a 24-hour ceiling on freshness. Applications that needed real-time reads ended up with their own local caches. The architecture was correct for its era and its constraints, and the workaround was a rational response to a real limit.

Agent platforms hit the same shape of constraint through latency. If the governed path adds seconds to every tool call, teams will build a faster ungoverned one. Budget the control-plane latency as a design requirement from the start.

The transferable point. Governance succeeds when it is faster to comply than to avoid. That was true of stewardship workflows a decade ago and it is true of agent platforms now. Every control in this architecture is designed to be cheaper to use than to route around.

Where would you start?

If you are standing up an agent platform, tightening the controls on one you already have, or preparing for an audit that now includes agents, I am happy to look at it with you.