D2D Coordinator: Mission Planning, Re-Planning, and When to Call a Human

The coordinator node is where D2D agentic systems live or die. Get it wrong and you have an expensive loop that hallucinates plans. Get it right and you have a system that degrades gracefully under failure and knows exactly when to stop and ask a human.

Mission Decomposition

When a high-level objective arrives — say, "investigate the spike in failed authentication events from IP range 203.0.113.0/24 over the last two hours" — the coordinator's first job is to decompose it into a directed acyclic graph (DAG) of sub-tasks:

mission: investigate-auth-spike
tasks:
  - id: t1
    type: query_siem
    params: { query: "failed_auth src_ip:203.0.113.0/24 last:2h", limit: 500 }
  - id: t2
    type: enrich_ip
    params: { ip_range: "203.0.113.0/24" }
    depends_on: []
  - id: t3
    type: correlate_events
    params: {}
    depends_on: [t1, t2]
  - id: t4
    type: assess_threat
    params: {}
    depends_on: [t3]
  - id: t5
    type: notify_slack
    params: { channel: "#soc-alerts", severity_threshold: "high" }
    depends_on: [t4]

t1 and t2 run in parallel (no dependencies). t3 waits for both. t4 waits for t3. t5 fires only if t4 assesses the threat as high or critical. This is a standard DAG execution pattern — nothing exotic.

Handling Partial Failure

Real D2D systems fail partially all the time. NVD is down. The SIEM query times out. An IP enrichment service returns a rate-limit error. The coordinator needs a re-planning policy:

1. Retry with backoff — for transient failures (rate limits, timeouts), retry up to max_retries with exponential backoff
2. Substitute with degraded result — if an enrichment worker fails, the coordinator can continue with a null enrichment and flag the gap in the output
3. Re-plan the DAG — if a critical path task fails, the coordinator re-decomposes: can the goal still be achieved with a different approach?
4. Escalate to human — if re-planning fails or the mission requires a decision the coordinator isn't authorized to make (e.g., "block this IP range at the firewall?"), it stops and pages the human

The key constraint: the coordinator must never guess past a failure. A coordinator that fabricates enrichment data because the API was down is worse than one that says "I couldn't complete this step."

When to Call a Human

This is the hardest design decision in any agentic system. The coordinator should escalate when:

• An action would be irreversible (blocking a network range, deleting an account, sending an external notification)
• Confidence in the assessment is below a defined threshold (e.g., threat confidence < 0.7)
• The mission has exceeded its time or token budget without completing
• A worker has been killed multiple times and no alternative path exists
• The task requires authorization the coordinator doesn't hold (data sovereignty, legal hold)

Escalation is not failure — it's the coordinator doing its job correctly. A well-designed escalation message includes: what was accomplished, what failed and why, what decision is needed, and what the coordinator would recommend if it had to guess.

The Mission State Machine

states:
  PLANNING → EXECUTING → COMPLETED
                       → PARTIAL_SUCCESS (with gaps flagged)
                       → REPLANNING → EXECUTING
                       → ESCALATED (human decision required)
                       → FAILED (unrecoverable)

Every transition is logged with a reason. An incident post-mortem can trace the full state history of a mission — which workers ran, which failed, what the coordinator decided at each junction, and what the final output was.

Security Implications for CISOs

For a CISO deploying D2D agentic systems, the coordinator's escalation policy is a governance document. It defines:

• What the system can do autonomously vs. what requires human approval
• What the blast radius is if the system misbehaves
• What the audit trail looks like for regulatory purposes

Before deploying any D2D system in production, the coordinator's escalation rules and worker manifests should go through the same review process as any other change to production security controls.

Next: deploying D2D for a real security operations team — including the PagerDuty integration, the human-review queue, and the lessons from running it in anger.