Agentic SOAR: What Changes When the Decision Happens at Runtime

In the last post I made the case that the five-to-ten playbook ceiling wasn't a failure of effort - it was teams correctly finding the boundary of what deterministic automation can do. This post is about what happened after teams hit that ceiling, because I watched it for years and it explains why "just write better playbooks" was never going to work.

Here's what the ceiling actually looked like from the inside. Teams didn't stop working after playbook ten. Something broke - hopefully something we were monitoring, or now we had to build that too - and sometimes the fix was trivial (an API key, a field rename, etc). But often the break revealed a new sub-case of the use case we thought we understood. So we did what everyone did: added an exception, or another branch. What started as a straightforward playbook splintered, version by version (“...oh god we need backwards compatible version control” was a moment everyone hit quickly), into something much bigger and much harder to reason about. You weren't adding more use cases… you were making the ones you had much more complex - oftentimes in the name of making them more resilient - until eventually a full rewrite was cheaper than the next patch.

Instead of building playbook eleven, all the energy went into keeping the ten you had alive. Gorka Sadowski, who helped coin the term SOAR at Gartner, described the same slow motion spiral: every new tool, new use case, or new exception sent the playbook team back to work - "a never ending story," with ROI getting progressively worse

Every exception is a question you couldn't ask

It took me a while to see the pattern from within the spiral, but once you see it you can't unsee it: every exception in a playbook is a pre-written answer to a question the playbook couldn't ask at runtime.

A decision tree can't wonder. It can't pull context it wasn't wired for, and it can't weigh a situation it wasn't shown in advance. Deterministic systems are brittle by design - the same property that makes them predictable in stable, well-understood conditions makes them fail on ambiguity, edge cases, and change. So when reality drifts, the only move available is to keep digging the hole deeper: another branch, another lookup table, another exception. The splintering I watched is just what a deterministic architecture does when you ask it to approximate judgment: enumerate, one pre-written answer at a time.

That works right up until the questions stop being enumerable - which, in a SOC, turns out to be almost immediately.

{{ebook-cta}}

The example every SOC has lived through: identity containment

Take the response action every team wants automated: suspend a user account, or force a password reset, when an identity alert goes malicious. Session hijack, impossible travel, credential stuffing that landed - contain the account.

The playbook version starts simple: if determination = malicious, suspend user. Then the realities of a human organization show up. You probably don't want to auto-suspend your CEO mid-board-meeting (or, ever?). You almost certainly don't want to auto-suspend the admin of your identity provider, because that's how you lock yourself out of the very system you'd use to fix it. So you do what we did in the old days: build groups. Executives here, admins there, service accounts over there. Users end up in multiple groups. And you've just signed up for the real job, because those groups have to be maintained - every onboarding, every promotion, every team move is a reassessment that never reliably happens… and so the groups go stale.

Then the automation takes the wrong action once. It suspends someone it shouldn't have, or fails to act on someone it should have, because the group data was six months stale. The action gets flipped to manual, and the containment playbook becomes a notification playbook. You automated it wrong once, and that was the end of that.

Notice what the playbook was actually demanding: a second copy of your org chart, living inside the security tool, kept current forever by hand. Organizations already struggle to keep the real org chart current. The deterministic approach automates the action and hands you a second job nobody scoped: maintaining a shadow model of your company. The automation is only ever as good as that model is fresh.

What changes at runtime

Now run the same alert through an agentic investigation, and watch where the org context comes from.

An agent investigating an identity alert asks questions as it goes: who is this user, what groups do they hold in the identity provider, what do they normally access, what does the HR system say their role is, what does the asset inventory say about the machine involved. The key point to remember is that those sources are already maintained by the business itself because the business doesn't function otherwise. Developers sit in the right identity provider group because that's how they get access to do their jobs. HR data is current because payroll depends on it. Nobody had to build a parallel structure for the agent - it inherits the work of the structure of the organization.

And that context, gathered as a byproduct of the investigation, is still in hand when it's time to decide what to do about the determination. Malicious, high confidence, standard action says suspend the account - but the entity context says this is the president of the company. A system reasoning at runtime doesn't blindly fire, and it doesn't have to break the workflow either. It can adjust the workflow based on the context: downgrade the automatic action to an approval, route it to the right person, and say why. The playbook needed someone to imagine that scenario in advance and write the exception. The agent derived it at runtime, from context it had already gathered.

That's the whole difference, and it's why the splintering stops. The questions get asked live, against sources the business keeps fresh for its own reasons, instead of being answered in advance against a shadow model that's stale the moment after it was copy pasta’d.

What doesn't change

Here is where I continue to pay down my debt, because I made a promise back in the first post that this series wouldn't pretend determinism is obsolete: the action itself should still be deterministic. When the decision is made to suspend an account, you want that suspension to execute the same way every single time - gated where you said gate it, logged where you said log it, with a known rollback. Nothing about runtime reasoning changes that, and anyone telling you the execution layer should get creative is selling you a different bridge.

What moves to runtime is the decision around the action: whether to take it, when, for whom, with what level of human sign-off. That's the judgment work - the part that generated all those splintered branches when we tried to enumerate it in advance. Agentic where judgment lives, deterministic where response lives. This post is just the story of where the judgment part actually has to happen.

More coming in this series - I've learned my lesson about promising the exact next topic (the content plan has survived contact with exactly zero of my drafts), so I'll just say there's plenty left to cover. Bring your skepticism, I've always got mine handy.