Part 2 of 3: Why telemetry makes the access problem worse
In the first post, we made the case that AI doesn't fail because it's not smart enough. It fails because it can't see. The large global retailer example showed what happens when an AI operates on a shadow of reality and fills the gaps with confidence. The fix isn't a better model. It's better access.
But "better access" means something very different depending on what kind of data you're working with. For e-commerce data, it's messy. For telemetry data, it's a different category of hard entirely.
Why is telemetry data a harder problem to tackle?
Every industry has an AI access problem. With telemetry, especially for IT and security, it becomes a liability.
Business data is messy. Telemetry is messier, and it doesn't sit in a warehouse waiting to be queried. It's fragmented across SIEMs, APM platforms, cloud providers, and edge infrastructure that were never designed to talk to each other, generated at a volume and velocity where seconds make a huge difference.
Then layer on the schema problem: OCSF, OTLP, ECS, custom formats, vendor-specific fields that almost mean the same thing but not quite. Every observability vendor wants to be the system of record. None of them are. You end up with a constellation of partial truths, each source authoritative for its own slice and blind to everything else. Normalizing across them isn't a query. It's a very complicated project.
And all of that is before you account for the noise. Telemetry systems generate it at scale by design. The signal you actually need is in there somewhere, and finding it fast, across all of those fragmented and inconsistently-schemed systems, while an incident is actively unfolding, is the entire game.
When something goes wrong (something always goes wrong) your AI is working with partial data, stale signals, and missing context across systems it was never designed to unify. That's not a model failure. It's an access failure that shows up as a model failure, which is why everyone is super focused on finding a fix to this side.
The integration trap most teams don't see until they're already in it
When an AI agent needs to pull telemetry, it has two real options:
Option A
Integrate directly with every system. Handle each API, each auth model, each schema. Normalize and correlate across sources at query time. Hope you didn't miss anything. Repeat for every new system you add.
Option B
Query once. Get structured, scoped, relevant results from a layer that's already handled the federation, normalization, and access control.
Option B is obviously better. So why does almost everyone end up at Option A?
Because Option B requires someone to build and maintain that layer, and most organizations treat telemetry access as an integration problem to solve later, not an architectural decision to make upfront.
So agents get built with direct integrations. Those integrations work well enough. Technical debt accumulates. Then you add a second agent, and a third, and suddenly you have a spider web of direct system connections where every agent has its own slightly different view of reality.
Every agent you add after that is borrowing against a foundation that was never built to hold it
Control through restriction doesn't scale
The current response to agentic AI in security is mostly about restriction. Lock down what agents can access. Approve every integration. Build the walled garden.
The problem is agents optimize for getting the job done. If the approved path is slow, incomplete, or friction-heavy, agents and the engineers building them will route around it. The workaround becomes the workflow before anyone notices
You can't control your way to a good agentic architecture. What you can do is make the right path so effective that bypassing it becomes the harder option. Make federated, governed, normalized access so fast and so complete that direct integrations offer no real advantage.
The shift is from control-through-restriction to control-through-abstraction. Not locking the doors, but making the front door good enough that nobody goes looking for a window.
Building the front door people will use
It means agents query a single layer that handles federation across every source, SIEM, APM, object storage, edge, without forcing data to move before it's needed. Schema normalization happens at query time, not as a preprocessing tax on data you may never use. Every query is scoped, auditable, and policy-enforced. You know what was accessed, by which agent, and why.
As your stack evolves, agents don't accumulate new integrations. They query the same layer, which means one fewer place for reality to get misrepresented, and one fewer seam where something can be exploited.
This is an architecture problem that tends to get outrun by momentum. Teams move fast, agents get built, Option A becomes the foundation before anyone made a deliberate call about it. Every agent you add after that makes it harder to course correct
This is why you need AI-first architecture.
