The Architectural Primitive
The architectural primitive behind accountable agentic SOC.
An Agentic Task is bounded agentic reasoning that runs inside a deterministic playbook node. The AI iterates, selects tools, makes intermediate decisions, and stops when it should — under hard caps on iteration count, compute cost, tool scope, and approval gates. One reasoning context. One audit trail. One accountable workflow owner.
It’s the primitive Morpheus uses to deliver agentic SOC. Same category as Torq Socrates, CrowdStrike Charlotte AI, Dropzone, Prophet, and 7AI — different architectural choice about where the reasoning lives. Multi-agent platforms distribute reasoning across coordinated agents; Morpheus contains the reasoning in a single bounded context that lives in a workflow node. The trade-off is real. Bounded reasoning excels at producing one defensible audit trail per incident — which is what NIS2, DORA, and EU AI Act Article 14 expect a regulator to read.
1
— not one per agent, not one per tool
4
— iteration · cost · tool scope · approval gate
800+
from the parent playbook — no per-task plumbing
3
— NIS2 · DORA · EU AI Act — fit by structure, not overlay
What is bounded agentic reasoning?
A reasoning pattern that runs autonomously — and stops when it should.
Bounded agentic reasoning is an AI reasoning pattern in which an autonomous agent operates inside a deterministic workflow with explicit constraints on iteration count, compute cost, tool scope, and approval gates — guaranteeing that the reasoning loop terminates, stays within cost limits, and produces an auditable trace inside the parent workflow’s audit trail.
An Agentic Task receives a goal, queries the Cybersecurity Triage Reasoning Graph for relevant investigation patterns, calls tools through the unified integration layer, evaluates results, decides the next step, and emits trace data to the audit trail at every checkpoint. The reasoning is bounded by the graph. The execution is bounded by governance. The trace is bounded by the audit format.
Contrast that with the default behavior of an unbounded LLM: open-ended iteration, undefined tool scope, no cost ceiling, no termination guarantee, and reasoning traces that live outside any production workflow audit trail. That pattern is fine for a research prototype. It is not fine for a SOC running under SEC cyber disclosure rules, NYDFS Part 500, or EU AI Act Article 14.
The word that matters in bounded agentic reasoning is bounded. — The autonomy is real. Every bound is enforced before the LLM call, not reconciled afterward.
When a bound is hit, the Agentic Task returns control to the deterministic engine with a documented termination reason. The reasoning is auditable because the bounds make it auditable.
Morpheus is agentic SOC. The Agentic Task is how.
The agentic SOC category includes Torq Socrates, CrowdStrike Charlotte AI, Dropzone, Prophet Security, and 7AI. Morpheus is in the same category — with a different choice about where the reasoning lives.
The multi-agent mesh
Torq Socrates · Charlotte AI · Dropzone · Prophet · 7AI
Multiple specialized agents — detection, enrichment, response, case management — coordinating through a message bus or shared memory. Each agent runs autonomously within its scope.
A genuinely powerful architecture for independent, well-scoped functions. The trade-off lives in the seams: coordination latency between agents, context handoffs across an agent boundary, and one audit trail per agent the SOC team stitches when an EU regulator asks “who decided.”
Bounded reasoning
D3 Morpheus · the Agentic Task primitive
One reasoning context inside a deterministic playbook node. The AI iterates, selects tools, makes intermediate decisions — within four platform-enforced bounds. When the Agentic Task returns, deterministic execution resumes.
The trade-off lives in scope: bounded reasoning isn’t the right pattern for every problem. It is the right pattern for producing one defensible audit trail per incident — and for tying every reasoning step, tool call, and approval to a single accountable workflow owner.
Both architectures are agentic. The interesting question isn’t “agentic or not” — that’s settled. The interesting question is what each architecture makes easy, and what each makes hard. This page argues that for regulated SOC environments running under NIS2, DORA, and the EU AI Act, bounded reasoning makes the right things easy.
Four bounds. Platform-enforced.
Every Agentic Task executes under four explicit bounds. Not agent discipline. Not LLM honor system. Enforced at the platform layer, before the call.
∞
Iteration cap
Hard limit on how many times the reasoning loop runs before producing output or returning control.
Default 12 iterations.
$
Cost cap
Token spend capped per reasoning step. Predictable compute consumption. No runaway loops on a novel input.
Default $0.40 / task.
⊂
Tool-scope limit
The Agentic Task can only call the integrations the playbook author granted. Every call logged with parameters and response.
✓
Approval gate
State-changing actions above a configured command-risk tier pause for analyst approval. The reasoning proposes; a human signs off.
Platform-enforced.
A node in a playbook. Not a service outside the workflow.
An Agentic Task is one node in a deterministic playbook. Deterministic execution runs to that node, the Agentic Task reasons, and deterministic execution resumes.
A playbook author drops an Agentic Task node into the workflow at the moment where reasoning is genuinely needed — typically a moment of novel evidence, where the analysis path can’t be pre-scripted but the inputs are well-defined.
When the deterministic engine reaches the node, it hands off the alert context, the inherited tool scope, and the parent playbook’s approval gates. The Agentic Task reasons autonomously within those bounds: it iterates, calls tools from the granted scope, validates evidence, drafts conclusions, and writes every step to the parent’s unified audit trail.
When the Agentic Task either reaches a verdict or hits a bound, it returns control. The deterministic playbook resumes — applying the verdict to downstream nodes, escalating where the approval gate paused work, or closing the case.
How the two architectures compare in production.
Seven architectural properties that define how each pattern behaves at scale — and how each will be evaluated by an EU auditor reading your incident records.
| Architectural property | D3 Morpheus — Agentic Task | Multi-agent mesh |
|---|---|---|
| Reasoning location | Inside a deterministic playbook node. One context, contiguous reasoning, returns control when complete or when a bound is hit. | Distributed across coordinated agents — detection, enrichment, response, case management — communicating through a message bus or shared memory. |
| Audit trail granularity | One unified trail per incident. Every reasoning step, tool call, approval gate, and action attributed to the same workflow owner. | One trail per agent. An auditor under NIS2 Article 20 stitches multiple traces together to reconstruct the decision chain. |
| Tool inheritance | Inherits the 800+ self-healing integration catalogue from the parent playbook. Tool scope is the bound; no per-task connector plumbing. | Each agent maintains its own integrations independently. API drift tracked per-agent across the mesh. |
| Approval gates | Enforced by the deterministic engine based on command-risk tier policy. The AI proposes; the platform decides whether human approval is required. | Each agent self-enforces approval logic. Distributed authorization is easier to drift and harder to audit at scale. |
| Failure semantics | Bound exhaustion returns control to the deterministic playbook with a documented termination reason. Predictable, debuggable. | An agent failure or hallucination becomes the input to downstream agents — failure modes propagate along the mesh. |
| Compliance footprint | Structurally mapped to NIS2 Article 21, DORA Articles 17–23, EU AI Act Article 14. Oversight enforced at the action layer, not added as overlay. | Compliance story constructed after the fact. Bolt-on governance tooling typically required to produce a regulator-ready audit narrative. |
| Operational ownership | One reasoning engine to operate. Self-healing layer handles vendor API drift across all 800+ tools at the platform level. | Operate the mesh. Coordinate agent updates. Debug cross-agent context handoffs. Manage inter-agent message bus failures. |
The 800+ integration catalogue, inherited.
An Agentic Task inherits its full tool surface from the parent playbook. No per-task wiring. No per-agent connector code. No drift to track per agent.
In Morpheus, integrations live once at the platform layer, in the self-healing integration catalogue. Every playbook node — deterministic or Agentic Task — sees the same tool surface. When a vendor ships an API change, the self-healing layer detects it, generates the corrective code, and propagates the fix to every customer tenant.
For the Agentic Task specifically: the playbook author scopes which subset of the 800+ catalogue the task may call. That scope is the tool-scope bound. The reasoning is free to pick which tools to call and in what order within the scope. It cannot reach for tools outside the envelope.
Command-risk tagging drives the approval gate.
Every callable action carries one of four command-risk tiers. The tier — not the agent — decides whether human approval is required. Approval gates aren’t a feature the AI chooses to honor; they’re a gate the AI can’t bypass.
T1
Read-only
Investigation, enrichment, lookups. The Agentic Task uses these freely to gather evidence.
Runs autonomously
T2
Reversible
Tag, label, low-impact ticket updates. Easy to roll back; analyst review on the audit log, not the action.
Autonomous · logged
T3
State-changing
Account disable, session revoke, file quarantine, mailbox purge. Material effect on the environment.
Analyst approval
T4
High-impact
Host isolation, mass account disable, network segmentation. Reversible at cost; named approver chain.
Named approver chain
Every approval — and every denial — writes to the unified audit trail with named approver, timestamp, and reasoning context. EU AI Act Article 14 human-oversight requirements are satisfied by structure, not by overlay.
What an Agentic Task does on the day you need it.
A novel zero-day. An MSSP fan-out across 14 customer tenants. A 600-finding vulnerability batch. Three production scenarios where bounded agentic reasoning earns its keep.
A novel zero-day fires across your environment 80 alerts in the first six hours · novel exploitation path
An analyst opens each alert manually, cross-references the CVE, queries identity and EDR for affected accounts, and assembles the chainability picture by hand.
An entire shift’s capacity, just for triage.
A single playbook step reasons across each alert: validates exploitation evidence against the CVE pattern, pivots through identity + EDR + cloud, produces a per-alert chainability verdict.
Bounds: 12 iterations · $0.40 per alert · approval before any account-disable or host-isolate.
80 alerts triaged. Each carries a unified audit trail. Four high-confidence chainable findings land in the analyst queue with full evidence; the other 76 are documented and closed.
An MSSP investigates across 14 customer tenants Different identity stacks · different email security · different change windows
An L2 analyst investigates each tenant in sequence — switching consoles, applying tenant-specific SOPs, tracking which approvals each tenant requires.
Sequential. One tenant at a time.
A parent playbook fans out to 14 parallel Agentic Task instances, each scoped to one tenant. Each inherits its tenant’s tool grants, approval gates, and SOPs.
Tenant scoping is enforced by the tool-scope bound, not by post-hoc filtering.
14 tenant-specific investigations completed in parallel. 14 unified audit trails, one per tenant. Each tenant’s GRC team reviews their own audit trail in isolation.
A 600-finding vulnerability batch arrives Mix of CVE-class findings and AI-discovered chainable exploit paths
600 findings triaged manually at 60 minutes each. By the time triage completes, hundreds have already been actively exploited in the wild.
600 analyst-hours for an 8-analyst team.
Batch playbook spawns one Agentic Task per finding. Each reasons across scanner output, asset inventory, identity graph, and threat intel for a chainability verdict.
Bounds: $0.25 cost cap per finding · approval before patch deployment or workload isolation.
600 findings triaged. The 47 actively-exploited findings land in the queue with full evidence; the 91 chainable findings prioritized for next sprint; the rest queued for routine patching.
When Agentic Task fits — and when it doesn’t.
Bounded agentic reasoning is powerful — but it isn’t the right primitive for every problem. The right architecture uses the right tool for each step. Vendors who pitch their AI as a solution to every SOC problem are pitching a product that doesn’t exist.
The analysis path is novel and the inputs require reasoning.
Autonomous reasoning within bounds. Tool selection at runtime. Intermediate decisions the playbook author couldn’t pre-script.
- The scope is novel — combinations the playbook can’t anticipate
- Inputs are structured — but the analysis path is not
- The outcome requires reasoning deterministic logic can’t capture
- Chainability analysis across newly disclosed vulnerabilities
- Correlation across unfamiliar telemetry — schema known, analysis not yet codified
The analysis path is known and the inputs are predictable.
Pre-scripted logic. Hard-coded validation rules. Same input, same output, every time — what most SOC workflows need most of the time.
- Provably-deterministic workflows — compliance reporting, regulated state transitions
- High-volume, low-judgment classification — the rule fits on a sticky note
- Strategic risk decisions — legal disclosure, executive notification belong to humans
- Novel tool integrations needed — add the integration first, then deploy the Agentic Task
- Sub-second-latency response paths — DDoS mitigation, runtime exploit blocking
What happens when a bound fires.
Bounds aren’t theoretical — they fire in production. Predictable behavior under every failure mode is what makes the audit trail defensible.
Iteration-cap exhaustion
The reasoning loop runs its configured maximum without producing a final verdict. The Agentic Task returns the partial reasoning state and a documented termination reason; the playbook retries with a different scope or escalates.
Cost-cap exhaustion
Token spend reaches the configured limit. The Agentic Task terminates the reasoning loop immediately — no overrun on cost — returns conclusions it has, and documents the cost-cap exhaustion in the trail.
Tool-scope violation
The reasoning attempts to call a tool outside the granted scope. The platform-level bound blocks the call before it executes, records the attempt, and routes the partial state to the analyst with a scope-violation flag.
Approval-gate timeout
No analyst response within the configured window (default 30 min for T3, 4 hr for T4). The Agentic Task transitions the parent incident to escalation and notifies the on-call chain. The reasoning never proceeds without approval.
Tool-call retries
Individual tool calls retry with exponential backoff on transient failures (network timeouts, rate limits). Each retry counts against the iteration cap. Persistent failures surface in the audit trail with the failing call detailed.
Partial-failure during reasoning
If a tool returns partial or inconsistent results (e.g., one of three IOC sources returns no data), the Agentic Task continues with what it has and records the gap. The reasoning never silently substitutes fabricated values for missing data.
This is why the bounds exist: predictable, debuggable, fully auditable behavior under every failure mode — not just the happy path. The audit trail is the same shape whether the Agentic Task succeeds, hits a bound, or encounters a tool failure.
One GRC surface. Not a collection of agents.
A regulator under NIS2, DORA, or the EU AI Act asks one question: show me the decision trail. Multi-agent architectures answer with N traces that must be stitched. Morpheus answers with one record — every reasoning step, every tool call, every approval, every action, every override — tied to the same workflow owner, in the same chronological order.
Bounds, agents, audit trails, deployment.
How does an Agentic Task compare to an agent in an agentic SOC platform?
An agent in an agentic SOC platform is a persistent autonomous component coordinating with other agents through a message bus or shared memory. An Agentic Task in Morpheus is a bounded reasoning step inside a parent workflow — autonomous reasoning within configured limits on iteration count, compute cost, tool scope, and approval gates. Both architectures are agentic; the difference is that Morpheus contains reasoning inside a single context with platform-enforced bounds, producing one audit trail per incident rather than one per agent.
What is an agentic SOC?
An agentic SOC is a security operations architecture in which AI agents — scoped to functions like detection, enrichment, correlation, or response — operate autonomously to investigate alerts. D3 Morpheus is an agentic SOC platform. The architectural difference among agentic SOC platforms is where the reasoning lives: distributed across coordinated agents (Torq Socrates, CrowdStrike Charlotte AI, Dropzone, Prophet, 7AI), or contained inside bounded reasoning within a deterministic workflow node (Morpheus).
What are the four bounds on an Agentic Task?
Every Agentic Task executes under four explicit bounds, enforced by the platform before each LLM call: (1) iteration cap — hard limit on reasoning loop iterations; (2) cost cap — maximum token spend per reasoning step; (3) tool-scope limit — the subset of the 800+ integration catalogue the task may call; (4) approval gate — state-changing actions above a configured command-risk tier pause for analyst sign-off.
When would you use an Agentic Task instead of a deterministic playbook step?
Use an Agentic Task when the analysis path is novel, the inputs are structured but the reasoning path cannot be pre-scripted, and the outcome requires reasoning deterministic logic cannot capture. Canonical examples: chainability analysis across newly disclosed vulnerabilities, correlation across an unfamiliar tool’s telemetry, triage of novel alert types. For well-understood repeatable workflows, deterministic playbook steps remain faster, cheaper, and equally effective.
How does the Agentic Task map to NIS2, DORA, and the EU AI Act?
The unified audit trail structurally supports NIS2 Article 21 (governance), DORA Articles 17–23 (ICT incident management and reporting), and EU AI Act Article 14 (human oversight of high-risk AI systems). Regulators want evidence of human oversight at the action level, documented decision logic, and traceable AI behavior. The unified trail provides all three as a normal byproduct of SOC operations — not as a separate compliance artifact built after the fact.
Can an Agentic Task act outside the playbook?
No. The Agentic Task runs inside a deterministic playbook node. It can only call tools the playbook author granted in the tool-scope bound. It cannot escalate, spawn other tasks autonomously, or reach for resources outside its envelope. This is the architectural property that distinguishes bounded agentic reasoning from a free-running agent: the AI’s authority is defined by the platform, not by the AI.
What happens if the Agentic Task hits a bound?
Control returns to the deterministic engine with a documented termination reason. The unified audit trail records the partial reasoning state, the bound that fired (iteration, cost, tool-scope, or approval gate), and any conclusions the task reached before terminating. The deterministic playbook either retries with a different scope, escalates to an analyst, or routes the incident to the next workflow step based on the termination reason. The reasoning never silently fails.
Is Agentic Task available across all autonomy modes?
Yes. Agentic Task is available across all four Morpheus autonomy modes — Deterministic, AI-Assisted, AI-Led, and Autonomous. The primitive doesn’t change between modes; what changes is how much of its output your analysts approve before downstream nodes act. Most customers start in AI-Assisted, graduate to AI-Led, and move specific high-volume workflows to Autonomous.