Introducing Grepr AI: a recap of my launch talk

When we talk to SREs and security analysts, we keep hearing the same thing: Code is getting pushed to production faster and faster as AI gets adopted inside engineering teams. Developers are shipping faster, security teams are seeing attacks generated by agents, and telemetry volumes keep climbing. Both groups are fighting to keep up with the detections they need to keep their systems reliable and secure, and it has become hard to build the static alerting rules to keep up with what is actually happening in production environments.

Change used to happen more slowly. In the past, teams could build rules and alerts off aggregates, SLOs, and metrics that indicate a problem. When those alerts fired, you would troubleshoot, figure out what happened, and add a new alert for the leading indicator that would have caught it sooner. 

It’s always been true that the most common reason incidents happen is something unexpected happened in production. But today, with the velocity of code being released, building static rules to cover every failure mode is essentially impossible.

How Grepr AI is different

So we asked a different question: Can we catch leading indicators of operational incidents and security threats without the need to build static rules based on known failure modes? 

That’s exactly what Grepr does. It monitors telemetry data for changing patterns, then uses AI to reason about whether that change is indicative of an impending incident or threat. Where AI SRE and AI SOC tools start when an alert fires, Grepr AI detects potential issues before an alert. 

Grepr’s Signal processor uses unsupervised machine learning to identify patterns in data. It sends interesting or novel signals to Grepr AI for investigation and orchestration across other tools in your stack. That’s how Grepr helps you catch problems no existing rule can catch. Since releasing Grepr AI, our customers have used Grepr AI to find errors, bugs, PII and sensitive data leaking into logs, and production problems they otherwise never would have found.

How Grepr works

The Grepr platform has two parts: the Signal Processor and Grepr AI. Here’s how they work together, including with your other tools:

1. You create an agent and tell it what to do in plain language: how to investigate signals and how you want to be notified if it finds anything worth flagging.
2. Grepr’s signal processor ingests your telemetry and detects new patterns: a new path in your application, an error path on your traces, or a static rule you built yourself into our streaming SQL. These signals are sent downstream to your observability and security tools. They’re also sent to Grepr AI for investigation. The “noise” is sent to a low-cost data lake that you control, always available for backfill into your observability and security tools.
3. Your agent reads the signal in context, checks its memory of similar events, and decides whether it matters. Noise is closed with the reasoning attached, so you can see what was ruled out.
4. When something matters, the agent posts a diagnosis with evidence, opens a fix PR, repairs the pipeline, or runs the workflow you defined. Or it hands the issue to the agent or system you already use. Agents can interact with external systems like Slack, your SIEM, your ticketing system, or runbooks and workflows you define. And they can write static rules back into the signal processor to re-trigger themselves when a threshold is crossed, which gives the agent layer a self-improving loop.

Why Grepr AI doesn’t blow up your bill

You might be wondering: If you send all your telemetry into Grepr, why don’t the agents blow up your bill? The reason is: Grepr AI agents don’t analyze your entire telemetry stream. Instead, the signal processor only passes the interesting patterns to Grepr AI. Over time, the volume of new patterns we discover becomes asymptotic and flat, so instead of agents working on terabytes or petabytes of raw data, they only see kilobytes or megabytes, which enables them to scale without driving costs.

Human-agent collaboration

Grepr AI has a built-in issue tracker, where you can follow the status of each investigation and collaborate with Grepr agents, your teammates, and non-Grepr agents (eg, AI SREs or AI SOCs). Every agent’s work is audited, the full investigations are stored, and agents cannot make changes unless you permit them. You define their access and permissions, and the data stays yours, in your bucket.

Case study: What Grepr AI caught for us

Before we released Grepr AI, we deployed it in our own environment, running tens of thousands of investigations that found 20 high-priority issues we needed to address. Some of these issues were discovered in our development environment, allowing us to fix them before they went into production, avoiding incidents altogether. And some issues were live in production, just waiting to cause a problem. In each case, Grepr AI detected the issue within a few minutes of the first signal appearing in our telemetry, which we would otherwise have missed, because nothing was looking for it.

Demo: See how it works

To show how Grepr AI works, we built a demo environment with more than a dozen services and a load generator making thousands of simulated purchases. We built an agent called “Shop SRE” using plain-English instructions, we set its permissions, connected it to GitHub and Slack over MCP, and subscribed it to a pipeline. 

Then I flipped a flag so that half of all charges would fail with a 503 error. Grepr detected the signal immediately as something new, causing the Shop SRE agent to investigate, creating a new issue. Grepr AI wrote up what a good SRE would: the symptom, the evidence with the exact log events and trace IDs, and the root cause down to the code. It then opened a fix PR that added a retry with backoff, posting its findings to Slack.

A few questions that came up

Do you replace my AI SRE or my SIEM? 

No. AI SREs start when an alert fires. Your Grepr agents find what never fired and can hand it over through MCP. Grepr is the trigger, not a replacement. You could build your AI SRE on top of Grepr if you wanted to and we’d provide templates to help. Grepr is a harness, not a single agent.

SIEM runs potentially thousands of predefined detections to catch well-known potential attacks. However, what about attacks that could be detected in custom logs or new attacks against internal targets that you’re not monitoring with SIEM, maybe due to cost? Grepr provides a backstop that can efficiently provide an alerting system for issues you would otherwise miss.

One deployment serves ops and security.

Datadog and others already have anomaly detection, so how is this different? 

Observability platforms analyze what you send and index, against baselines they chose. Grepr agents see the full log stream before indexing, wake up on anything new or changed, and do the job your team defined for your environment.

Do I have to build every agent from scratch? What if my team doesn't know where to start?

You build agents using natural language, and Grepr provides starter prompts. The agents in the demo were built for our environment and solve problems most teams share, so they are a good first prompt to adapt.

New patterns show up constantly, so won’t this flood my team? 

No. Grepr AI agents investigate every new pattern but close most of them with reasoning attached. Only what matters reaches Slack or PagerDuty.

What can an agent change on its own? 

Only what you allow. Agents run in a tight sandbox with the permissions you give them, and you can require approval on every change.

What’s next

This first release works on logs, with unsupervised learning for traces and metrics coming. If you want to see what it finds in your own data, there is a free tier with no credit card. The signal processor underneath also reduces the telemetry you send to your observability and security platforms by up to 90%, and you can estimate that with our ROI calculator. And we will be at KubeCon in Salt Lake City this month, booth 291. Come find us.

‍