I Built the Agentic SOC System Sumo Logic Is Demoing at AWS re:Invent
SOC Analyst Agent: Your always-on security team (Image Source: Sumo Logic: https://www.sumologic.com/blog/agents-dojo-ai-soc-analyst-mcp)
This week, Sumo Logic is on stage at AWS re:Invent showcasing their Dojo AI platform—including a SOC Analyst Agent, Knowledge Agent, and MCP Server built on Amazon Bedrock AgentCore.
I built the working foundation for that system earlier this year.
End to end. In three weeks.
Here's what I learned.
The Problem Was Real
Security Operations teams are drowning. Not in theory—in practice, every single day.
The environment I walked into had:
AI-generated attacks accelerating faster than human analysts could adapt
100–1,000 security signals per second flowing through the system
Multiple disparate toolkits that didn't talk to each other
Tribal knowledge scattered across analysts' heads, not documented anywhere
Alert volumes that made triage feel like drinking from a firehose
Mean time to respond measured in hours when it needed to be minutes
The $21M product line built to solve this was stuck. Leadership team at Sumo had churned three times. The roadmap was fog. The team was burned out on AI initiatives that went nowhere.
Sound familiar?
The Question That Unlocked Everything
I didn't start with architecture diagrams or capability wishlists.
I started with one question:
What's the smallest, hardest, most valuable problem we can prove first?
For this system, the answer was natural-language query translation—turning an analyst's intent into real, executable SumoQL.
Why that slice?
Because it was the bottleneck. Analysts knew what they wanted to investigate. They just couldn't get it out of the system fast enough. Every query was a tax on their attention. Every syntax error was friction that slowed response time.
If we could nail that single interaction, we'd prove the entire agentic approach was viable.
What I Actually Built
In three weeks, I delivered the prototype for what's now the SOC Analyst Agent—an always-on system that applies reasoning to triage alerts, assess severity, and link related activity into a clear picture of what's actually happening.
The core capabilities I architected:
Autonomous investigation workflow — the planner agent creates an 8-12 step plan for investigating the insight. For each step, it takes a typical analyst's natural language question, translates it to SumoQL, executes it, interprets results, and recommends next steps.
Alert triage and severity assessment — after the plan is executed, the Judge agent produces a detailed verdict and attack graph. This standardizes how security alerts get evaluated, so you get consistent outcomes across the team, not just whoever happens to be on shift.
Blast radius identification — automatically linking related activity to show impact scope, not just isolated alerts (pivot on the attack graph entities to widen the investigation).
RAG architecture — the file schema and retrieval patterns that let the agent access documentation, runbooks, and tribal knowledge in context.
SumoQL translation patterns — prompt engineering and validation logic that made query generation reliable, not hallucinatory.
The conversational interface flow — what's now called Mobot, the UI layer where analysts actually interact with agents.
Agent orchestration logic — how multiple agents hand off context and collaborate on complex investigations.
Evaluation framework — how to measure whether the agent is actually reducing MTTR or just producing confident garbage.
This wasn't a demo. It was working code. Analysts could use it. We could measure it. Leadership could see it.
And that changed everything.
Why Speed Mattered
Three weeks sounds fast. It was.
But speed wasn't the point. Validation was the point.
When an AI initiative drags on for months without producing something real, it accumulates opinions. Stakeholders start designing by committee. Engineers start debating architecture in the abstract. Leadership starts asking "what's taking so long" without being able to see what "done" would even look like.
A working prototype in three weeks cuts through all of that.
Suddenly, the conversation shifted from "will this work?" to "how do we scale this?" That's a completely different organizational posture. That's momentum.
The Methodology Behind It
I call this approach the Snowball Sprint.
The core principle: start with the thinnest possible slice that proves the hardest part of your value proposition. Not a toy demo. Not a capabilities showcase. The actual hard thing that determines whether your agent will work in production.
Build that first. Get it in front of real users. Measure it. Refine it.
Then expand.
Iteration equals capability. But you can't iterate on something that doesn't exist yet.
Most enterprise AI projects fail because they try to boil the ocean before they've proven they can heat a cup of water. They define too much. They automate too broadly. They expect autonomy on day one.
Thin-slicing forces focus. And focus is what gets you from idea to proof in days instead of quarters.
What Happens Next
The system I built is now on the AWS re:Invent stage, scaled and productized by Sumo's engineering team: https://www.linkedin.com/posts/sumo-logic_aws-reinvent-ai-activity-7401375682012094464-BYFn
(Here's the walk-through demo of the finished product: https://www.sumologic.com/blog/agents-dojo-ai-soc-analyst-mcp)
I'm incredibly proud of what we've built together.
And I'm now doing the same thing for other companies.
If your AI initiative is stuck—overbuilt, directionless, or trapped in the gap between "cool tech" and "actual customer value"—this is the approach that gets you unstuck.
Three weeks to a working agentic prototype that proves your thesis and unlocks your roadmap.
That's Snowball Sprint.
Schedule a call with me if you want to talk about your AI challenges and see whether Snowball Sprint is the right fit. No pitch—just an honest conversation… and I'll share a few insights, whether or not we end up working together: https://calendly.com/snowballsprint/30min
Greg
