SOAR vs Agentic SOC: Where a Playbook Breaks on a Real Alert
Every vendor in the category now has a version of the sentence “SOAR is dead.” It is a good headline and a bad diagnosis. SOAR is not dead. It is sitting in the wrong seat. Playbooks were asked to make judgments, and judgment is the one thing a decision tree cannot do. Put the playbook back where it belongs, executing a decision after something else has made it, and it is still the most reliable component in the building.
This post runs one alert twice. Once through a SOAR playbook written the way most of them are written, and once through the five reasoning agents in HawkEye’s AI SOC. The point is not that the agents win. The point is to see exactly where the playbook stops being able to continue, because that is the line a SOC architect has to draw.
The Alert
A phishing email reaches a finance user. Thirty minutes later the identity provider logs a successful sign-in for that user from an IP in a country the organization has no staff in. The email security gateway raises one alert. The identity provider raises another. They arrive two minutes apart in the SIEM, with different schemas and no shared case ID.
This is an ordinary Tuesday. It is also the kind of sequence CrowdStrike’s 2026 Global Threat Report was describing when it put the average eCrime breakout time at 29 minutes in 2025, a pace HawkEye’s threat advisories track week to week. The attacker has already moved laterally by the time the second alert lands.
Run One: The Playbook
The phishing playbook fires on the first alert. It extracts the sender, checks the domain against a reputation feed, detonates the attachment in a sandbox, and opens a ticket. The sandbox returns clean, because the attachment was a lure with no payload and the real action was a credential-harvesting link. The playbook has a branch for malicious attachments and a branch for malicious URLs. The URL was shortened. The reputation feed has not seen it. The playbook takes the clean branch and closes the ticket as informational.
The suspicious-login playbook fires on the second alert. It checks whether the country is on a blocklist. It is not. It checks whether MFA succeeded. It did, because the attacker phished the MFA code along with the password. The playbook has no branch for “MFA succeeded but the session should still be suspect.” It tags the login as a travel anomaly and routes it to a queue a human will reach in four hours.
Nothing connected the two alerts, because nothing in either playbook knew to look.
Where the Playbook Broke
Five distinct failures happened in that run, and every one of them is structural rather than a matter of the playbook being badly written.
- Unanticipated scenario: the playbook only has branches for cases someone wrote down in advance. A lure with no payload and a shortened URL was not one of them, so the alert fell through to the default branch, which was “close.”
- No cross-alert context: each playbook runs in its own scope. The login playbook had no way to know a phishing alert for the same user existed, because that knowledge lives in a different playbook’s variables.
- Binary enrichment: every check returned a yes or a no. The reputation feed had not seen the URL, which the playbook treated as “safe” rather than “unknown,” which is the opposite of what an analyst would conclude.
- Schema drift: the identity provider changed a field name in its last release. The playbook’s MFA check silently read an empty value and evaluated it as success. Nobody noticed, because the playbook does not report on fields it could not find.
- No blast-radius logic: had the login playbook been configured to revoke sessions on travel anomalies, it would have revoked the sessions of a finance user during month-end close on a rule that fires on legitimate travel most of the time. The playbook has no concept of what the action costs.
Run Two: The Five Agents
The same two alerts land in HawkEye’s AI SOC. The L1 Triage Analyst picks up the phishing alert and asks the questions an analyst would. Is the sender domain newly registered? Is the link shortened, and where does it resolve? Does the destination page contain a credential form? The reputation feed has not seen the URL, which the agent records as unknown, not safe, and weights accordingly.
The Threat Intel Analyst enriches the resolved domain and the login IP and reports what it found at its real resolution. The IP sits in a hosting range associated with commercial VPN exit nodes. The domain was registered nine days ago. Neither is proof. Both are recorded.
The Investigation Agent is where the two alerts meet. It sees the same user on both, because the agents share a control plane rather than private playbook state, and it pulls the user’s sign-in history, device registrations, and post-login activity. Within three minutes of the login, a mailbox forwarding rule was created and an OAuth consent was granted to an application nobody in the organization has heard of. That is the finding that moves the verdict.
The Alert Summarizer writes one narrative. Phishing lure delivered, credentials and MFA code harvested, session established from a VPN exit, persistence via forwarding rule and OAuth grant. The Responder proposes three actions. Remove the forwarding rule and revoke the OAuth grant, both reversible and released under policy. Revoke all active sessions and force re-authentication, disruptive, gated for a human. The approver reads the narrative and approves in under a minute.
Total elapsed time is measured in minutes of agent work plus one human decision. The playbook run would have surfaced the second alert to a human in four hours, with the first one already closed.
What SOAR Is Still For
Notice what happened at the end of run two. The Responder did not log into the mail server and delete a rule by hand. It called an action, and that action ran deterministically, with retries, error handling, and an audit entry. That is a playbook. It is a very good playbook, and it is doing exactly what playbooks are good at, which is executing a known operation reliably once something else has decided it should happen.
The division of labor an agentic SOC needs is this.
- Agents reason: they read the evidence, correlate across sources, decide what the alert is, and propose what to do about it.
- Policy gates: a written rule decides whether the proposed action runs unattended or waits for a person, based on action class and blast radius.
- Playbooks execute: the approved action runs as a deterministic workflow against the firewall, the identity provider, the mail platform, the ticketing system.
Most organizations that already own a SOAR platform can keep it in that third role without rewriting anything. What changes is that nobody asks it to make a judgment call anymore.
The Honest Trade
A playbook that fails fails the same way every time, which makes it easy to audit and easy to trust within its narrow lane. A reasoning agent can be wrong in ways nobody anticipated, which is why every verdict it produces has to carry its reasoning trace and why the consequential actions have to stop for a person. The staffing reality makes that person precious. ISC2’s 2025 Cybersecurity Workforce Study found 59 percent of organizations reporting a critical or significant skills gap. The agents exist to spend that person’s attention on the one decision that matters in the case above, not on four hours of reconstructing it from two disconnected tickets.
Frequently Asked Questions about SOAR and the Agentic SOC
Does an agentic SOC replace SOAR?
It replaces SOAR as the thing that decides what an alert is. It keeps SOAR, or a component like it, as the thing that executes an approved action reliably. Reasoning moves to the agents, execution stays deterministic, and a written policy sits between them.
Where do SOAR playbooks fail in practice?
On alerts nobody anticipated when the playbook was written, on investigations that need evidence from more than one alert or tool, on enrichment results that are unknown rather than yes or no, on silent schema changes in upstream tools, and on actions whose cost depends on context the playbook cannot see.
Can existing SOAR playbooks be reused in an agentic SOC?
The execution playbooks can, meaning the ones that perform a discrete operation like revoking a session or blocking an IP. The decision playbooks, the ones with branching logic that tries to classify an alert, are the part the reasoning agents take over.
Is an agentic SOC less predictable than SOAR?
Its verdicts are less predictable, which is the point, since it adapts to each alert. Its actions are not, because consequential actions run through the same policy gate and the same deterministic execution every time, and every verdict carries a reasoning trace that can be reviewed.