Skip to content
Logmetry
What we solve
SIEM and log costClean data for AI agentsCoverage, audit and PIIVendor independenceSIEM migrationObservability modernizationAll problems we solve
Who it’s for
For the CISOFor the CIO and CTOFor the CFOFor Architects
Platforms
SplunkMicrosoft SentinelCrowdStrikeElasticDatadogDynatraceSplunk ObservabilitySolarWindsCriblOpenTelemetryA Data LakeCompare the options
The Blueprint
The whole methodPhase 01 · FoundationPhase 02 · AI triagePhase 03 · RemediationPhase 04 · FootprintEverything as codeAI native
JournalAbout
About LogmetryYour teamTrust and securityStep one and the proofWhere we fit
Book the review

The Logmetry BlueprintPhase 02

AI triage and root cause. SOC agents you own, on clean data.

SOC agents you own work the alerts your tools already fire, find the root cause, reach the alerts your team never gets to, and hunt across the clean Lake, read-only, with a person on your team on every exception.

Book the architecture reviewAll four phases →
  1. 01Foundation
  2. 02AI triage
  3. 03Remediation
  4. 04Footprint

What gets built

  • SOC agents on the alerts your tools already fire, read-only
  • Business, infrastructure, log and trace data in one Lake, read without parsing
  • Root cause analysis across every source in the Lake
  • The alerts your team never gets to, worked
  • Threat hunting across the clean Lake
  • Fixes proposed as pull requests, reviewed by your team

The gate

Comes straight after Phase 01, once it is proved on your data. A person on your team reviews every exception, and remediation is always a proposal someone reviews, never an unattended change.

01How it works

Your alerts, worked read-only

Agents work the alerts you choose as they fire: one on security triage, one on root cause, one hunting across the Lake for what no rule caught, all reading the Lake copy read-only, and people decide every exception.

Your agent, and the SIEM you keepAny SIEM you keep is unchanged and its detections still fire. The alert crosses into ground you own, where your agent queries the Lake and is handed your runbooks and environment context. It calls back into the SIEM over MCP only for the one thing that platform alone holds, and everything the investigation found is appended to the ServiceNow ticket the service desk already opened.KEPT, AND UNCHANGEDSPLUNK · SENTINELand any other SIEMYour detections, your rulesThe alertYOUR GROUNDYOUR AGENTOVER MCPFor that one thing onlyYOUR LAKEYOUR RUNBOOKSYour runbooks, your environment,and how all of it fits togetherEvidence, hypotheses, and what it ruled outSERVICENOWThe ticket you alreadyopened, with the case appended
The SIEM stays and its detections still fire. The thinking happens on ground you own: the Agent reads the Lake and your runbooks, reaches back across the boundary once and on purpose, and appends the case to the ticket that already exists.

Findings land in the ticket your service desk already uses. By then the queue runs both ways: a request for a new source or a new alert, and a fix an agent proposes off its own finding, both arrive as pull requests rather than as console work. Remediation is always a proposal a person reviews, never an unattended change.

What you own after: playbooks written around your environment that get sharper with every investigation, and one agent pointed at security triage while another works root cause.

02The half nobody sells

Why the platform version stops short

A platform's assistant lives inside its own console, reasons about what that console holds, and stops at its edge.

  1. 00:00

    Alert firedYour SIEM

    Impossible travel on j.rivera, the rule your team already runs.

  2. 00:04

    Reads the LakeYour Lake

    Only the fields it needs: the user, where the logons came from, who owns each host, every logon on record.

  3. 00:09

    Asks your SIEM over MCPYour SIEM

    The detection’s own context, read in place. Nothing is copied into a vendor’s AI module.

  4. 00:31

    Finding in your ticketYour service desk

    The hypothesis, the evidence and what it checked, in the ticket your service desk already opened.

  5. 00:38

    Fix as a pull requestYour repository

    The VPN pool was missing from the office ranges. One line, linked to the ticket.

  6. Waiting

    A person approvesYour team

    Nothing merges until someone on your team says so. The pipeline tests it first.

What each one can reach

A console’s assistant

Its own console, and the data you paid it to ingest

Your agent

The Lake, the SIEM, the ticket and the repository, on your runbooks

Their AI runs on their rules and their runbooks. This one runs on yours.

Illustrative. Times are from the alert.

The same idea over an estate you hold as code can read the collection layer, the destinations, the Lake and the infrastructure underneath, read-only, because every part of it is code. It has no write access to your SIEM's rules or your source systems. The Agent follows the same trace ID your APM raised into everything the collector kept around it. That reach is what the foundation exists to build, and it cannot be bought as a module.

From outside nothing moved. Same sources, same destinations, same service desk. In between sits a layer you own, where the models are yours and the runbooks are your team's.

03Questions

Asked about the Agent

Does the Agent replace our SOC?

No. The Agent works the alerts you choose, from the tools you already run, and reads the Lake copy read-only. Findings land in the ticket your service desk already uses, and a person on your team reviews every exception before anything changes. It takes routine work off your analysts. It does not take the decisions.

Whose models does it run?

A model you approve, running in your own account. It is a configuration decision, frontier or open weight, and swappable later without rebuilding anything, because every model reads the same foundation: the enriched, partitioned Lake built in Phase 01. Your data never trains any model, ours or a vendor’s.

What do we own afterwards?

Playbooks written around your environment that get sharper with every investigation, and the agents themselves, running in your own account on your own runbooks. One points at security triage while another works root cause. None of it lives inside a vendor console.

Why does AI triage come straight after the foundation?

Because AI is where the return is, and the Agent is only as good as the data it can reach. Phase 01 makes the history clean, enriched, cheap to keep, and yours. Without that foundation an agent reads one console and stops at its edge, which is exactly the version the platform vendors sell. So the agents go on top of the foundation as soon as it is proved on your data, before remediation, collection or footprint work, and step one itself puts none of your data into any AI model.

See your architecture drawn, with the costs, before you spend anything.

Our lead architects draw your SIEM feed from your diagrams: where the cost sits, what step one would change, and where it would not pay. If it pays, the next step is a two-week proof on your noisiest source.

Book the architecture reviewOr take the Blueprint as a PDF →

Free. No system access. No obligation. You keep the drawing.

What you get

  • Your architecture today, drawn
  • The waste map
  • Costs before and after, with estimates
  • Your target architecture
  • Options for your business problem

What it costsNothing