Something interesting is happening in software right now. Not the fact that organizations are building custom applications, as they've been doing that for decades. Some of the most important software in the world was never packaged and sold. It was built by internal teams, integrators, and domain experts solving problems no vendor bothered to.
What's changing is the economics. AI is collapsing the cost of building applications. What took months of development effort now takes days. Subject matter experts who used to write requirements for engineers are increasingly building the experiences themselves. The question isn't whether organizations will build custom software. It's how much of it they'll build, and how fast they'll build it.
In IT and Security, this matters more than most places. Nearly every meaningful workflow runs on telemetry. Troubleshooting an application, investigating a security incident, monitoring an AI workload, understanding infrastructure behavior — the workflow changes. The user interface changes. The use case changes. The telemetry doesn't. It's the constant underneath all of it.
Here's the problem: the cost of creating applications is falling fast. The cost of the infrastructure underneath them is not.
Applications need identity, governance, RBAC, search, storage, APIs, and secure access to data. If building apps gets dramatically cheaper while the infrastructure tax stays constant, you haven't removed the bottleneck. You've just moved it. Teams won't struggle to build applications. They'll struggle to support them.
That leads to an architectural question that's long overdue. If telemetry is the common dependency across all of these experiences, why are we still rebuilding telemetry infrastructure every time we create a new application?
For twenty years, the industry's answer was: you don't. You buy a solution. Observability vendors built observability platforms. Security vendors built SIEMs. Analytics vendors built analytics products. Each one came with its own collection, storage, governance, and access controls baked in because that's how you justified the license. The telemetry stack was bundled with the experience.
That model made sense when applications were expensive. The AI era changes the math.
Applications are becoming abundant. The infrastructure underneath them is not. And here's what keeps coming back to me: we've seen this pattern before. Databases moved from bundled to shared. Cloud infrastructure moved from embedded to utility. Identity followed. Every time a critical capability moved into a shared platform, the experiences built on top got dramatically better and cheaper to create.
Telemetry is next. That belief is what led us to build the AI Platform for Telemetry. But let me be clear about what that means, because this is where the important distinction lives.
We're not building another application framework that extends a single product. We're not creating another silo where applications can only touch data stored inside Cribl. We looked at our customers and saw the reality: telemetry already exists everywhere. Observability platforms, SIEMs, cloud services, data lakes, object stores. Most enterprises are multi-cloud, multi-tool, multi-vendor environments. The answer isn't convincing customers to move everything into a single destination. The answer is helping them access, govern, and operationalize telemetry regardless of where it lives.
That's why federation became a core design principle. Before a person, application, or AI agent can create value from telemetry, it first needs to access that telemetry. The first challenge isn't centralization. It's access. Once you start from that premise, app building looks very different.
Most application frameworks in the market sit on top of a solution platform. The app is valuable because it extends the solution. It's another way to consume what's already there. We came at it from the opposite direction. We started by solving telemetry infrastructure problems. Collection, routing, processing, governance, storage, search, access, federation. Those came first. App building emerged on top of a telemetry platform, not a solution platform.
That distinction matters more than it might seem. A solution platform assumes the app is valuable because it extends the solution. A telemetry platform assumes the telemetry itself is the durable asset and that many different experiences should be able to consume it. Some built by Cribl. Others built by customers, partners, integrators, or AI-assisted tools. The platform shouldn't care. Its job is to provide the common services every application needs while letting the application itself evolve independently.
The most obvious benefit is customization. Security teams can build workflows around the way they investigate incidents. Operations teams can build experiences tailored to their troubleshooting process. Partners can create industry-specific solutions. Customers can solve highly specialized problems that would never justify a commercial software product and do it without standing up another telemetry stack.
The software industry spent decades asking customers to adapt to applications. That was a reasonable ask when applications were expensive and hard to build. We're entering a period where the balance shifts toward the people closest to the problem.
The next generation of IT and Security software will be built on telemetry platforms, not solution-specific stacks. Some of those experiences will come from Cribl. Many will come from customers, partners, integrators, and AI.
Our job is to build the foundation that makes all of them possible.