Every SOC is drowning in the same way. Enterprise teams field 100,000+ alerts a day. About 70% never get investigated. Analysts are stretched thin: there aren't enough hours, and the headcount isn't growing as fast as the alert count.

The industry's answer is "agentic SOC." Every vendor has a version. Some form of system with “always-on” agents that hunt, triage, investigate, write detections, and maybe even learn from each other.

But agents don’t fix the underlying problem. If your analysts couldn't trace one identity across five systems before, your AI assistant can't either, it just says so with more confidence. That confidence problem is the real story here.

Talk to any team that's actually tried to build agentic detection and response. The conversation about which model to use lasts about five minutes. Then it turns into a conversation about data: what you actually have, and whether it's fast and clean enough for an agent to reason over instead of guess.

The data layer is the ceiling

The data conversation always comes down to: an agent's ceiling is set by its data layer. Here are the ways an inadequate data layer keeps AI agents from being useful in the SOC:

1. Fragmented search is what happens when you can resolve identity across systems and can't search across them together.
   ‍
   ‍One attacker. Five systems. Five different identifiers for the same person: an ARN in CloudTrail, an email in Salesforce, a different email in Microsoft 365, a user ID in Slack.
   
   Resolving those five identifiers to one is the pipeline's job, and it matters. But resolution alone doesn't answer the actual question an investigation needs answered.
   
   Your SIEM sees five unrelated events because it was never built to search across all of them at once. Your analysts get five tickets. The attacker sees one clean path from phishing email to exfiltration.
   
   That's the default state of any enterprise running 30+ tools, even the ones that agree on what to call the same user, if nothing can search across all of them together.

2. An agent can’t investigate what retention economics has already erased.‍
   
   ‍Mandiant's 2026 incident response data puts median dwell time for cyber espionage cases at 122 days. Some intrusions (BRICKSTORM) ran closer to 400 days. Most SOCs keep searchable logs for 30 to 90 days. By the time anyone's looking, the evidence has already aged out.‍
   
   IBM's numbers tell the same story from a different angle with the average breach now taking 241 days to identify and contain. Breaches caught before day 200 cost $3.87 million on average. Past day 200, $5.01 million. Almost 30% more, just for being slow. An agent can't investigate what has already rolled out of the retention window.

3. Fast is too expensive at agent volume. Cheap is too slow. That’s the cost vs speed problem.‍
   
   Security data mostly lives on one of two foundations, and neither one is built for what an agent needs.
   
   Search platforms like Splunk or Elasticsearch give you speed: sub-second queries, real-time investigation. But they're built for a certain level of concurrency, sized for people typing queries one at a time, not an agent firing off hundreds per incident. Push past that and you're either paying for a lot more compute to keep up, or every query queues behind everyone else's.
   
   Data lakes built on Iceberg or Delta Lake flip the tradeoff. Storage is cheap. Scale is easy. But these systems were built for occasional analytical queries, not the high-concurrency, low-latency pattern an agent needs when it's iterating through a live investigation.
   
   Neither foundation solves that on its own. Teams bridge this today with throttling and sampling: route the "important" queries to the expensive system, let everything else wait. That works fine when a human is setting the pace. It doesn't work when the thing setting the pace is an agent running dozens of queries a minute, or an attacker doing the same on the other side.

4. Without structure and context, more data makes an agent confidently wrong, faster.‍
   
   More data also doesn't raise the ceiling. Sometimes it lowers it.‍
   ‍
   Researchers found this back in 2023, before agentic anything was a category. Feed a model a stack of documents with the answer buried in the middle, and accuracy on that answer can drop below what the model gets with no documents at all. Handing it more evidence made it perform worse than handing it none.‍‍
   
   Chroma tested 18 models in 2025 and found the same pattern holds today. They gave it a name: context rot. Performance erodes unevenly the more you pile on, well before any hard token limit.
   
   A team from Michigan and Amazon ran the same test on actual agents doing multi-step tasks. Bury an agent's task under noise and success rates fall from 40-50% down to under 10%. It gets stuck in loops, repeating the same failed action. Or it wanders off, finishes a different task, and reports the original one done.
   
   Feed an agent an unstructured dump of 40 alerts instead of 5 correlated ones, and this is what you're buying: an agent that's confidently wrong, fast.

Former Gartner VP Anton Chuvakin makes a sharper point than "process matters too." He argues weak processes and weak data compound each other, each one making the other harder to fix.

A SOC running on tribal knowledge, "ask John, he'll know," can't be documented into an agent-ready playbook if the underlying data is too fragmented to encode what John actually knows. The process fix depends on the data being there to fix it with.

Data comes first. It's what makes everything else fixable.

Agentic security operational layers

The "brand" of each layer is irrelevant. They just need to mesh together. Everything starts as raw telemetry, endpoint, cloud, identity, network, and SaaS before it ever reaches the first layer. What happens to it from there is what makes it an operation.

Data pipeline

This is where identity resolution actually gets fixed, or doesn't.

A pipeline collects from every source once, normalizes it so a login event looks the same whether it came from Okta or Entra, and resolves identity at ingestion: jsmith@company.com, JSMITH, and a Slack user ID all become one canonical ID before anything gets indexed. Do that here, and the five-system attacker from earlier becomes one flagged identity instead of five orphaned tickets.

This is a generic layer with real vendor variety, each with a different take on routing, enrichment, and cost control. None of this is unique to one company. It's the job any pipeline has to do.

Data lake

