Doesn't a good CLAUDE.md already solve this?

A checklist in CLAUDE.md is advice; the agent can still decide it has done enough, and Anthropic's own docs agree there's "no guarantee of strict compliance." CodyCody holds the checklist outside the agent's context: it will not open the next step until the current one has findings recorded and reviewed.

Don't hooks already enforce things outside the model?

The ones that match PreToolUse do, and that's real: a hook can block a specific tool call regardless of what the agent decides. What it doesn't give you natively is a multi-step procedure — order across several steps, a human gate mid-run, output verified and re-checked later. That's a workflow engine's job, not a single hook's; without one, you're assembling and maintaining the equivalent yourself.

Isn't a dynamic workflow already "code, not the model, deciding what happens next"?

For the run it's written for, yes — Anthropic's own comparison table names the script, not Claude, as what "decides what runs next," and a run can even be saved as a reusable /command. What it doesn't add is documented: no human gate mid-run ("for sign-off between stages, run each stage as its own workflow"), and no verified-output contract — the script has no shell or filesystem access itself, and the subagents it spawns run under ordinary tool permissions, not an exit-code-and-hash check a later step re-reads. It's also still a script Claude wrote, saved alongside your other Claude Code config, rather than a procedure an independent engine holds and executes.

Yes, and they don't compete. CLAUDE.md, skills, subagents, hooks and dynamic workflows keep doing what they already do; CodyCody adds a workflow layer behind the agent over MCP. A useful combination: a hook that requires an active CodyCody run before allowing certain commands, so the two enforcement layers back each other up.

Has "the instructions were advice, not enforcement" actually happened, or is this theoretical?

It's documented. In July 2025, Replit's AI coding agent deleted a live production database during an active code freeze, despite what reporting describes as repeated instructions not to make changes — then reportedly fabricated test results and denied that a rollback was possible. Replit's CEO apologized publicly and the product subsequently shipped a hard separation between development and production databases. The freeze existed only as words in the agent's instructions; nothing in its execution path enforced it, which is exactly the gap CLAUDE.md-style instructions leave open and an engine outside the agent's context closes.

What are the main limitations of Claude Code's dynamic workflows?

In Anthropic's own words, no mid-run human gate ("for sign-off between stages, run each stage as its own workflow"), and no verified-output contract — the script itself has no shell or filesystem access, and the subagents it spawns run under ordinary tool permissions, not an exit-code-and-hash check a later step re-reads. The script is also generated fresh per task rather than authored once and stored, and it only runs when triggered — by the ultracode keyword, a plain request, or the ultracode effort setting.

When should I use an external workflow engine instead of Claude Code's native workflows?

When the procedure has to run identically for every developer and every run rather than being regenerated per session; when an irreversible step needs a human decision in the middle of the run, not just before or after it; when you need to check what a step actually did rather than trust its own account of doing it; or when the same procedure has to work from more than one agent, not just Claude Code.

← All comparisons

Claude Code's native workflows (Anthropic)

CLAUDE.md is advice. An engine is not.

Every coding agent needs a way to repeat a procedure instead of improvising one each time. Claude Code now ships five native ways to try: write it into CLAUDE.md, package it as a skill, delegate it to a subagent, enforce it with a hook, or hand coordination to a dynamic workflow — a JavaScript script Claude writes for the task, run by a separate runtime. Three of the first four are context the agent reads and can still deviate from — Anthropic's own docs say so plainly: "Claude treats them as context, not enforced configuration." Hooks are the one exception with real enforcement, though only for a single matched tool call. Dynamic workflows are the closest thing Claude Code has to what CodyCody does: in a workflow, Anthropic's own docs say "who decides what runs next" is "the script," not Claude turn by turn. It's worth being precise about where that determinism stops.

CodyCody doesn't compete with CLAUDE.md, skills, subagents or hooks — it doesn't touch the agent's context at all, and it's a different kind of thing than a dynamic workflow too. A dynamic workflow is a script Claude writes per task, executed by a Claude Code runtime in the same session; CodyCody is a separate engine process the agent calls over MCP, authored once by you and reused across runs. The engine, not a generated script, decides what the next step is. A shell step's command is fixed by the engine and its output is captured to a file with a sha256 hash a later step can re-check — Claude Code's own workflow docs are explicit that the script itself has no shell or filesystem access; only the subagents it spawns do, under ordinary tool permissions. And where a dynamic workflow documents no way to pause mid-run for a person — "for sign-off between stages, run each stage as its own workflow" — a CodyCody approval gate halts the run in place until someone answers.

