Why AI agents can’t find the data they need

A specific failure mode keeps appearing in autonomous network operations pilots, and it rarely gets discussed because it is unglamorous.

It has nothing to do with model capability, prompt architecture or agent design. The agent cannot find its data. It is like a surgeon who has trained for a decade but cannot find the operating room. The capability is real. The outcome is failure. And the reason is infrastructure, not intelligence.

What data discovery looks like today

Ask a data engineer at any major operator how a new team discovers what data exists. The answer is consistent: They ask someone, a Confluence page, a spreadsheet, a Slack channel. It works, slowly, because there are humans on both sides with enough shared context.

Agents cannot ask someone. They cannot wait two days for a reply or judge that an opaquely named table last updated by someone who left in 2023 is probably the right one. Without a programmatic way to find data, an agent either refuses the task or proceeds on incomplete context, producing output that looks authoritative but is not. The second outcome is the dangerous one.

The metadata gap

Discoverability depends on metadata: the structured description of what each data asset is, where it lives, how to query it and what it means. In most operators’ environments such metadata exists but not in a form that serves agents.

In self-healing and self-optimizing telecoms networks, counters are the foundation of network telemetry. They track digital events and feed data into AI decision engines.

A counter name like “pmHoExecLteInterF” encodes real meaning: handover execution attempts, LTE inter-frequency, Ericsson radio access network (RAN). That meaning lives in vendor PDFs, informal data-team notes and the brains of engineers who have worked these systems for a decade. It is real knowledge that is almost entirely inaccessible to an agent.

And the gap runs even deeper than counter names. What is the valid range for this counter? What is normal for a dense urban macrocell versus a rural small cell? A senior engineer answers from experience. An agent needs the answer in structured, machine-readable form.

The layers of agent-ready metadata

Agents need metadata across four layers, and all of them matter:

• Technical metadata (schema, data type, granularity, storage location) tells an agent how to access and parse a dataset. Most operators have this partly in place.
• Operational metadata (quality score, freshness, completeness, last collection time) tells the agent whether the data is usable right now. Operators can usually reconstruct it but rarely expose it at query time.
• Semantic metadata tells the agent what the data means – for example, what a counter measures, how to aggregate it, and how it relates to service quality and to other vendors’ equivalents. This is the layer almost universally absent in machine-readable form.
• Lineage records where the data originated, what transformations it passed through and what depends on it. For an agent whose recommendation triggers a configuration change, lineage is the evidence that the data was what it claimed to be.

Technical metadata without semantic metadata is a filing system without labels: The agent finds the data but cannot interpret it. And when something goes wrong, the question is what data the agent used and whether it was valid.

With lineage, an agent can be audited; without it, it cannot. Lineage is not a governance formality. It is how autonomous operations stay accountable.

What agent-ready infrastructure looks like

In practice, agent-ready means metadata an agent can query at runtime, not read in a Confluence page or spreadsheet. It is versioned so that when a vendor release changes what a counter means, agents know which definition applies to which time window. It is also complete, current and linked to quality: all four layers present for every field in scope, kept up to date automatically rather than by a data-engineering sprint, with each asset’s quality status attached so an agent knows whether to trust it.

The catalog as active infrastructure

A catalog built for agents is not a directory but active infrastructure. It discovers assets, indexes their metadata, tracks lineage, monitors quality and exposes all this to agents at the speed of a network operation, not a human data team. The catalog is the difference between a library and a librarian: One holds the knowledge, while the other finds it and returns the context that makes it useful.

So, the question for operators is not whether to invest in metadata and catalog infrastructure. It is whether to invest in it before building agents so that the benefits can be achieved across every use case, or after, which means rebuilding the agents that were designed in its absence.

The data is already there. The question is whether your agents can find it.