AI Over Every Log… Without Inference on Every Log

(See our early demo of the capability described in this blog as applied to sensitive data detection here).

Logs are how software explains what it is doing.

They record authentication attempts, API calls, configuration changes, deployments, failures, retries, and thousands of other behaviors. When a system begins to go awry, the leading indicators are often already present in its logs.

The problem is knowing which indicators matter.

Traditional monitoring asks engineers to predict how software might fail and encode those expectations into alerts. That works for known failure modes. But software changes when it meets the real world: unfamiliar workloads, unusual user behavior, degraded dependencies, and combinations of conditions no one encountered in testing.

The incidents that bring systems down are often the ones no one knew to create an alert for.

AI offers another model. An agent can understand what log messages mean, reason about their relationships, investigate supporting evidence, and turn what it learns into new monitoring or remediation logic.

Instead of only explaining an incident after it happens, AI can help discover what should have been monitored before the incident began by extracting operational and security insight from the entire log stream as it passes through the telemetry pipeline. It can then remediate a problem directly or use Grepr’s streaming SQL capabilities to create a continuous detection based on what the system has learned.

This is the challenge we built Grepr to solve: identifying novel failure modes (unknown unknowns), even if rare or happen only once, using AI at production-level volumes of telemetry data, before the failure escalates to an incident.

Every log should inform the AI, without every log requiring AI inference.

Alerts encode what we already know

No human - and no system built entirely from predefined rules—can predict every condition software will encounter once it is running in the real world.

The first indication of an unknown failure is often in the logs though. It may be a message the system has never emitted before or a change in frequency of another. At other times, every individual event appears normal, and the problem is only visible in the relationship between several messages over time.

The evidence is in the logs, but no one has written the alert that connects it.

Catching these unknown unknowns requires examining the complete telemetry stream in real time and looking for leading indicators before they escalate into incidents.

But logs are effectively endless. Large systems generate billions of events containing enormous numbers of recurring patterns. Sending every event to an LLM would be expensive, slow, and largely unnecessary. Sampling makes inference manageable, but it creates the risk that the signal that matters is one the AI never sees.

Grepr takes a different approach.

Extracting the shape of the stream

Grepr processes logs as they move through the telemetry pipeline and extracts their recurring shapes in real time.

Consider two messages:

Authentication failed for user jad from 10.0.4.21
Authentication failed for user amir from 10.0.8.17

The usernames and addresses differ, but the messages share an underlying structure:

Authentication failed for user <*> from <*>

As events arrive, every log contributes to an evolving representation of the stream. A familiar message reinforces a known pattern. A new shape means the system has started saying something new. A spike in an existing pattern can reveal a change in behavior. Relationships among patterns can expose conditions that no individual event reveals on its own.

This is what makes Grepr’s position in the telemetry pipeline important.

Pattern extraction does not happen later against a selected sample of stored data. It happens continuously while the complete stream is being processed.

Grepr is the first platform to use continuous, full-stream pattern extraction in the telemetry path as the context and trigger layer for autonomous agents.

One way to think about this representation is as the edge map of an image. It does not preserve every color, shadow, or texture, but it retains the contours needed to recognize what is present and notice what has changed.

Grepr gives the agent those contours: the patterns, representative samples, and relevant context. The agent can then “zoom and enhance” by retrieving raw events, examining metrics or traces, inspecting code or deployments, or using other permitted tools.

The pipeline identifies the signal. The agent determines what it means.

This is the foundation of semantic anomaly detection.

The anomaly might be a new message, a meaningful spike, or a relationship among event types. The semantic understanding comes from the LLM’s ability to recognize what the messages represent and reason about their significance.

Every log contributes to the system’s understanding. Inference is applied only where reasoning is valuable.

From understanding to continuous detection

Suppose a Grepr agent is asked to build security monitoring from an organization’s logs.

