You can't ask questions of data you don't have. Neither can your agents.
Agentic telemetry
Agentic telemetry is telemetry managed for two audiences at once: the people who run systems, and the AI agents that increasingly run alongside them. It fuses human, machine, and AI context so that any authorized agent, person, or system can ask questions of any data, in place wherever it rests, at full fidelity.
Achieving agentic telemetry means we will have to change our underlying architecture. We will fail if we proceed as we have for the last couple of decades, assuming all the data must be in one place. For the entirety of my career, vendors have pitched a single pane of glass. It’s so prevalent it’s become a joke. What that’s meant, until now, is to give that vendor all of your data. Install their software end to end to collect, process, store, and analyze all of your telemetry. It’s an unachievable panacea. No single vendor will ever have the best of everything. Real enterprise telemetry architecture will always mean integrating many different systems. Instead of a single system the goal is to achieve a single lens on this data.
We call this an AI Platform for Telemetry. We want to have all of the capabilities required for a complete telemetry platform without mandating that those capabilities come from a single vendor. The platform offers collection, routing, shaping, storing, and analysis of all of an organization's telemetry. These components, however, are modular and integrated. None are mandatory, allowing you to mix capabilities from different providers. That means you can get data from any source. Store it in any store. Point any agent at it. Answer any question at a price point you can afford. And, most importantly, no lock-in. Your data is yours forever.
That distinction matters. Agentic telemetry is the category: the outcome customers need when humans and AI agents both produce and consume telemetry. An AI Platform for Telemetry is the architecture required to deliver it: open access, full-fidelity retention, search-in-place, context, observability, and governance. Cribl is one implementation of that architecture, not the category itself. Even if you choose not to use Cribl this is still the required architecture.
Cribl has been on this journey before. Seven years ago I wrote a post called The Observability Pipeline. We'd spent a year trying on names that didn't fit: log pre-processor; log processing engine; real-time log management. It was clear there was an emerging pattern, and putting a name to it helped solidify our industry’s perception. We’re seeing this again with agentic telemetry: repeated patterns at customers bringing together their telemetry data for human and agentic workloads. It’s time to have that same conversation again, this time about how we unify access to this data for people and machines.
We’ve been searching for names for this solution, and so far none of them have fit. AIOps (round two). AI SRE. AI SOC. Copilots. Agentic observability, which, depending on who you ask, means either AI agents acting on your telemetry or telemetry about your AI agents. When naming categories, it’s best to avoid meaning everything to everyone.
So once again, we’ll lay out the roadmap and vision for achieving agentic telemetry. We’ll define the terms, name the problems, and sketch the capabilities required to solve them. If the map is good, you should be able to build this yourself. (We'd love it if you built it with us. More on that later.)
For those of us who have been doing this long enough, we’ve seen all this before. We used to ssh and grep, then we centralized into platforms which enabled rich analytics, then fractured into a half dozen different purpose-built data stores with a pipeline in between them. The problems haven’t changed - we need to observe our systems to detect and root cause operational and security problems. But, how we’re solving them needs to evolve. It cannot mean centralizing all data storage behind one walled garden. It must mean democratizing access for humans and machines, with cost transparency and unified access.
Now, there’s a new consumer for telemetry. It’s not just humans trying to get control over massive amounts of telemetry while enabling and securing the business; it’s also machines riding alongside them. But this time it’s different: machines don’t sleep, don’t get tired of poring through data, and they ask a hell of a lot more questions than humans ever did.
For the rest of this post, I’ll attempt to answer why we need anything new at all, define some terms so we’re aligned on how I’m using them, describe the problems we’re seeing, and show how we recommend solving them. It’s a long post, so bear with me, but I think it’s worth the investment.
What’s new
Can’t we just point our agents at our existing tools? Surely your vendors are already showing these demos. It’s cool. The demos are awesome. But here’s the question we need to answer: "how do I make all of my telemetry usable by humans and AI agents alike, without any single vendor's agent getting a monopoly on my data, and without going broke doing it?"
What this is not: another copilot bolted onto a single vendor's datastore. It is not AIOps with better branding. It is not a mandate to centralize every byte in a new proprietary store. And it is not a license to let agents reason over telemetry without identity, cost controls, and audit. If the agent only sees one vendor's data, or if it can act without governance, it is not agentic telemetry in the sense I mean here. Economically, existing telemetry products in Infrastructure Monitoring, APM, SIEM, CSPM, DSPM, etc., aren’t set up to help you achieve agentic telemetry. They are priced with the presumption that value you are receiving comes from the solution itself, not simply getting access to the data. We can see this pattern emerging with customers adopting cloud data warehouses like ClickHouse, Snowflake, and Databricks and using them for telemetry use cases. Customers get access to the data more cost-effectively, but they must build custom solutions on top. These are not purpose-built telemetry tools and as such, similar to what we saw with Observability Pipelines, only the most sophisticated organizations are successful today.
Additionally, it would also be fair to ask: “Aren’t agents going to solve all of this for me?” “Can’t agents just query all my datastores and give me a unified view?” Certainly agents will achieve some of this. However, when you need to unify data across data stores, what does the unification? When you ask a question, how do you ensure the question gets translated the same way every time?
A unified lens on data needs to be deterministic. Federation should be a capability of the platform that an agent can utilize to get deterministic answers back to its question, rather than being solved by the agent itself. Translating natural language to query language is non-deterministic: it’s not guaranteed to be the same every time. Being able to correlate and join between data stores at scale needs to happen at the data layer, not the agent layer.
So again, we find ourselves needing to evolve the architecture for the problems of 2026. To achieve agentic telemetry, we need to evolve our telemetry platform.
Terms and definitions
Let's define terms as I'm using them. At minimum this post will be internally consistent, and you can see how I'm thinking even if your definitions differ.
Agent. The most overloaded word in the industry. In 2019, an agent was a piece of software that collected data from a box. In 2026, an agent is a piece of software that reasons and acts. Both kinds sprawl.
Agentic telemetry. Telemetry managed for people and AI agents at once, fusing human, machine, and AI context so any authorized agent can ask questions of any data.
AI Platform for Telemetry. The architecture that makes agentic telemetry practical: open access for people and agents, full-fidelity retention, search-in-place, fused context, agent observability, and governance.
Context. Everything around an event that makes it answerable: who deployed, what changed, which identity touched it, what an agent already did about it, etc.
Federated search / search-in-place. Bringing the question to the data instead of moving the data to the question. Query data where it lives: in the lake, in object storage, in the lakehouse, in the tools you already pay for.
Telemetry lake / lakehouse. The lake is cheap, full-fidelity retention in open formats. The lakehouse is the price-performance layer that makes data at rest fast enough to rapidly interrogate.
Detection. A system, not a stage. Finding problems in your data. Matching in the stream is one stage of that system. Querying at rest with surrounding context enables high quality correlations and alerting.
Problem 1: Agent fatigue, again
Back in 2019, I wrote about agent fatigue: a world where every vendor demanded its own collection binary, and Ops teams were left managing a dozen distinct shippers. Consolidation was a pipe dream because those agents were the proprietary keys to the data kingdom.
It is seven years later, and the cycle has repeated with a different species of agent.
In 2026, every vendor is pitching an AI companion. There are copilots for your SIEM, your APM, your ticketing systems, and your cloud infrastructure. Left alone, they become walled gardens, reasoning mostly over their own silos and priced to make leaving painful.The agent remains the mechanism for vendor lock-in.
The math is brutal. You have N agents across M repositories, but none of them can traverse the gaps. Your security copilot is blind to application traces; your monitoring copilot has no visibility into security detections. Worse, they are all ignoring the massive volume of raw telemetry that was never indexed because the economics didn't work.
Take a hard look at your spend: how many of these expensive copilots are you funding, and can a single one of them answer a question that requires joining data across two or more different tools?
The incentives remain unchanged from 2019, but the stakes have escalated. This time, the agents aren't just moving bits. They are making recommendations, writing queries, opening tickets, and eventually taking action in your business.
Problem 2: Context starvation
Seven years ago, I shared one of my favorite quotes from my co-founder, Ledion, that still resonates today: "The value of a debug log is exactly zero, until it's not." In the previous epoch, that economic reality forced a compromise: selective collection based on foresight. When I surveyed the industry about what was being discarded, most customers admitted they were collecting a fraction of their telemetry and potentially leaving petabytes uncollected.
Agents change that calculation. A human goes and finds an answer to a question only when the pain of doing so justifies the effort. An agent can ask the next question immediately, in parallel, and without getting tired. That only helps if the data exists, the agent is allowed to reach it and the agent has sufficient context to query and understand it.
The issue is not just missing logs. It is missing relationships. The trace is not enough without the deploy. The alert is not enough without identity. The ticket is not enough without telemetry. The agent transcript is incomplete without the tool calls and data it processed. If those live in disconnected systems, you do not have agentic telemetry. You have partial answers.
You can't ask questions of data you don't have. Neither can your agents.
The uncomfortable answer in most customer conversations is: an agent can reach less telemetry than you think, and less than it will need. Telemetry drives the costs, but the architecture must also evolve to see beyond telemetry into relevant context. Marrying human generated data which contains all the context along with the relevant telemetry.
Problem 3: Token economics
The 2019 version of this problem was capacity anxiety: admins living in fear that one chatty deployment would blow through the ingest license. The 2026 version is worse, because now there are two meters running: what it costs to keep the data and what it costs for an agent to think about it.
Your telemetry is measured in petabytes. A context window is measured in megabytes. You cannot shove the former into the latter. Something has to retrieve and summarize petabytes of telemetry to get kilobyte summaries for the context window. Moving petabytes of data to one place to get those answers isn’t feasible.The architectural answer is retrieval and federation: let the agent find the needle where it lies, and pull back only the needle.
Now the economics. Index-everything pricing was already shaky when humans were doing the asking. Agents query orders of magnitude more often than humans ever did. Agent curiosity will necessitate access to an order of magnitude or more data than current models can do cost effectively. That's before vendors tack on fees for API access, which is becoming common.
Architecting the answer: An AI Platform for Telemetry
Solving fatigue, starvation, and economics takes more than another feature. It requires the same kind of architectural shift that created the observability pipeline. Here is the blueprint for the capabilities required to make agentic telemetry a reality. I would hold any vendor to this standard, and we certainly hold ourselves to it.
Open access for all agents. AI agents and human operators must be treated as peer consumers. With open protocols like MCP and open APIs, any authorized agent, whether built in-house, by a vendor, or by a competitor, becomes a first-class citizen capable of interrogating the system.
Full-fidelity retention at scale. You cannot predict what a reasoning agent will need to know tomorrow. A telemetry lake providing affordable, high-fidelity storage for every byte is a prerequisite.
Search-in-place. Federated query capabilities across the lake and existing tools are the only sane responses to the brutal reality of token economics. Move the answer, not the petabytes.
Context by default. Context should not live in a silo. By fusing human, machine, and AI metadata both in motion and at rest, detection evolves into a system rather than a single processing stage.
Trust and governance. When agents can act autonomously, verifiability becomes paramount. Every query and action needs identity, RBAC, audit, lineage, budget controls, and a way for humans to inspect what happened. Agents must also be sources of telemetry, not just consumers, necessitating rich instrumentation and observability of the agent layer as well.
AI training and inference. Future use cases will require customized models, trained across the industry as well as customized for each customer on individual customer data. Models are not just LLMs, but wire speed models for classification, structuring, clustering, and sensitive data scanning.
When these six pillars are integrated, a clear vision emerges. You need an open front door for any consumer (1), supported by the entirety of your data (2), with the ability to query that data where it rests (3). That data must be enriched with deep context (4), while the agents themselves emit telemetry (5) within a secure, auditable framework (6). This is the platform. Leave any one of these out and you may still have a great demo. You do not have something an enterprise can trust in production.
An open architecture: The map
Seven years ago, I laid out a blueprint and invited the community to construct it. Many did, and the industry matured as a result. We are at that same juncture again. If the map is good, you should be able to build this yourself.
From left to right, here is the flow:
Sources. The usual suspects: infrastructure, apps, and security tools. Plus a critical new addition: the agents. Every action, tool call, and decision made by an AI agent is telemetry that must be captured.
The pipeline. Shaping, routing, and enriching data in motion. This is where in-stream detections live, functioning as one vital stage in a much larger system.
The Lake and Lakehouse. Full-fidelity retention in open formats like Iceberg. The lake provides the cheap storage; the lakehouse provides the real-time query and performance needed to rapidly interrogate data at rest.
Federated query. Search-in-place capabilities that let you query the lake, object stores, and existing analytics tools without moving petabytes to a central store.
The access layer. The open front door for agents, using MCP and standardized APIs to ensure any authorized consumer can walk through.
Consumers. Humans and machines working as peers. Whether it is Claude, ChatGPT, or a custom SRE agent from GitHub, if it speaks the protocol and has permission, it has a seat at the table.
For the DIY crowd: use OpenTelemetry with GenAI conventions for instrumentation, Iceberg for open storage, and MCP for access. This architecture ensures you can swap models whenever the wind changes, avoiding lock-in.
By following this roadmap, sophisticated organizations can achieve agentic telemetry today. We would love for you to build it with us, but either way, we want to see how you solve these problems. Choice and control are the only way forward.
Three solutions
Concepts are fine, but here are some examples of how agentic telemetry functions in the real world:
AI SRE. When a latency spike occurs, an agent investigates by federating metrics, lake logs, and change history from disparate tools into a single timeline with evidence. Instead of a manual scavenger hunt, the human operator gets the likely cause, the queries, and the confidence level.
AI SOC. A stream detection triggers a response where an agent retrieves historical activity from the lakehouse. By fusing identity context and historical triage data, it delivers a high-fidelity case to the analyst rather than a raw alert.
Retroactive investigation. Facing a new CVE, an agent interrogates hundreds of days of full-fidelity data for specific indicators. In the legacy index-everything model, this depth of inquiry was economically impossible. Now, it is a standard operational task.
As agents get access to the telemetry data they can’t see today the possible applications of that data will explode.
The final word
Every major shift in telemetry has been driven by a new consumer. Agents are the next consumer, and the old architecture was not built for how often they ask, how much context they need, or how quickly they move.
Models will change. Agents will change. Interfaces will change. Your telemetry is the durable asset. Architect for that: retain what matters at full fidelity, use open formats, query data where it lives, and establish a governed access layer for any authorized reasoning engine.
You can’t ask questions of data you don’t have. Neither can your agents. Plan accordingly.
This was a deep dive because the architecture matters. Seven years ago, we took the long way around to define the pipeline, and that worked out just fine. We’re doing it again.
