“AI-ready” is everywhere right now, attached to nearly every product in every category. The catchy label rarely means anything specific, just as additional questions are warranted when vendors claim to be “AI-native”. After fighting through all the marketing jargon, there needs to be a standard, not a slogan. And the definition changes depending on what the data is for. AI-ready for a data warehouse and AI-ready for live operational telemetry are not the same problem.
Telemetry data has enormous untapped value, and every vendor selling AI security is leading with the same claim: our model is smarter. But a smarter model reading disorganized data just hallucinates faster on a bad day. On a good day, it burns through massive amounts of tokens, adding structure to unstructured data. The real question isn’t how intelligent your agent is. It’s whether your telemetry was built for an agent to consume in the first place.
What makes telemetry AI-ready?
AI-ready telemetry isn’t defined by a single property. It’s six dimensions, each building on the last, that together define whether a telemetry data lake is ready for the agentic workflows already arriving. Not a feature bolted on top of your security and observability stack, but a standard for the data underneath it. We believe these six properties define AI-ready telemetry:
- Unified: Data lives in one queryable plane.
- Normalized: Data has a consistent structure and meaning.
- Correlated/contextualized: Signals are connected to each other and enriched with the knowledge needed to understand them.
- Current: Data is available when you need it, across recent and historical timeframes.
- Investigable: The platform can turn data into useful answers, not just return raw results.
- Accountable: AI reasoning and actions can be understood, governed, and traced after the fact.
The challenge is magnified because operational telemetry doesn’t sit still. Metrics, events, logs, and traces, sometimes referred to as MELT data, are generated continuously by systems that have no idea an AI agent might read them later, in volumes and formats nobody designed for machine consumption. And increasingly, the AI reading this data isn’t retrieving a fact for a chatbot. It’s diagnosing a live incident, investigating an active threat, and in a growing number of deployments, taking action with real consequences.
Here’s what each feature looks like in practice.
Unified: One plane to rule them all
The first requirement is the most basic and the most commonly failed: logs, metrics, traces, and security events need to live in a single, queryable plane, not four separate tools that someone or some agent has to manually cross-reference. Even with the advances of federated search, robust APIs, and MCP-enabled workflows, leaving critical data scattered across silos in different formats is not the ideal end state. When you have to trust the agent to piece together the bits of data it thinks it needs to solve the problem, the risk of it getting that wrong doesn’t disappear. It just gets harder to catch.
Picture a mid-sized fintech’s on-call engineer during an incident. The error rate metric is in one dashboard, the logs are in a second tool, the trace data lives in a third, and the security events sit in a fourth system entirely. No one is at fault in this scenario. Each tool may be perfectly good at its job. But during an incident, the engineer’s job becomes tab-switching and mental translation, not investigation.
An AI agent facing the same fragmentation doesn’t magically become smarter than that engineer. It just fails faster because it can’t see the parts of the picture living in systems it can’t access.
The Open Cybersecurity Schema Framework and services like AWS Security Lake exist specifically because the industry recognized that security and operational data scattered across dozens of vendors was becoming unmanageable. Now, more than 50 vendors integrate with Security Lake alone, each contributing one more format that needs reconciling. The instinct to unify is now industry-wide, not a Sumo Logic opinion. In the age of operating at machine speed and machine scale, it’s non-negotiable.
Unified doesn’t mean one vendor for everything. It means one place where the question “what happened?” can be asked across all of it at once. And if that unified data lake also has a unified entity model and unified institutional memory, agents don’t just have the data. They have the context required to reason responsibly.
Normalized: Structure applied automatically, not manually
We touched on this above, but it deserves its own pillar. Getting everything into one place solves half the problem. The other half is that raw telemetry is a mess of inconsistent formats.
Every application, every team, every era of infrastructure writes logs slightly differently, with no enforced schema. This problem is not new. As the famous XKCD comic captured, every time someone realizes there are competing standards, they get the brilliant idea to add yet another standard. Optimistically, with OCSF and ECS and broad industry buy-in, we may finally win the normalization battle… and even the war.
Strictly speaking, the pipeline has three distinct steps. Normalization means structure gets applied automatically at ingest, from parsing, to field extraction, to schema mapping, rather than requiring a bespoke integration project every time a new data source shows up. Somewhat counterintuitively, this matters more for AI than it does for humans: a person can eyeball a slightly malformed log line and infer what it means. A model reasoning over that same data needs a consistent structure to reason reliably, or it’s pattern-matching against noise. And even when it can reason its way through, it costs unnecessary token burn to get there.
Normalization isn’t a data hygiene project. Cleaning your data is proofreading a document for typos. Parsing and normalization are translating documents written in five different languages into one shared language. When field names vary across sources, an AI agent has no reliable way to distinguish the actor from the target.
One firewall log stores source and destination IPs in different fields, sometimes unlabeled. The cloud audit log calls the person who performed the action userIdentity.arn; the endpoint log calls them TargetUserName. Without a normalized schema, an agent investigating a lateral movement alert can swap the attacker and the victim, correlate the wrong user with the wrong asset, or flag the destination as the source of compromise.
The main concern here is that it won’t correct the mistake. It will present it with full confidence, and the analyst will act on it. Now multiply that across every log source where “who did what to whom” is expressed differently, and you have a platform where AI isn’t accelerating investigations. It’s manufacturing plausible, well-formatted wrong answers at machine speed. Normalization means every source maps to one schema before any agent touches it, so ‘src’ always means source, ‘dst’ always means destination, and actor always means the entity that initiated the action, regardless of which vendor’s log it came from.
Correlated and contextualized: Signals linked across type and system
Having unified and normalized data gives an AI agent access to the pieces. The next challenge is helping it understand how those pieces fit together. That requires both correlation and context.
Correlation connects signals that share a causal relationship across your telemetry. A trace ID links to the log lines it generated, which link to the metric anomaly they explain. An investigator, human or AI, can walk the chain from symptom to root cause instead of assembling it by hand. Correlation answers the question: what happened, and what caused it? Everything it needs already exists somewhere in the data stream. The problem is finding and linking the pieces.
Context is the knowledge that doesn’t exist in the data stream at all. It’s the fact that this server is the CFO’s laptop. That an IP range belongs to a contractor who was offboarded last Friday. That a service is mid-migration, and the team expects elevated error rates through Thursday. That an alert pattern was investigated twice last quarter and closed as a known false positive both times.
In the old world, this knowledge lived in an analyst’s head, in a Slack thread, on a wiki page nobody updated, or in a hallway conversation between two engineers who happened to be getting coffee at the same time. It was real, it was critical, and it was completely invisible to every automated system in the building.
The distinction is worth acknowledging because an AI agent that can follow a trace span to the log error that caused it, but doesn’t know the affected service is in a planned maintenance window hasn’t solved the investigation. It’s produced a technically accurate, operationally useless alert. An agent needs both, which means the platform has to surface both: causal links across telemetry for correlation and organizational knowledge such as asset ownership, business criticality, change schedules, historical investigation outcomes, and threat intel enrichments, encoded in a structure the agent can query, not trapped in someone’s institutional memory.
Current: Reflecting what’s happening now, not what happened earlier
Picture this: you’ve identified a significant security issue after a threat hunt. One of the key entities involved has been seen in your estate for the past six months. If it’s been there six months, what about further back? Unfortunately, you’ve only got six months of retention that you’re actively paying for. Anything older is stuck in a frozen state, an archive maybe, or just a colder data tier.
You have to rehydrate this data before you can even begin a search, but with the volume you have to go through, that’ll take a while. You’re stuck, hands tied, because you can’t do the analysis you need. Incidents now unfold faster than any human can follow. The data that explains them can’t be sitting in cold storage waiting to be thawed, because by the time you melt the M.E.L.T. glacier, the attacker has moved.
Latency is usually framed as a real-time problem: how quickly new events become queryable after they happen. But there are two types of latency:
- Ingestion latency: How quickly new data becomes available.
- Historical query latency: How quickly you can search data that already exists..
An agent investigating a compromised service account doesn’t just need the last hour of authentication logs. It needs to establish whether this account has exhibited similar behavior over the past year, whether the same IP appeared in a different context six months ago, and whether the entity’s access patterns drifted gradually or changed overnight. If answering those questions requires a lengthy rehydration job, the agent’s investigation stalls at exactly the point where historical context would have been the turning point.
For an AI agent building an investigation timeline, both real-time ingestion latency and historical query latency are equally critical.
Within reason, data should be accessible at all times. Having an aggregated view of all your telemetry and sources, across any time frame, is essential to understanding behavioral patterns among the agents, humans, and machines generating more activity in today’s environments. This is where the concept of a cloud-native security and observability data lake is resonating with executive and operational teams alike.
You want your AI agents to make recommendations based on all of your data, not just the tip of the iceberg. More complete data, more accurate answers, more timely remediations.
Investigable: Built to produce answers, not just store data
The first four pillars describe properties of the data: unified, normalized, correlated and current. You can verify each one by looking at the data without knowing anything about the platform serving it.
Investigable is different. It’s about what happens when someone or something tries to use the data. One could argue that if you nail pillars 1 through 4, investigability is just the natural outcome. It absolutely isn’t. You can have a perfectly unified, normalized, correlated, real-time dataset sitting behind a query engine that takes 45 seconds to return results, returns 10,000 unranked results, has no concept of scoping by entity, and offers no way to ask a follow-up question informed by the first answer.
The data is flawless. The investigation experience is useless. Anyone who has ever used a beautifully architected data warehouse with a terrible BI tool has lived this exact problem.
Think of pillars one through four as the recipe and pillar five as the oven. A bad oven ruins a perfect recipe every time, and no amount of ingredient quality compensates for it. For mature customers, the oven is often where AI agent deployments actually fail today. The model can reason. The data is there. But the platform or AI harness can’t serve the right slice of it fast enough, scope it tightly enough and attach enough context for the agent to do anything useful with it in the time the investigation demands.
At the platform level, investigable requires:
- Entity-scoped queries that return a timeline, not a result set.
- Pre-correlated context attached to every answer so the agent doesn’t need a second round trip to understand what it’s looking at.
- Ranked relevance so the first result is the most likely answer, not just the most recent match.
- Response times that fit inside an agent’s reasoning loop, not a human’s patience for a loading spinner.
The difference between a platform that stores data well and one that is investigable is the difference between a library and a research assistant. Both have access to the same books. One of them hands you the open page.
Accountability and reasoning
The last pillar becomes crucial the moment an AI agent moves from suggesting an action to executing one. Or in the language of the operating model: from human in the loop, to human on the loop, to human out of the loop entirely.
A recommendation engine can be wrong without much consequence. An agent with production access that acts autonomously is a different matter. Its reasoning and its actions need to be reconstructable after the fact, not as a compliance afterthought but as an operational requirement.
This is squarely where the industry’s attention has landed: analysts researching enterprise technology leadership have identified “enabling and protecting AI” as the top priority for security leaders this year, with an emphasis on proving control over agentic risk rather than simply asserting it exists. Separate research into engineering leadership finds that the large majority of technology leaders already see AI agents as a growing security risk precisely because of the breadth of access they’re granted relative to the oversight applied to them. The recent Hugging Face incident is an example of this. Some analysts project that, by the end of the decade, a meaningful share of enterprise security incidents will trace back to AI agent misuse specifically, rather than to traditional attack vectors.
Accountability also means the trail left behind by everything your agents do. Access governed at the platform level rather than by convention. A durable, queryable record of what any agent saw, what it decided, and what it did, separate from the action itself, so that six months later the question “why did this happen?” has an actual answer. And critically, it means a feedback loop. If a mistake happens once, that’s on the AI. If the same mistake happens twice because nobody retrained the model or refined the prompt, that’s on us. Accountability isn’t just the audit trail. It’s the system that makes sure the trail is read and acted on.
What meeting the bar actually looks like
This framework describes what the Sumo Logic Platform is engineered around, and we are our own first customer. Our SOC uses our agents to secure our app and infrastructure. Mobot, the SOC Analyst Agent, and a broader team-of-agents architecture depend on these six pillars. They don’t work without them. No agent does.
Mobot’s ability to investigate across logs, metrics, and traces in a single conversational flow only works because the underlying platform treats them as one unified, normalized surface rather than three separate products glued together after the fact. When it walks from a metric anomaly to the specific log line and trace span that explains it, that’s correlation doing the work. When it knows that the affected service is owned by a specific team and was deployed two hours ago, that’s context doing the work.
And as the SOC Analyst Agent moves from surfacing findings to acting on them, accountability stops being an abstract principle and becomes the thing that determines whether that autonomy is actually defensible before a security team, an auditor, or a board.
The AI landscape will keep shifting. Models will get faster, cheaper, and more capable. Agents will multiply. The vendors building them will come and go.
But the platforms that survive will be the ones that got the data right, because data outlasts every model trained on it, every agent that reasons over it, and every vendor that claims to have made it smarter. The six pillars aren’t a moat against competitors. They’re the foundation that makes everything built on top of them trustworthy. And in security operations with AI, trust is the current battleground.
See how Sumo Logic does this in action. Request a demo.