It identifies a pattern representing failed logins and recognizes fields corresponding to the user, source address, device, and authentication service. Elsewhere in the stream, it finds a successful-login pattern. Another pattern represents authorization failures against internal APIs.

No individual message necessarily proves that an attack is occurring. Their relationship may be more significant:

Repeated login failures
 → successful login
  → authorization failures across additional resources

This sequence could indicate that an attacker obtained access and is now attempting to move laterally through the environment.

The agent can form that hypothesis, determine how the events should be correlated, and generate streaming SQL to monitor the behavior. The resulting rule can track the relevant identities and systems across an appropriate time window as future events pass through the pipeline.

This creates a powerful division of labor.

The LLM understands the messages, reasons about their relationship, and constructs the detector. Grepr’s streaming engine executes that logic continuously and deterministically, without another inference call for every login or API request.

AI does not merely explain the evidence. It turns new understanding into durable monitoring.

The hardest part is learning together

Identifying a single pattern and launching an investigation is only the beginning.

The harder problem is that relevant evidence rarely arrives neatly packaged in one place or in the correct order.

One investigation may begin when Grepr discovers a failed-login pattern. Another agent may independently interpret an API authorization failure. A successful-login pattern may already be known, or it may appear days later.

These investigations may run in parallel. They may use different tools and gather evidence from different systems. They may reach conclusions that reinforce one another - or conflict.

Yet together, their findings may describe a single behavior that no investigation could discover alone.

Coordinating that work requires more than giving each agent a longer context window or a searchable archive of previous conversations. Agents need a shared memory in which they can:

• Record semantic interpretations of new patterns.
• Create, revise, and abandon hypotheses.
• Attach evidence and counterevidence.
• Track where a conclusion came from.
• Share proposed correlations and detection logic.
• Determine whether a hypothesis has been validated.
• Recognize when new evidence changes an earlier conclusion.

The telemetry pipeline maintains state about what has happened in the environment.

Coordinated memory maintains state about what the agents believe those events mean.

This is one of the hardest parts of building the system.

Closing the agentic loop

Continuous detection is not necessarily the final outcome.

Once an agent understands what is happening, it can investigate further, delegate work, notify a human, or execute a remediation through the tools it has been permitted to use.

The resulting loop looks like this:

Observe the complete stream
  → identify an emerging signal
  → understand its meaning
  → connect it to prior knowledge
  → create a continuous detection
  → alert, delegate, or remediate
  → observe the result
 → update the system’s understanding

This is the path toward systems that can self-heal and self-secure.

The objective is not to give an unconstrained model control over production. Organizations define which tools agents may access, which actions require approval, which remediations may run autonomously, and when a human must be involved.

The important change is that the system is no longer limited to the conditions engineers predicted before deployment.

It can learn new conditions from the behavior of the software itself.

Monitoring that learns its own failure modes

Putting a chatbot on top of log search can make an existing investigation easier. It does not solve the unknown-unknown problem.

Doing that requires a different architecture: one that observes the complete stream, extracts its structure continuously, applies semantic reasoning selectively, coordinates knowledge across investigations, and turns new understanding into monitoring and action.

That is what Grepr is building.

Today, monitoring is largely a static expression of what humans already know. Engineers imagine a failure, write a rule, and wait for it to happen. But the most consequential failures are often the ones no one expected.

What if the system can automatically handle new behaviors and detect leading indicators of issues before they happen, and then remediate them? The result would not merely be faster incident response. It would be infrastructure capable of learning its own failure modes and intervening before they become incidents. The result would be a self-healing self-securing system.

‍

Become a design partner for Grepr's AI capability

We are actively deploying this architecture with design partners. If you want to run self-healing, self-securing loops over 100% of your production telemetry, reach out to join our early access program by doing the following:

• Visit https://www.grepr.ai/contact
• Under Inquiry Type, select "General Inquiry"
• Under Message, enter "I'm interested in becoming a design partner for your AI capability"

‍