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

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:

1. Agent manifest (manifest.yaml) — declares the agent's name, domain, tool list, model, token budget, and heartbeat interval
2. System prompt (system.md) — the agent's role, constraints, output schema, and escalation rules
3. 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.