.webp?width=1921&height=622&name=usecase-banner%20(1).webp)
Key takeaway
- Dynamic workflows build a task-specific workflow at run time and discard it afterwards. Reference architecture, six patterns and governance for enterprises.
What is a dynamic workflow harness? It is a runtime that compiles a task-specific workflow at execution time from governed building blocks, executes it durably, verifies the result and records every decision along the way. The workflow is no longer designed up front: a runtime builds one for each task, then throws it away. For enterprises, the value and the risk sit in what surrounds that runtime: context, a governed capability registry and decision traces.
TL;DR for leaders
- The shift: the workflow is no longer designed up front. A runtime builds one for each task, then throws it away.
- The proof: a 750,000-line Zig-to-Rust port finished in 11 days with 99.8% of tests passing, using this pattern.
- The enterprise gap: context, a governed capability registry and decision traces. That is where the value, and the risk, now sits.
Claude Code's dynamic workflows make a new idea practical: instead of one agent carrying a whole job, Claude writes a custom orchestration script for each task, spawns a team of fresh-context subagents in parallel, and throws the harness away when the job is done. For enterprises, the lesson goes beyond coding: every task deserves a workflow built for it, running inside guardrails that never move.
The Problem: Two Architectures, Two Failure Modes
Enterprises built automation in two waves, and each fails in a predictable place.
Static workflows (BPM, RPA, DAG pipelines) are designed once and run many times. They are auditable and cheap, but they only cover the paths someone anticipated. The long tail of exceptions, which is where the real work and cost live, falls back to people.
Free-roaming agents handle the long tail in demos. In production, nobody can say in advance what the agent will do, nobody can say afterwards why it did it, cost varies by an order of magnitude between runs, and one bad tool call can write to a system of record.
Static workflows are governable but brittle. Autonomous agents are adaptive but ungovernable. The resolution is the dynamic workflow harness.
The Reference Implementation: Dynamic Workflows in Claude Code
Dynamic workflows in Claude Code are self-authored, ephemeral, multi-agent harnesses. Claude writes a JavaScript orchestration script on the fly, and a runtime executes it in the background to spawn, route and coordinate isolated subagents in parallel.
Why one context window is not enough
When a single context carries a long task end to end, three failure modes appear:
- Agentic laziness: the agent starts thoroughly, then skips files or assumes the rest is similar, and reports the whole job done.
- Self-preferential bias: asked to judge its own output, the agent gives itself the benefit of the doubt.
- Goal drift: over many steps, constraints such as "do not skip any file" quietly fall away.
How workflows fix it
The plan moves out of the model's head and into code. The script holds the loop, the branching and the intermediate results. Each subagent holds only its own slice in a fresh context. Claude receives only the final answer.
A workflow can run dozens to hundreds of agents per run, the orchestration itself is repeatable, and runs are resumable. The script is small and readable:
const found = await agent('List every .ts file under src/routes/.')
const audits = await pipeline(found.files, file =>
agent(`Audit ${file} for missing authentication checks.`))
return audits.filter(Boolean)The proof point
Jarred Sumner, creator of Bun, used this pattern (one unit of work, an adversarial review, then apply) to port roughly 750,000 lines of Zig to Rust, with 99.8% of the existing test suite passing, 11 days from first commit to merge.
What Is a Dynamic Workflow Harness?
A harness is everything around the model that turns reasoning into reliable work. The model decides; the harness plans, binds, executes, checks and remembers. Agent = Model + Harness.
A dynamic harness adds one property: the workflow is an output of the run, not an input to it. Three properties separate it from earlier waves:
- Plans are artifacts. The workflow is a structured object that can be validated, diffed, approved and replayed.
- Freedom is bounded by the registry. The planner can only compose capabilities that exist in a governed registry, each with an owner, schema and risk tier.
- Every run leaves a decision trace. Inputs, context, policies evaluated, alternatives rejected and approvals given are recorded as data.
Reference Architecture: Seven Layers
Only one layer, the planner, changes from task to task. The other six make that flexibility safe.
| Layer | What it does |
|---|---|
| 1. Intake and intent | Turns an email, ticket or event into a task contract (objective, constraints, risk tier, SLA) |
| 2. Context assembly | Resolves entities and fetches the policies, data and precedents this task needs, just in time |
| 3. Planner | Compiles the contract and context into an explicit task graph with budgets and gates |
| 4. Capability registry | The governed catalogue of tools, skills, sub-agents and connectors |
| 5. Durable executor | Runs the graph in parallel, with checkpoints, retries and human gates |
| 6. Verifier | Checks every output against its contract and source data; a failed check replans from the last checkpoint |
| 7. Governance and decision trace | Wraps every layer, enforcing policy and recording why each decision was made |
Mapped to Claude Code: Claude is the planner, the script is the task graph, the workflow runtime is the executor, and verifier agents are the verification layer. What an enterprise must add is the context layer, the governed registry and the decision trace. That is the layer ElixirData builds with Context OS.
Six Composable Patterns
Most real tasks chain two or three of these:
| Pattern | How it works | Example |
|---|---|---|
| Classify-and-act | A classifier routes each item to a specialised subagent | Sort an inbound backlog into billing, technical and legal |
| Fan-out-and-synthesize | Split the job across clean contexts, then merge | Query ERP, CRM and the contract store at once, then reconcile |
| Adversarial verification | Every finding gets a critic whose only job is to disprove it | A skeptic tries to refute each compliance gap before it reaches the report |
| Generate-and-filter | Produce many candidates, keep only those that pass a strict rubric | Twenty remediation options, three survive policy and cost checks |
| Tournament | Pairwise comparisons advance winners through a bracket | Rank 400 resumes or vendor bids head to head |
| Loop-until-done | Keep running until a programmatic gate confirms zero new findings | Scan for policy violations until two rounds find nothing new |
Operating Dynamic Workflows: Triggers, Budgets and Limits
- Manual trigger: ask for "a workflow", include the keyword ultracode in a prompt, or run a bundled command such as
/deep-research. - Ultracode mode:
/effort ultracodemakes Claude plan a workflow for every substantive task in the session. - Budget and size: state a token budget in the prompt and set a workflow size guideline. Claude Code flags runs above 25 agents or 1.5M projected tokens.
- Reuse: save a good run as a team command or ship it in a plugin.
Three practices that keep runs disciplined
- Review the script before it runs. Narrowing scope up front removes whole categories of noise.
- Put the strongest model on orchestration, not everywhere. A cheaper worker model can burn its price advantage in extra tokens.
- Write specific prompts. Isolated agents still inherit a vague brief.
When not to use them
Workflows consume substantially more tokens than a single-agent session. Avoid them for:
- Simple or routine tasks that fit in one context window
- Deep, sequential tasks where nothing runs in parallel
- Work with no measurable correctness bar
- Tasks that need human sign-off mid-run
Use them when the task is wide, too large for one context, and expensive to get wrong.
Context, Memory and Decision Traces
Models rarely fail on enterprise tasks because they reason poorly. They fail because they reason over the wrong, stale or incomplete facts. A production harness manages three tiers:
| Tier | Lifetime | What it holds |
|---|---|---|
| Working context | One step | The exact facts the model needs now |
| Run state | One task | Plan, step outputs, checkpoints, open approvals |
| Institutional memory | Years | Entities, policies, precedents, decision traces |
The most undervalued asset is the decision trace. A log tells you what happened; a trace tells you why: inputs used, policy version evaluated, alternatives rejected, who approved. Traces compound. They make runs auditable, become precedents for the next plan, and turn into evaluation datasets.
Governance Inside the Harness, Not Around It
Governance bolted on afterwards produces reports. Governance built in prevents incidents. It acts at three moments:
- Plan time: policy-as-code validates the whole graph before anything runs.
- Action time: every tool call is checked with its live arguments.
- After the outcome: evaluators score the result and the trace is written.
Every capability carries a risk tier:
| Risk tier | Control |
|---|---|
| Read | Scoped credentials, data-residency check |
| Reversible write | Policy check, logged with trace |
| Financial or customer-facing write | Threshold-based human approval |
| Irreversible or regulated | Mandatory approval and dual control |
A regulator does not ask whether the model is accurate. They ask who decided, on what basis, under which policy, and whether you can prove it.
Worked Example: One Disputed Invoice, End to End
- Intake: a customer disputes being billed for 1,200 units when only 1,000 arrived.
- Context: the harness resolves the customer across ERP, CRM and contracts, and pulls precedent decisions.
- Plan: a precedent plan is adapted and validated against policy.
- Execute: three workers fetch invoice, delivery and contract terms in parallel.
- Verify: a verifier catches two partial shipments and replans only that step.
- Decide: the variance exceeds the auto-approval limit, so a finance approver gets a one-page summary.
- Act and record: a credit note posts through a run-scoped credential; the trace becomes the next precedent.
No one designed this workflow in advance. No one would accept it if it were improvised invisibly either. The harness made it explicit, checked it, ran it, repaired it and proved it.
Maturity: Where Are You Today?
| Level | Description |
|---|---|
| Level 0 · Scripts and bots | Static automations; exceptions go to humans |
| Level 1 · Assisted agents | Copilots suggest; humans execute |
| Level 2 · Governed single-task agents | Fixed workflows with approvals |
| Level 3 · Dynamic workflow harness | Plans compiled per task, validated, traced |
| Level 4 · Self-improving decision infrastructure | Traces feed precedents and evals; the harness improves every week |
On build versus buy: the model is a commodity you should be able to swap; your skills, policies and context are yours to build; the executor, policy engine and trace store are infrastructure. Insist on plans as inspectable artifacts, action-time policy enforcement, model portability, and decision traces you own.
What Should Leaders Do Next?
- Pick one high-volume, exception-heavy process and measure how much falls outside today's static workflows.
- Stand up a capability registry before adding more agents.
- Write your top ten policies as code and enforce them at plan time and action time.
- Make decision traces a data product with a schema and an owner.
- Measure tasks completed without escalation, cost per decision and audit findings, not prompt accuracy.
This is the layer XenonStack calls Decision Infrastructure: context, policy, orchestration and memory working together so that every task runs on a workflow built for it and accountable for its outcome.
The question for leadership teams is no longer whether agents can do the work. It is whether your organisation has the harness to let them do it safely, every time.
Scope Your First Dynamic Workflow
In a Context Workshop, XenonStack works with your process and platform owners to pick one exception-heavy process, define its task contract, context and risk tiers, and scope the harness on ElixirData with agents running on ElixirClaw. Related reading: Harness Engineering for Enterprise AI.
Book a Context Workshop | Explore ElixirClaw Agentic OS
Frequently Asked Questions
How is a dynamic workflow different from a static workflow?
A static workflow is designed once and run many times, so it only covers anticipated paths. A dynamic workflow is compiled for each task at run time from governed building blocks, then discarded.
Why not let one autonomous agent handle the whole task?
A single context carrying a long task tends to skip work, judge its own output too kindly and lose constraints over many steps. Splitting the work across fresh-context subagents with separate verifiers addresses all three.
What must an enterprise add to a dynamic workflow runtime?
A context layer, a governed capability registry and decision traces. These decide what the planner may compose, on which facts, and what evidence is kept.
When should dynamic workflows be avoided?
For simple tasks that fit in one context window, deep sequential work with no parallelism, work with no measurable correctness bar, and tasks that need human sign-off mid-run.
What is a decision trace?
A record of why a decision was made: the inputs used, the policy version evaluated, the alternatives rejected and who approved. It makes runs auditable and becomes a precedent for later plans.
Sources and further reading
- Orchestrate subagents at scale with dynamic workflows, Claude Code documentation
- A Harness for Every Task: Putting a Team of Claudes on One Job, Towards Data Science
- A harness for every task: dynamic workflows in Claude Code, Thariq Shihipar, Anthropic
This article first appeared in Navdeep Singh Gill's LinkedIn newsletter, AI + Human = Human Squared.
Explore the XenonStack Platform and Agent Network
Platforms: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AutonomousOps · CohortIQ · AI Aviator · SAIF Aviator
AI agents: AgentAnalyst · AgentEvaluation · AgentForce · AgentGRC · AgentHR · AgentInstruct · AgentLabel · AgentPixel · AgentQA · AgentRAI · AgentScrum · AgentSearch · AgentSketch · AgentSRE
XenonStack: xenonstack.com · xenonstack.ai · xenonstack.ae · xenonstack.jobs
