# D2D Agentic Architecture: How Domain-to-Domain AI Agents Coordinate at Scale

> A deep dive into the Domain-to-Domain (D2D) agentic protocol — the coordinator, worker, and killer node model that lets autonomous AI agents collaborate across security domains without human-in-the-loop bottlenecks.

Source: https://playciso.com/blog/d2d-agentic-architecture-overview · Published: 2026-07-13 · Publisher: PlayCISO (https://playciso.com)

---

Autonomous AI agents are no longer just demos. Production security teams are deploying multi-agent pipelines that span threat detection, triage, remediation, and reporting — all without a human clicking "approve" between every step. The pattern making this work at scale is **Domain-to-Domain (D2D) agentic architecture**. ## What Is D2D? D2D is an architectural pattern where AI agents are scoped to _domains_ (e.g., network monitoring, identity triage, vuln management) and communicate via a structured inter-domain protocol rather than through a central monolith or a shared prompt queue. Think of it as microservices, but for AI agents that reason and act. The key insight: each domain agent owns its context, its tools, and its decision boundary. Cross-domain coordination happens through explicit message contracts, not shared state. This is what makes D2D systems auditable, composable, and surprisingly robust under failure. ## The Three Core Node Types ### Coordinator Node The coordinator is the orchestrator — it holds the mission context and decomposes goals into sub-tasks assigned to worker nodes. It does _not_ execute directly. Its job is: - Accepting high-level objectives from a human operator or upstream system - Routing sub-tasks to the appropriate worker domain - Tracking task state and dependency chains - Aggregating results and deciding whether the mission is complete or needs re-planning - Triggering killer nodes when a worker is stuck, runaway, or producing bad output A coordinator is typically a larger, reasoning-capable model (Claude Opus-tier) because it needs to handle ambiguity and re-plan under partial failure. Latency matters less here than correctness. ### Worker Node Workers are the specialists. Each worker node: - Owns a single domain (e.g., "SIEM query agent", "CVE enrichment agent", "Slack notification agent") - Has a constrained tool set — only the tools relevant to its domain - Accepts structured task messages from the coordinator - Returns structured results (with status, evidence, and confidence scores) - Emits heartbeats so the coordinator can detect stalls Workers are typically smaller, faster models (Haiku-tier) — they're cheap to run and easy to parallelize. The domain constraint is what makes them safe: a network-monitoring worker literally cannot call your billing API. ### Killer Node The killer node is the safety valve — often the most underappreciated part of the architecture. Its job is to terminate workers that are stuck in loops, exceeding budget, or producing outputs that fail a safety check. A well-designed killer node: - Monitors heartbeat timeouts from workers - Watches for token budget overruns - Runs output validation (schema checks, hallucination detectors, policy guardrails) - Issues a KILL signal to the coordinator, which re-routes or escalates to human review Without a killer node, a runaway agent that hits an API loop will drain your budget and produce garbage. With one, the worst case is a graceful re-plan. ## Why D2D Works for Security Security workflows are exactly the use case D2D was built for: - Domain isolation maps to security boundaries — your EDR agent and your cloud IAM agent should not share context or credentials - Auditability is built-in — every inter-domain message is a logged, structured artifact - Blast radius is bounded — a worker node can only take actions within its domain - Human escalation is explicit — the coordinator knows when to stop and ask ## What Each Agent File Looks Like In a typical D2D implementation, each agent is defined by three files: - Agent manifest (manifest.yaml) — declares the agent's name, domain, tool list, model, token budget, and heartbeat interval - System prompt (system.md) — the agent's role, constraints, output schema, and escalation rules - Tool definitions (tools.json or tools.ts) — the exact API surface the agent can call, with input/output schemas The coordinator also has a **routing table** (`routing.yaml`) that maps task types to worker domains, and a **mission schema** that defines what a completed mission looks like. ## Next in This Series In the next post we'll walk through a concrete D2D deployment for a security operations centre — showing the actual manifest files, the coordinator's routing logic, and how killer nodes are wired to PagerDuty for human escalation.