Deploying D2D Agentic Architecture in a Real Security Operations Team
Theoretical architecture is one thing. Running D2D in a production SOC — with real alerts, real analysts, and a real on-call rotation — is another. Here's what we learned from deploying it.
The Initial Stack
The deployment started with five worker domains:
- SIEM Query — Splunk queries for alert enrichment
- IP/Domain Enrichment — VirusTotal, Shodan, passive DNS
- CVE Lookup — NVD + EPSS scoring
- Identity Resolution — mapping IPs to internal users via Active Directory
- Notification — Slack (low/medium), PagerDuty (high/critical)
The coordinator ran on Claude Opus-tier. Workers ran on Haiku-tier. The killer node ran as a separate process with a 10-second polling loop.
What Worked Immediately
Parallel enrichment. Before D2D, an analyst manually ran 4-5 enrichment queries sequentially per alert. The D2D coordinator ran them all in parallel — SIEM + IP + CVE + identity simultaneously. First-alert triage time dropped from ~12 minutes to ~2 minutes for standard alerts.
Consistent output format. Every alert that went through D2D came out with the same structured summary: affected assets, threat indicators, confidence score, recommended action, evidence chain. Analysts could read them in a predictable pattern without parsing prose.
The killer node earning its keep. In the first week, the killer node terminated three runaway workers — two SIEM query workers that hit a malformed query and looped, and one enrichment worker that got stuck retrying a rate-limited API. Without the killer, each of those would have drained budget and eventually timed out at the API gateway level.
What Broke
The coordinator's DAG was too optimistic. The initial planning prompt assumed all worker results would be available before synthesis. In practice, enrichment workers sometimes returned partial data with errors. The coordinator's first version would fail the synthesis step rather than proceeding with gaps. We fixed this by having workers always return a result (with a status: partial field) rather than erroring out.
Escalation messages were too terse. When the coordinator escalated to PagerDuty, the initial message was machine-readable but analyst-hostile. On-call engineers were getting paged with JSON blobs at 3am. We added a natural-language summary layer that the coordinator generates alongside the structured output.
Token budgets were wrong. The initial budgets were set by gut feel. After two weeks of logs, we recalibrated: SIEM query workers needed 3x more budget than estimated (Splunk results can be verbose), while identity resolution workers needed half as much. Budget calibration is empirical — run it in production and measure.
The Human Review Queue
Escalated missions (those the coordinator couldn't complete autonomously) went into a human review queue with a 15-minute SLA during business hours and a PagerDuty page after hours. The queue UI showed:
- What the coordinator accomplished before escalating
- What it couldn't complete and why
- What decision was needed from the human
- The coordinator's recommendation if it had to guess
Analysts found the recommendation field valuable — even when they overrode it, having a starting point was faster than starting from scratch. After three months, coordinators were right about 78% of the time on the recommendation. That number improved as the routing table was refined.
Governance and CISO Sign-Off
Before going live, we documented:
- Every action type workers could take, with explicit "autonomous" or "human-required" designation
- The maximum token budget per mission (cost control)
- Data residency constraints (no PII leaving the EU region)
- The audit log retention policy (90 days, tamper-evident)
The CISO review of this document took two hours. The key questions were about irreversible actions (we hardcoded human-required for all firewall changes) and data handling (enrichment workers got explicit constraints on what they could send to external APIs).
What's Next for D2D
The pattern is maturing fast. The interesting frontier isn't the coordinator or the worker — it's the inter-domain trust model. When a worker from one domain passes results to a worker in another domain, how do you prevent prompt injection in the intermediate data? How do you verify that the IP enrichment worker's output wasn't poisoned by a threat actor controlling the IP?
These are the problems that will define enterprise-grade agentic security — and they're the problems we're building toward in future PlayCISO War Room scenarios.
Ready to practise the decisions these articles describe?
Run a free War Room →