Workshop architecture and the harness diagram

The 6-agent triage harness

The finished analyst console runs a 6-agent harness that processes each incident through a structured pipeline. Here’s how the agents are organized:

flowchart TD
A[Incident Intake] --> B[Coordinator]
B --> C[Cmd-Line Analyzer]
B --> D[Identity Analyzer]
B --> E[Network Analyzer]
B --> F[Activity Analyzer]
C --> G[Triage Synthesizer]
D --> G
E --> G
F --> G
G --> H[Response Agent]
H --> I[HITL Approval]

How an incident flows through the harness

Here’s what happens when an analyst clicks “Investigate” on an incident:

1. Intake — The incident data (alert type, raw telemetry, user/host context) is pulled from D1 and handed to the Coordinator.

2. Coordinator dispatches — The Coordinator examines the incident type and dispatches the relevant sub-agents in parallel. For a malware incident, all four analyzers run simultaneously. For a phishing incident, the Command-Line Analyzer might be skipped.

3. Parallel analysis — Each analyzer examines one dimension of the incident:

• Command-Line Analyzer — Decodes obfuscated commands, identifies known attack patterns (Base64 PowerShell, reverse shells, LOLBins).
• Identity Analyzer — Checks user context: role, MFA status, recent privilege changes, impossible travel.
• Network Analyzer — Evaluates IP reputation, DNS patterns, geolocation anomalies, known C2 infrastructure.
• Activity Analyzer — Reviews temporal patterns: time-of-day anomalies, volume spikes, behavioral deviations from baseline.

4. Triage Synthesizer — Collects the structured findings from all sub-agents, cross-correlates them, and produces a triage card with a severity score (critical/high/medium/low), confidence rating, and key indicators.

5. Response Agent — Takes the triage card and generates a concrete action plan: which accounts to disable, which hosts to isolate, which firewall rules to apply, and which teams to notify.

6. Human approval — The analyst reviews the triage card and action plan, then approves, modifies, or rejects the recommended actions.

The progressive build path

You won’t build all of this at once. The workshop is designed so that each lesson adds one capability and produces a visible change in your deployed app.

Each state transition requires a small, well-defined change: typically adding a binding to wrangler.jsonc, running one CLI command, and changing the STATE environment variable.

Mapping primitives to the pipeline

Each Cloudflare primitive plays a specific role in the architecture:

• Workers — The runtime foundation. Your analyst console (both the React UI and the API routes) runs as a Cloudflare Worker deployed to the edge.
• D1 — The data layer. Incident records, alert metadata, and historical triage results are stored in a serverless SQLite database accessed via a Worker binding.
• Durable Objects — The state layer. Each incident gets its own SIRTSession Durable Object that holds investigation state, scratchpad data, and the triage card — all persisted automatically.
• Workers AI — The inference layer. Each sub-agent calls an LLM to analyze its dimension of the incident. Inference runs at the edge with no external API keys needed.
• Agents SDK — The orchestration layer. The Coordinator and sub-agents are Agents SDK agent instances with lifecycle management, state persistence, and structured tool calling.
• Sandbox SDK — The execution layer. The Network Analyzer uses Sandbox SDK to run CLI commands (DNS lookups, WHOIS queries, hash checks) in an isolated environment.
• Dynamic Workers — The automation layer. The Response Agent generates custom Worker code (firewall rules, webhook handlers) and deploys it at runtime using the Workers for Platforms dispatch namespace.