Last week, I watched an AI agent confidently create a database field called jira_key. The same system already had fields called jira_issue, tw.jira_issue, and issue_key. All storing the same thing.
The agent didn't know. It couldn't know. It had no memory of what came before.
This is the dirty secret of AI agents in 2026: they're getting more autonomous, but not more aware.
The Guardrail Illusion
Everyone's talking about AI safety. Guardrails. Prompt injection prevention. Jailbreak resistance. And those matter — I'm not dismissing them.
But here's what nobody's talking about: what happens when your AI agent does exactly what you asked, a hundred times, and each time it makes slightly different decisions?
Not malicious decisions. Not jailbroken decisions. Just... inconsistent ones.
- Monday's agent names the field
customer_id - Tuesday's agent names it
clientId - Wednesday's agent names it
cust_identifier
Three different sessions. Three different LLM instances. Zero shared memory. Each one "correct" in isolation. Together? A mess that compounds daily.
Guardrails stop agents from doing bad things. But they don't help agents do the same things. And in enterprise operations, consistency isn't a nice-to-have — it's the foundation of trust.
The Registry Drift Problem
Here's a concrete example from our own work.
We run AI agents that modify code, create services, update configurations. Every change is legitimate. Every change is reviewed. But we noticed a pattern:
The agents were creating drift.
A new tool gets added to the codebase — but nobody updates the tool registry. A new service starts running on port 9005 — but the port allocation map still thinks 9005 is free. A config file changes — but the schema documentation doesn't know.
Each agent session operates in isolation. It makes changes. It commits them. It moves on. But it has no concept of "I just changed something that other systems depend on."
This isn't a bug. It's the architecture. LLMs are stateless by design. Every session starts fresh. That's a feature for creativity. It's a disaster for governance.
AI agents are excellent at discovery — reading the current state of things. They're terrible at enforcement — ensuring their changes maintain consistency with everything else. Discovery without enforcement is just sophisticated chaos.
Governance Is the Missing Layer
What we needed wasn't more guardrails. We needed governance.
The difference?
- Guardrails say "don't do X"
- Governance says "when you do X, here's how we do it, and here's what else needs to happen"
Guardrails are binary. Governance is procedural. Guardrails block. Governance coordinates.
So we built something. We call it registry drift detection — but the principle is universal.
Every time an agent session ends, we analyze what changed. Not just "what files were modified" — that's table stakes. We ask:
- Did this session add a new tool? If so, does our tool registry know about it?
- Did this session touch files that are indexed in our knowledge graph? If so, is that graph now stale?
- Did this session change a configuration? If so, do we need to validate the schema?
- Did this session allocate a new port? If so, does it conflict with something else?
The agent doesn't have to remember these rules. The governance layer does. And it runs at session boundary — the moment between "agent did something" and "changes are permanent."
Defense and Offense
But wait — there's a second problem we hadn't considered.
We'd already built what we called "DiscoveryGuard" — a gate that prevents agents from touching project files without first understanding the project. You want to modify InvoiceController.php? First, prove you've read the project registry. Know what you're dealing with.
That's defense. It ensures agents read before they write.
But what about the reverse? What about ensuring the registry stays current when agents change things?
That's offense. It's the other half of the equation. And almost nobody's building it.
Most AI governance focuses on inputs: what can the agent see, what can it access, what can it execute. Almost none focuses on outputs: what does the agent change, and what are the downstream effects of those changes?
We discovered this gap because we eat our own cooking. We use AI agents to build our own systems. When your agents create the very infrastructure that governs agents, you notice the gaps fast.
What Governance Actually Looks Like
Let me be concrete about what we implemented:
1. Session-Scoped Drift Detection
At the end of every agent session, we scan the git diff — not the whole codebase, just what changed. We look for patterns: new tool decorators, new port bindings, config file modifications, changes to indexed directories. Each pattern triggers a drift check against our central registry.
2. Auto-Fixable vs Manual Review
Not all drift is equal. Adding a new tool to the registry? That's mechanical — auto-fixable with a single command. Changing a config schema? That needs human eyes. The governance layer categorizes drift and routes it appropriately.
3. Wrap-Up Enforcement
The session can't truly "end" until drift is addressed. Either the registry updates are applied, or the human explicitly acknowledges the gap. No silent rot.
4. Audit Trail
Every drift detection, every resolution, every bypass — logged. When something breaks in three months, we can trace back to exactly which session created the inconsistency and why the governance layer didn't catch it (or did catch it and was overridden).
The Bigger Picture
This isn't just about keeping registries in sync. It's about a fundamental shift in how we think about AI systems.
The old model: Train model → Deploy model → Monitor outputs
The new model: Train model → Deploy model → Govern lifecycle → Learn from governance → Update decisions → Repeat
The governance layer isn't just catching mistakes. It's generating signal. Every time drift is detected, that's a data point. Every time an agent creates a new pattern, that's a candidate for a new rule. Every time a human overrides the governance layer, that's a potential gap in the rules themselves.
Over time, the system gets smarter. Not because the LLM is smarter — the LLM is still stateless, still amnesiac, still starting fresh every session. But because the governance layer accumulates institutional knowledge that persists across sessions.
We're not trying to make AI agents remember everything. That's a losing battle against architecture. We're building the institutional memory that sits outside the agent — the accumulated decisions, patterns, and rules that get injected into every session and enforced at every boundary.
What This Means for Your AI Strategy
If you're deploying AI agents in your enterprise — and you probably are, or will be soon — ask yourself:
- What's your governance layer? Not your guardrails. Your actual governance. The thing that ensures Tuesday's agent and Wednesday's agent make consistent decisions.
- Who owns the registry? When your agents create things — services, fields, endpoints, configurations — where is the canonical source of truth? And who updates it?
- What happens at session boundary? When an agent session ends, what validation runs? Is it just "did the code compile" or is it "did this session maintain consistency with everything else in the system"?
- Where does institutional knowledge live? If your best developer quits tomorrow, their knowledge walks out the door. If your AI agent's session ends, its context disappears. What persists?
These aren't theoretical questions. They're operational ones. And the companies that answer them well will be the ones whose AI systems actually improve over time — instead of slowly, silently, drifting into chaos.
The Future Is Governed
The AI models will keep getting better. GPT-5, Claude 4, whatever comes next — they'll be smarter, faster, cheaper. That's table stakes.
The differentiator won't be which model you use. It'll be how well your governance layer ensures that model operates consistently within your institutional context.
Because an AI that's 10% smarter but creates 50% more drift is a net negative. And an AI that's "just okay" but operates within a tight governance framework is worth its weight in gold.
Guardrails stop agents from going rogue. Governance ensures they go right.
Build both.
