Agentic AI vs SOAR Automation: The Category Boundary

Definitional clarity: what each term actually means

The loose definition of agentic AI, 'software that takes action on its own,' is useless for procurement because it also describes a SOAR playbook that auto-closes a phishing ticket. Precision matters here because the two systems fail differently, get governed differently, and belong in different parts of the security operations stack.

SOAR automation is the execution of a pre-authored decision tree. A human wrote the logic in advance: if condition A, do step B, then check condition C. The system that runs it does not decide anything; it follows the graph. Agentic AI is different in kind, not degree. It is given a goal, not a script, and it reasons about how to reach that goal using the tools, data, and constraints available to it at that moment.

• SOAR: pre-authored logic, executed on a matching trigger, deterministic path
• Agentic AI: goal handed to the system, plan generated at runtime, path varies by evidence
• The dividing line is not 'does it act,' it is 'who decided the action, and when'

The agent vs playbook distinction, precisely stated

A playbook is a map drawn before the journey. It works exactly as long as the terrain matches what the cartographer anticipated. An agent is a navigator dropped into unfamiliar terrain with a destination and a set of tools; it builds the map as it goes.

This distinction shows up immediately in how each system handles a new question. Ask a playbook to explain why it took an action and it can only point to the branch it followed. Ask an agent, and it can produce the chain of reasoning: what it observed, what it inferred, what it ruled out, and why the final action was chosen over the alternatives.

Why agentic systems handle novel situations that SOAR cannot

SOAR is built for repetition. Its entire value proposition depends on the incident matching a pattern someone already coded. When an incident deviates even slightly, the playbook either fails to trigger, triggers on the wrong branch, or completes and produces a result that is technically correct and operationally useless.

Novel incidents are not rare edge cases in modern environments; they are close to the norm. Attackers vary tooling, timing, and sequencing specifically to avoid matching known patterns. An agentic system does not need the incident to match a known shape. It reasons from first principles: what is unusual here, what would explain it, what evidence would confirm or deny each explanation, and what should happen next given the confidence level reached.

The tool-use pattern: plan, invoke, observe, repeat

The mechanism behind agentic reasoning is a loop, not a single inference call. A language or small language model plans a next step, invokes a tool such as a log query, an EDR lookup, or an identity provider call, observes the result, and updates its plan before deciding the next step. This loop repeats until the agent reaches sufficient confidence to conclude or act.

This is fundamentally different from a single large prompt producing a single answer. The agent's intelligence is expressed through the sequence of tool calls it chooses and how it revises its approach based on what each tool returns, not through the model's raw output alone.

• Plan: the model proposes the next investigative or containment step given the current context
• Invoke: a tool call executes against real infrastructure, telemetry, or identity systems
• Observe: the result is folded back into the agent's working context
• Repeat or conclude: the loop continues until the goal is met or the policy envelope stops it

Memory and continuity across investigations

A playbook has no memory beyond the single run; each execution starts cold and ends cold. Agentic systems are expected to carry context: prior findings about a given host or identity, related incidents from the past several days, and the reasoning trail from earlier steps in the same investigation.

This continuity is what lets an agent notice that a low-severity alert today connects to a dismissed alert from last week, and escalate accordingly. Playbooks cannot make that connection because each one only sees the trigger event in front of it.

Governance requirements unique to agentic systems

Governing a playbook is straightforward: review the logic once, approve it, and it behaves the same way every time. Governing an agent is a different exercise, because the agent's exact sequence of actions is not fixed in advance. Governance has to constrain the space of possible actions rather than approve a single fixed path.

This requires three things a playbook never needed: an approval envelope that defines which action categories the agent may take without a human, hard action bounds that cap blast radius even for approved categories, and an evidence chain that records what the agent observed, inferred, and decided at every step so the reasoning can be reconstructed after the fact.

• Approval envelope: which action classes run autonomously, which require human sign-off
• Action bounds: scope, rate, and reversibility limits on any action, even an authorized one
• Evidence chain: a reconstructable record of observation, inference, and decision, not just the final action

Where playbooks remain the right primitive

None of this argues that SOAR should disappear. For deterministic, high-volume, low-ambiguity operations, a playbook is the correct tool and an agent is overkill. User provisioning, password resets, standard access revocation on offboarding, and known-IOC blocklist updates all fit this profile: the correct action is knowable in advance, and reasoning adds cost without adding value.

The mistake is treating this as an either-or choice. Mature security operations use both, deliberately, in the roles each is built for.

Coexistence patterns and the misuse to watch for

The healthy pattern is agent as decision-maker, playbook as executor. The agent investigates, concludes that containment is warranted, and invokes the specific playbook that performs the deterministic part of the response. The agent supplies judgment; the playbook supplies repeatable, auditable execution.

The unhealthy pattern is what can be called agentic-washed SOAR: a vendor wraps an existing playbook library with a chat interface or a thin large-language-model layer that rewrites playbook descriptions, then markets the result as agentic. Nothing about the decision path has changed. The tell is simple: ask what happens when the incident does not match any existing playbook. If the honest answer is 'nothing, or a generic escalation,' the system is not agentic regardless of what the interface looks like.

Evaluation questions to bring to a vendor conversation

Buyers evaluating either category should ask questions that expose the actual decision mechanism rather than the marketing layer around it.

• When the incident does not match a known pattern, what does the system do next, and can you show it happening on a case you did not pre-stage?
• Can the system explain, in evidence and reasoning rather than a fixed branch label, why it chose one action over an alternative?
• Does the system retain context across related incidents, or does every alert start from zero?
• What is the approval envelope, and can it be edited by the customer without vendor engineering involvement?
• Is there a full evidence chain per action, independent of the final action log, that survives audit and legal review?

How AuraXP and AirWatch implement the agent and governance pair

AuraXP inside Spharaka Sphere is built as a multi-agent fabric with specialised roles for investigation, containment planning, evidence chaining, and human liaison. These agents run the plan, invoke, observe loop against live telemetry and identity systems, and they carry context across related incidents rather than treating each alert in isolation.

AirWatch is the governance layer that makes this safe to operate. It defines the approval envelope for each agent role, enforces hard action bounds regardless of confidence level, and records the full evidence chain behind every decision so it can be reconstructed during audit or incident review. Deterministic operations that agents decide to invoke, such as access revocation or password reset, still run through standard playbook execution. The agent decides; AirWatch bounds the decision; the playbook, where one applies, executes it.