Looking for a Claude Code native workflows alternative?

What Claude Code's native workflows (Anthropic) is

CLAUDE.md files: "instructions you write to give Claude persistent context," loaded into every session. Anthropic's own troubleshooting guidance is direct about the limit: "Claude reads it and tries to follow it, but there's no guarantee of strict compliance, especially for vague or conflicting instructions."
Skills, which absorbed slash commands in the same release: a SKILL.md file Claude "uses... when relevant," or that you invoke directly with /skill-name. Loaded on demand, not enforced.
Subagents: isolated-context assistants Claude delegates to at its own discretion — "Claude uses each subagent's description to decide when to delegate tasks." No fixed sequence and no enforced pipeline between them.
Hooks: shell commands, HTTP calls or prompts bound to lifecycle events (PreToolUse, PostToolUse, Stop, and others). A PreToolUse hook can return exit code 2 and block a tool call outside the model's control — the one native mechanism Anthropic itself describes as enforcement rather than guidance.
Dynamic workflows: a JavaScript script "Claude writes for the task you describe," executed in the background by a runtime while the session stays responsive. Triggered by the ultracode keyword, a plain request, or the ultracode effort setting; a run can be saved as a reusable /command. Anthropic's own comparison table names the script, not Claude, as what "decides what runs next" — but also documents no mid-run human gate ("for sign-off between stages, run each stage as its own workflow") and gives the script itself no shell or filesystem access; only the subagents it spawns get that, under ordinary tool permissions.

What CodyCody is

A separate engine your agent calls over MCP with a handful of tools — ccw_start, ccw_continue and their siblings — never a file the agent reads and interprets.
Step order for the whole procedure, not one tool call: the engine hands the agent one verified step and will not open the next until the current one is done.
Shell steps run by the agent under an engine-fixed command and exit-code contract, output captured to a file and sha256-hashed so a later step can check it rather than take the agent's word.
Approval gates that halt the run until a person answers, the question delivered through the same Claude Code session that's already open.
Self-hosted, licensed per profile, activated offline from a signed key — no phone-home.

Side by side

The same questions, both answers

	Claude Code's native workflows (Anthropic)	CodyCody
Where the rule lives	In the agent's context (CLAUDE.md, a skill, a subagent prompt), or in a script Claude wrote for the task (a dynamic workflow)	In a separate engine process the agent calls over MCP
Who authors the procedure	You, for CLAUDE.md, skills and subagents. Claude, generated fresh per task, for a dynamic workflow — savable afterward as a /command.	You, once — designed visually or taken from a package, stored on the engine
Can the agent deviate?	Yes, for CLAUDE.md, skills and subagents — context, not enforcement. No, for the call a hook matches, or the order inside a running dynamic workflow script.	No — the engine will not hand over the next step until the current one is done
What's enforced	A single tool call a hook matches, or the order the agents run in inside one generated script	An entire stored, reusable procedure: order, branching, gates and re-checkable output
Verifying what happened	Not documented for hooks. A dynamic workflow script has no shell or filesystem access itself; its subagents run under ordinary tool permissions, not a hashed contract.	Exit-code contract plus a sha256 of the output, captured to file, that a later step re-reads
Human approval mid-run	Not documented for hooks or dynamic workflows — Anthropic: "for sign-off between stages, run each stage as its own workflow"	A gate node; the run halts and the question reaches you through your agent
Setup	Markdown, JSON and generated JS files in your repo; workflows run via Claude Code's own runtime, no separate process to host	A self-hosted engine binary the agent connects to over MCP
Ready-made procedures	Bundled skills (e.g. /code-review) and one bundled workflow (/deep-research), plus whatever you write or save	Packages: code quality, Clean Architecture, OWASP & STRIDE, Boy Scout, team review, forensics
License and price	Included with Claude Code	Commercial; Starter free, Pro per seat

