Machine-Speed Triage: Compressing MTTR with Claude Code Dynamic Workflows

Greg Heffner June 14th, 2026

It is 2:14 in the morning and an alert fires. A vulnerability scanner flagged a CVE on an internal host, and that same CVE just lit up against the CISA Known Exploited Vulnerabilities catalog. In a lot of shops this is the start of a seventy minute slog: somebody wakes up, pivots between five consoles, hand correlates the alert to a MITRE ATT&CK technique, guesses at how far the damage could reach, and finally writes a remediation ticket that gets actioned in the morning. The attacker is not waiting for morning.

This post is about closing that gap with a Claude Code dynamic workflow. The thesis is narrow and measurable: the right kind of automation does not just throw more robots at the SOC, it collapses the specific stages of incident response where your time actually goes. And the interesting part is not the agents. It is the thing coordinating them.

What a dynamic workflow actually is

Claude Code shipped dynamic workflows as a research preview in late May 2026, and the one sentence that matters is this: a dynamic workflow is a JavaScript script that orchestrates AI agents. The plan lives in code.

That sounds small. It is the whole game. With a normal agent or a chat session, the AI itself is the orchestrator. It decides turn by turn what to do next, and every intermediate result, every fat log dump, every dead end, piles up in one context window that you pay to re-read on every step. A workflow moves the plan out of the model and into a script you wrote. The loops, the branching, the intermediate results all live in plain script variables, and only the final, verified answer ever comes back to you. The orchestration is deterministic, ordinary code you can read and re-run, while each individual agent runs in its own fresh, clean context window and is thrown away when it is done.

The script gets a handful of primitives, and two of them are the backbone of any SOC pipeline:

• agent(prompt, opts) spawns one fresh agent. Hand it a schema and it has to return a validated, machine-readable object instead of loose prose, which is exactly what you want for a verdict, a confidence score, or an ATT&CK technique ID.
• parallel(thunks) runs a batch of agents at once and waits for all of them. This is your enrichment fan-out: query every intel source at the same time instead of one after another.
• pipeline(items, ...stages) streams items through stages with no waiting, so alert A can be in the validation stage while alert B is still being triaged. This is your alert queue.

Why that shape is built for the SOC

A SOC runs on two things at once: repeatable process and judgment. SOAR gave us the first. It runs predefined playbooks, "if X then steps Y," which is great until the signal does not match the script and it stalls and pages a human. Most SOAR ends up only half automated, with a person back on the critical path as the bottleneck.

A dynamic workflow gives you both halves in one tool. The JavaScript is the repeatable, re-runnable, auditable spine that SOAR people want. The agents supply the judgment: each one reasons about what it actually found instead of following a frozen branch. Deterministic glue, probabilistic judgment, with a clean line between them. And because the plan is code, you can bake in quality patterns a single AI pass cannot guarantee. The most important for security is adversarial verification: before acting on a finding, spawn several independent agents whose only job is to try to refute it, and keep it only if it survives the vote. That is what turns "fast" into "fast and right."

One alert, end to end

Think of the workflow as a shift lead handing work to a small team of specialists, each one a fresh agent with a single job. Here is that 2:14 a.m. alert run through it instead of through a tired human. Each stage maps to a primitive, and each stage is where a chunk of MTTR disappears.

1. Investigate the intelligence (parallel)

The alert comes in as the workflow's input. The first move is to gather context from every source at once, so this is a parallel fan-out: one agent asks the CISA KEV catalog whether this CVE is actually being exploited in the wild and by when it has to be fixed, one maps the behavior to MITRE ATT&CK, one pulls threat-actor and IOC context. The script waits for all of them, then plain code stitches the results into a single incident picture. Five consoles a human would have tabbed through one at a time, queried in parallel and merged in code.

2. Triage on the way in (pipeline)

Because the agents return structured results, a pipeline triage stage can classify and deduplicate each incident against a strict schema and drop the obvious false positives that drive alert fatigue. As a pipeline, the next alert in the queue starts its own investigation the moment this one moves on. This is the stage that stops noise from ever reaching a person.

3. Validate the impact

Next an agent works out the blast radius: which users, services, and systems are in scope, whether there is any sign of lateral movement, and what the likely root cause is. It returns a structured impact object, not a wall of text, so the next stage can act on it programmatically. This is the step that usually eats hours of an analyst's night, done in seconds.

4. Verify before acting

Now the adversarial gate. Before anything touches a production box, the script spawns several independent verifier agents told to refute the finding, defaulting to "not real" when unsure. It survives only on a majority. A single confident model can be confidently wrong; a panel told to tear the conclusion apart catches the plausible-but-false ones before they turn into action. Because it is in code, this runs the same way every time and every step is logged for you to audit later.

5. Remediate

Finally an agent writes the playbook: a ranked set of actions tied to the validated techniques, each reversible where possible with a rollback noted, and prioritized against the KEV due date. If you want it to go past recommending, that agent can be given the tools to open a ticket, stage a patch, or isolate the host. And the only thing that reaches the on-call analyst is that one verified playbook, not the hundreds of rows of raw output that lived and died inside the agents.

What it does to the clock

MTTR, the mean time to respond and resolve, is mostly measured in days, and that delay is expensive. IBM's 2024 Cost of a Data Breach report put the average breach lifecycle at 258 days and the average cost at a record 4.88 million dollars, and found breaches closed faster cost dramatically less. The reason it drags is the front of the funnel: false positive rates often run past 50 percent, a large share of alerts never get investigated at all, and a single investigation averages around seventy minutes. Meanwhile attacker breakout times in 2025 have been clocked as fast as four minutes. You cannot win that race with a process that starts by waking somebody up.

A workflow attacks exactly the stages where that time hides. Triage and the parallel intel fan-out compress the dead time before a human is paged. The impact-validation stage compresses the investigation, the single most expensive step. The remediation stage replaces a hand-written ticket with a ranked, ready plan. Published systems show the size of the prize: vendors report triage analyses dropping from tens of minutes to under a minute, and IBM's 2025 report found heavy automation users saved roughly 1.9 million dollars per breach and cut 80 days off the lifecycle. Treat those as the achievable envelope, not a promise, and instrument your own before-and-after per stage.

Final Thoughts

The win is not "add more agents." It is moving the plan into code so the expensive, repeatable, judgment-heavy middle of incident response runs at machine speed and gets argued with before a human ever sees it. The attacker already operates at machine speed. For years our answer to a four minute breakout was a process that started by waking somebody up. A dynamic workflow lets the boring, fast, repeatable part run on its own and hands the on-call analyst the one thing they actually needed at 2:14 a.m.: a verified finding and a ranked way to fix it. Spend your people on the judgment that earns it, and let the clock work for you for once.