Remember the cost/speed wall: fast systems get expensive at agent volume, cheap systems are too slow for an agent's pace. This layer is where that tradeoff either gets solved or doesn't. It's also where that one resolved identity actually gets searched, across everything it touched, in one place, instead of five separate lookups.

The job here is full-fidelity retention (months, not weeks) at object-storage economics, with query speed fast enough for an agent to run dozens of questions per investigation instead of one.

Retrieval and reasoning

Getting data into a lake solves retention. It doesn't automatically solve reasoning.

An agent needs a way in to ask the lake questions itself instead of waiting on a person to run a query for it. But one query rarely finishes an investigation. Real reasoning looks like iteration: ask something, get an answer, let that answer shape the next question, keep going until you land on a real answer instead of a guess dressed up as one.

This is why the cost/speed wall from earlier matters twice as much here. An agent that can only afford one or two queries before the bill or the latency catches up isn't reasoning. It's guessing once and calling it done.

Orchestration and response

Detection without action is a very expensive dashboard.

This layer takes what the lake surfaces and what reasoning concludes, and turns it into something that actually happens: a case gets opened, a session gets revoked, an analyst gets pulled in at exactly the right moment instead of buried under everything.

Some of this runs on rules a human wrote in advance. Increasingly, some of it runs on an agent deciding the next step itself, based on what it just found. Low-risk moves run on their own. Anything that touches production, revokes access, or changes a config waits for a human first. Everything gets logged either way.

Skip that boundary and you don't get a faster agent. You get one nobody trusts enough to leave alone.

The workforce

The previous four layers get you the infrastructure. Something still has to run on top of it, asking the questions, drawing the conclusions, taking the action. This layer works differently from the others. It touches all four at once, querying the pipeline's normalized data, searching the data lake, working through retrieval and reasoning, and acting through orchestration.

An agent here runs a loop, not a single prompt and answer: pull context, form a hypothesis, query for evidence, check that evidence, decide whether to act or ask another question. Investigation is that loop running dozens of times in a row. It needs memory that outlasts one alert too, a case opened today should still carry its context if something six months from now turns out to be related. And it doesn't act unrestricted. What it can do on its own, and what waits for a human, is a boundary set by whoever builds or configures it.

Two ways to fill this layer. Build the agent yourself, shaped around exactly how your environment and your team work. Or run one that's already built, already trained on this loop, and point it at your layers instead of assembling the loop from scratch.

Buy or build 

At some point every team asks the same question: do we buy one solution that does all of this, or assemble it yourself?

Gartner has a name for the buy path now: Integrated Security Operations Center, or ISOC. One vendor, one dashboard, detection and response bundled together. Gartner's own research rates it high-benefit, and for good reason, you get real out-of-the-box value without stitching four tools together yourself.

But Gartner's own research on ISOC also names the catch, in language sharper than most vendors would ever say about themselves: "mixing and matching components, while technically possible, diminishes the value of complexity reduction that the platform is intended to provide." Translation: you're not just buying a product. You're buying the obligation to stay inside it. Swap out one piece for something better and you lose the reason you bought it in the first place.

Buying a single vendor's fixed idea of what an agentic SOC looks like, in a space Omdia's Rik Turner says is still moving too fast for any one vendor to have the right answer for long, means betting your architecture on this year's version of a fast-moving idea.

Building it yourself, layer by layer, is the other path. Pick each layer, and pick it for your environment, not someone else's average customer. Keep the option to swap any one of them later without touching the rest. Outgrow one piece and you replace one piece, not the whole system.

IDC's Frank Dickson's advice, consolidate one domain at a time and prove it before moving on, is built for a large, phased rollout. Get one layer wrong, and you only replace that layer.

What we’ve seen work

A few teams already run this.

Lambda, which builds GPU supercomputers for large-scale AI training and inference, runs Monad and Scanner together. Monad handles ingestion, normalization, and catching breaking changes before they become problems. Scanner turns that clean data into fast answers, letting their team search and hunt across months of logs in seconds, whether through the console, API, or MCP. Together, the two have expanded visibility, opened the door to agentic detection and response, and helped Lambda investigate incidents faster with fewer people.

Notion runs Tines alongside Scanner as one of the data sources feeding Scruff, an AI teammate their security team built in-house to triage and investigate alerts. Scruff pulls context from Scanner, Wiz, and CrowdStrike before a human ever looks at a ticket. The results: 6+ hours saved per week across their Detection and Response Team, an 84% reduction in median time to investigate false positives, and 93% faster time to resolution on the same. Notably, Notion built Scruff themselves rather than buying an off-the-shelf agent, after running their own solution head-to-head against vendor platforms and finding it won on every criterion that mattered to them.

Ramp, a financial operations platform, runs Scanner alongside Cotool and Linear. Their previous setup only retained 15 days of searchable logs, and archived data on S3 took 30+ minutes to query with Athena, sometimes timing out entirely. Scanner cut that down to about a minute and stretched their searchable history from 15 days to a year. Tickets generated from Scanner route into Linear, which triggers Cotool's AI agents to pull additional context before a human ever reviews it.

Every organization's starting point is different. What generates the most telemetry, how long you need to retain it, how mature your team already is, how fast the threats you're facing are moving, all of it changes the right answer for you.

Start with an honest audit of what you actually have and answer these questions:

• Can you trace one identity across every system you run?
• How far back does your searchable history go?
• How many queries would a real investigation take before it ran out of time or budget?

Those answers tell you whether to build, buy, or hire a workforce to run on top of what's already there. Get that part right, and everything above it gets easier.