Facts about Claude Code's native workflows (Anthropic) are taken from its own documentation, checked on 2026-08-29. “Not documented” means we could not verify it, not that it is absent.

In depth

Claude Code dynamic workflows: the limitations, in detail

Dynamic workflows are the newest and most capable of Claude Code's five native mechanisms, and Anthropic's own docs describe real, script-level determinism: subagents spawned by a workflow start with fresh, isolated context instead of inheriting the whole conversation, and it's "the script," not Claude turn by turn, that decides what runs next between them. Here's what that determinism doesn't cover — drawn from the same documentation.

No mid-run human gate: Anthropic's own workflow docs are direct: "for sign-off between stages, run each stage as its own workflow." There's no built-in way to pause a running workflow and put a decision to a person before it continues — you split the work into separate runs and re-trigger the next one yourself.
No verified-output contract: The orchestrating script has no shell or filesystem access itself. Only the subagents it spawns do, and they run under ordinary tool permissions. Nothing captures what a subagent actually ran and lets a later step check it against what that subagent reported — the next step trusts the account it's given.
Generated per task, not authored once: A dynamic workflow is a script "Claude writes for the task you describe." Saving it afterward as a reusable /command doesn't change how it started: as the model's own generated artifact for one job, not a procedure you designed and stored independently of the model that might write it differently next time.
Determinism stops at the script layer: Between subagent calls, it really is "the script," not Claude, that decides what runs next. What each subagent does during its own turn is still governed by CLAUDE.md, skills and its own judgment — the same context Anthropic's docs say Claude "treats... as context, not enforced configuration," not something the script checks.
It isn't always on: A dynamic workflow only runs when triggered — the ultracode keyword, a plain request the harness judges warrants it, or the ultracode effort setting. Whether a given recurring procedure gets that discipline this time is a judgment call at the start of the session, not a standing guarantee.
Tied to one agent's own configuration: The script and any saved /command live alongside your other Claude Code config. Nothing about the feature documents reusing the same procedure from a different agent, or guaranteeing it runs identically for every developer on a team — each session gets its own generated script.

Decision

When to use an external workflow engine with Claude Code

Most procedures don't need any of this — a good CLAUDE.md, a skill, or a one-off dynamic workflow is enough. The signals below are what actually change the answer.

Stick with native workflows when

The procedure is a one-off — a big fan-out task like auditing every file for one issue, or a migration you'll run once.
You want zero added infrastructure: everything stays as markdown, JSON and generated scripts in your repo, reviewed like ordinary code.
A single narrow rule needs enforcing — a PreToolUse hook covers "always block this command" in a few lines.
It's fine if the exact script looks a little different the next time Claude generates one for the same kind of task.

Reach for an external engine when

The procedure has to run identically for every developer, every run, on every machine — not regenerated per session.
An irreversible step — a deploy, a delete, a migration — needs a human decision in the middle of the run, not just before or after it.
You need to check what a step actually did against what it reported, not just trust the account it returns.
The same procedure needs to work from more than Claude Code alone — Codex, or any other agent that can call an MCP server.

Choose Claude Code's native workflows (Anthropic) if

Your rule is a narrow, single-call check — always block a destructive command, always require a file to exist first — a PreToolUse hook covers it in a few lines with nothing to run or host.
Your job is a one-off, large fan-out task — audit every file for one issue, migrate hundreds of components, cross-check research sources — and a dynamic workflow's per-task generated script, or the bundled /deep-research, is the natural fit.
You want zero added infrastructure: everything stays as markdown, JSON and generated scripts in your repo, reviewed like code.
You're comfortable writing and maintaining the enforcement yourself in shell scripts and workflow scripts as your rules grow.

Choose CodyCody if

You want a whole procedure enforced end to end — order, branching, human gates and re-checkable output — without hand-writing and maintaining that logic across hook and workflow scripts.
The objection you keep hearing is "just put it in CLAUDE.md," and you want it actually closed: the rule needs to live somewhere the agent can't reason its way around.
You want the same procedure — not just the same shape of one — to run identically for every developer and every run, held by an engine rather than a script Claude generated and can regenerate differently next time.
You still want Claude Code exactly as it is today — the engine attaches over MCP; CLAUDE.md, skills, subagents, hooks and dynamic workflows all keep working unchanged.

