A Guide to Orchestrating End-to-End Investigations with AI

If you’ve been following this series, we’ve covered two agents in Swimlane’s Hero AI fleet so far: the MITRE ATT&CK & D3FEND Agent that standardizes how you describe attacks and defenses, and the Threat Intelligence Agent that synthesizes multi-source intel into a single, explainable assessment. 

Both of those agents solve real problems, but they’re inputs. They produce context. What happens next, given that context, is where investigations either fly or fall apart.

This is where the Investigation Agent comes in, and honestly, it’s the one I’m most excited to dig into, because it’s where the fleet concept stops being theoretical and starts producing end-to-end outcomes. 

It’s also where progressive trust gets real. When an agent is enriching indicators or mapping ATT&CK techniques, the blast radius of a mistake is small. When an agent is building an investigation plan, generating a timeline, and recommending containment actions, that’s a different conversation entirely. 

The bar is higher, the stakes are higher, and the trust has to be earned differently.

But here’s the thing: this is also the agent that unlocks the outcome every SOC leader actually wants, confidently auto-closing the obvious stuff so your team can focus on what matters.

The Context-Switching Tax

Before we get into how the Hero AI Investigation Agent works, let’s talk about the problem it solves, because I think it’s one of the most underappreciated productivity killers in security operations.

When an alert fires and an analyst starts investigating, they’re not just doing one thing. 

• They’re pulling alert context from the SIEM. They’re checking the threat intelligence (TI) platform for indicator reputation. 
• They’re looking at historical tickets to see whether this host or user has appeared before. 
• They’re cross-referencing the MITRE framework to understand the attack pattern. 
• They’re consulting the runbook to see what the documented response procedure looks like.
• They’re writing notes as they go. And then they’re making a recommendation, escalate, contain, close, based on all of that work.

Each of those steps lives in a different tool, tab, or workflow. The analyst is the integration layer, and the cost of that integration is context switching. Every time they pivot between tools, they lose momentum. They have to re-orient, re-read, re-contextualize. 

Switching can eat 20-40% of productive time, and in my experience running SOC teams, that’s conservative for investigation work.

The Investigation Agent eliminates that tax by doing what a senior analyst does, but from a single interface, without the cognitive overhead of tool-hopping.

How the Investigation Agent Works

The Investigation Agent acts as the “brain” of the AI SOC, and that framing actually makes sense when you see how it operates. It doesn’t work in isolation; it ingests the high-fidelity outputs from the other three agents in the fleet and synthesizes them into a complete investigation.

Investigation & Response Agent Workflow

The agent starts by pulling in all available case inputs, including the raw alert data, enrichment, and context. It layers in the TI Agent’s unified cross-source analysis, the MITRE agent’s technique and countermeasure mappings, and the Verdict Agent’s preliminary assessment. 

That’s the intelligence foundation.

Then it does something that most automation tools don’t: it evaluates all of that against your customer-defined runbooks and knowledge base articles. This is where your institutional knowledge comes into play: the documented procedures, lessons learned from past incidents, and the tribal knowledge your team has (hopefully) captured over time. 

The agent uses the NIST Incident Response Framework as its backbone, providing the output with a structure universally understood across security teams.

Investigation Agent Results: Four-Phase Response Plan

The result is a prioritized response plan organized into four phases: 

1. Containment: stop the threat from spreading.
2. Eradication: remove the root cause
3. Recovery: restore normal operations
4. Hardening: prevent recurrence

Each recommendation is actionable, not a vague “consider investigating further,” but specific next steps that an analyst can execute or, when the trust is earned, that the platform can execute autonomously.

Along the way, the agent generates investigation summaries, timelines, and recommended actions through a single unified interface. No tab-switching, no manual correlation, no rebuilding context every time you switch tools. The analyst gets a complete picture and a clear plan.

This is Where AI SOC Benchmarking Gets Real

Okay, this is the part I really want to spend time on, because it’s the most important concept in this entire series, and the Investigation Agent is where it becomes tangible.

I’ve been saying throughout these posts that AI in the SOC doesn’t need to be perfect to be useful. It needs to achieve human-level or better outcomes, with sufficient explainability so an analyst can validate the reasoning. The way you prove that isn’t with vendor demos or marketing claims, it’s with benchmarking against your own analysts on your own data.

Swimlane did exactly this with their internal SOC. They took roughly 35,000 human investigations, real cases, real decisions, and real analyst notes and used that dataset to benchmark, verify, and tune the agents’ outputs. That’s not a lab exercise. That’s comparing what the AI would have recommended against what experienced analysts actually did, on a case-by-case basis at scale.

Swimlane AI SOC Case Study

Tips for AI SOC Teams

This is the methodology I push every time I work with a team on AI adoption.

Start with your raw material. You need historical tickets and the analyst notes that capture why something was closed, escalated, or labeled benign. The “why” is the critical part, not just the disposition, but the reasoning chain. 

If your analysts are closing tickets with one-word notes, you’ve got a documentation problem to solve before you’ve got an AI problem to solve. If you already have knowledge bases and runbooks, great, the Investigation Agent can evaluate cases against them. If you don’t, you can use AI to generate them from old cases. 

I’ve had good results using Claude Sonnet for this: feed it a batch of historical tickets with analyst notes, and have it extract the patterns, decision criteria, and response procedures into structured KB articles. Treat that as your starting knowledge base and refine from there.

Then you iterate. Run the Investigation Agent alongside your analysts. Compare its investigation plans, timelines, and recommended actions with what your team independently produces. Track where it agrees, where it diverges, and why. 

Look for patterns. Is the agent consistently more thorough on enrichment but occasionally missing context that an experienced analyst would catch? Is it recommending containment actions that your team agrees with 95% of the time?

That benchmarking process is how the agent earns the right to more autonomy. It’s not a day-one switch. It’s progressive trust.

Building Your AI Knowledge Foundation

I want to close with something practical, because this is where I see most organizations stall. They want the auto-close outcome, but they skip the knowledge foundation that makes it possible.

The Investigation Agent is only as good as the runbooks and KB articles it uses to evaluate cases. If your institutional knowledge lives exclusively in the heads of your senior analysts, and let’s be honest, in most SOCs it does, then the agent doesn’t have the context it needs to make good recommendations. 

You’ll get generic investigation plans instead of ones tailored to how your team actually handles specific case types.

The fix is simpler than most people think. Pull your last 6-12 months of closed tickets. Focus on the ones with decent analyst notes (even if they’re inconsistent, that’s normal). Use AI to extract common patterns: which alert types generated these cases, which enrichment steps were taken, what the typical decision criteria were, and what actions were recommended. 

Structure that into KB articles and runbooks. You don’t need perfection; you need a starting point that the agents can reference and that your team can refine over time.

I’ve done this across multiple environments, and the results are remarkably consistent. Within a few weeks of seeding the knowledge base and running the fleet in shadow mode, you start seeing the agents produce investigation plans that match what your analysts would have done. 

Within a couple of months of benchmarking, you’re identifying your first auto-close candidates. Within a quarter, you’re confidently closing a meaningful percentage of Tier 1 cases autonomously and your analysts are spending their time on the investigations that actually need human judgment.

That’s the AI SOC. Not a magic model that replaces your team on day one. A fleet of purpose-built agents that each do one thing well, feed into each other, and collectively earn the right to carry more weight over time. The Investigation Agent is where all of that comes together, and it’s where the ROI gets real.

In the final post of this series, I’ll cover the Verdict Agent, the one that actually makes the call. If the Investigation Agent is the brain, the Verdict Agent is the decision-maker. Stay tuned.