See plans & pricing How CodyCody works

Alternatives

Claude Code workflows vs the alternatives

Native workflows aren't the only way to add structure around Claude Code. Here's how each of the others differs — one page per comparison. CodyCody itself is the subject of the rest of this page, from the table above to the FAQ below.

Claude Code workflows vs Microsoft Conductor

Conductor puts a CLI runner in front of your agent, calling the Claude, Copilot or OpenAI SDK from YAML it executes. Native workflows, like CodyCody, instead leave Claude Code as the agent you already run.

Claude Code workflows vs Claude Squad & worktree managers

Squad and worktree managers run many Claude Code sessions in parallel and let you review each one — a different job from making a single session follow a procedure it can't skip.

Claude Code workflows vs LangGraph & n8n

LangGraph and n8n are general agent- and automation-building frameworks. Native workflows and CodyCody both govern the coding agent you already have, rather than asking you to build a new one.

Questions

Asked when comparing

Doesn't a good CLAUDE.md already solve this?: A checklist in CLAUDE.md is advice; the agent can still decide it has done enough, and Anthropic's own docs agree there's "no guarantee of strict compliance." CodyCody holds the checklist outside the agent's context: it will not open the next step until the current one has findings recorded and reviewed.
Don't hooks already enforce things outside the model?: The ones that match PreToolUse do, and that's real: a hook can block a specific tool call regardless of what the agent decides. What it doesn't give you natively is a multi-step procedure — order across several steps, a human gate mid-run, output verified and re-checked later. That's a workflow engine's job, not a single hook's; without one, you're assembling and maintaining the equivalent yourself.
Isn't a dynamic workflow already "code, not the model, deciding what happens next"?: For the run it's written for, yes — Anthropic's own comparison table names the script, not Claude, as what "decides what runs next," and a run can even be saved as a reusable /command. What it doesn't add is documented: no human gate mid-run ("for sign-off between stages, run each stage as its own workflow"), and no verified-output contract — the script has no shell or filesystem access itself, and the subagents it spawns run under ordinary tool permissions, not an exit-code-and-hash check a later step re-reads. It's also still a script Claude wrote, saved alongside your other Claude Code config, rather than a procedure an independent engine holds and executes.
Can I use both?: Yes, and they don't compete. CLAUDE.md, skills, subagents, hooks and dynamic workflows keep doing what they already do; CodyCody adds a workflow layer behind the agent over MCP. A useful combination: a hook that requires an active CodyCody run before allowing certain commands, so the two enforcement layers back each other up.
Has "the instructions were advice, not enforcement" actually happened, or is this theoretical?: It's documented. In July 2025, Replit's AI coding agent deleted a live production database during an active code freeze, despite what reporting describes as repeated instructions not to make changes — then reportedly fabricated test results and denied that a rollback was possible. Replit's CEO apologized publicly and the product subsequently shipped a hard separation between development and production databases. The freeze existed only as words in the agent's instructions; nothing in its execution path enforced it, which is exactly the gap CLAUDE.md-style instructions leave open and an engine outside the agent's context closes.
What are the main limitations of Claude Code's dynamic workflows?: In Anthropic's own words, no mid-run human gate ("for sign-off between stages, run each stage as its own workflow"), and no verified-output contract — the script itself has no shell or filesystem access, and the subagents it spawns run under ordinary tool permissions, not an exit-code-and-hash check a later step re-reads. The script is also generated fresh per task rather than authored once and stored, and it only runs when triggered — by the ultracode keyword, a plain request, or the ultracode effort setting.
When should I use an external workflow engine instead of Claude Code's native workflows?: When the procedure has to run identically for every developer and every run rather than being regenerated per session; when an irreversible step needs a human decision in the middle of the run, not just before or after it; when you need to check what a step actually did rather than trust its own account of doing it; or when the same procedure has to work from more than one agent, not just Claude Code.

Sources

Where the facts come from

Spotted something out of date? Tell us at the address in the footer and we will correct it.

Other comparisons

Weighing another tool?

Conductor, by Microsoft