Skip to main content
Last week Anthropic shipped Dynamic Workflows into Claude Code: you describe a task, Claude writes a JavaScript orchestration script, and a runtime fans it out across as many as a thousand subagents that attack the problem from independent angles, refute each other, and converge on an answer. It’s good work, and it validates a thesis we’ve been building on for a year: underneath every named agent topology sits a durable orchestration layer that doesn’t change. Dynamic Workflows is closed, Claude-only, cloud-gated, and ephemeral. Smithers is the same idea, open source, running on any model and any harness, on your laptop, and it survives a crash. That last property is the one nobody demos, so the article starts there.

Background agents are a different shape

Synchronous chat is forgiving: retries are free, an upstream Lambda with a five-minute timeout is fine. Background agents are a different shape: they pause for a human approval that won’t arrive until tomorrow morning, and have to wake back up at the right step when the human finally shows up. You can’t fake the right-hand column with a queue and a database. You can build it that way, but you’ll reinvent sixty percent of what an honest durable execution layer already does, more poorly: a durable step state machine, heartbeats and stale-claim recovery, retry policies with backoff, suspension on approval, resume-at-the-right-step semantics, cancellation propagation. None of that is application code you want to write; it’s the substrate.

The layer that does not change

Every six months the right way to build an AI agent changes. Chains. ReAct. Tools. Plan-and-execute. Crews. Swarms. Background agents. Dynamic subagent fan-out, as of last week. If you coupled your infrastructure to any one of these, you’ve already rebuilt at least twice, and you’ll rebuild again. There are three layers, and they move at different speeds.

The model layer churns weekly and the topology layer churns quarterly. The orchestration layer underneath does not change. That is the layer Smithers is.

  • Model layer. Volatile, changes weekly. GPT, Claude, Gemini, Kimi.
  • Topology layer. Fluid, changes quarterly. ReAct, crew, swarm, plan-execute, subagent swarm.
  • Orchestration layer. Stable. Durable steps, retries, state, events, observability.
Anthropic’s own framing of Dynamic Workflows lands on that bottom layer exactly: there’s a layer that doesn’t change, in their words. We agree so hard we wrote a runtime to be it; the disagreement is only about whether that layer should belong to one model vendor.

What Dynamic Workflows is, and the three things it is not

Dynamic Workflows is a real product and a good one, and also three things Smithers deliberately is not. It’s not open. It’s a research preview on Max, Team, and eligible Enterprise plans. You can’t read the runtime, fork it, or run it where you like. It’s not model-agnostic. It orchestrates Claude subagents. The whole point of an orchestration layer that outlives the model is swapping models and harnesses without touching the workflow, and Smithers already does: Claude Code, Codex, Pi, Antigravity, and any model the Vercel AI SDK supports, mixed in one workflow. It’s not durable. The script orchestrates subagents and returns an answer. Kill the process halfway and you start over. In Smithers, every completed step is persisted the moment it finishes, and a crash resumes from the last frame.

Durability you can watch

This three-task workflow runs research, then plan, then implement. Sequence enforces order, so plan waits for research with no wiring.
Start it. Kill the process while plan is running. Resume it:
research is skipped (already in the database). plan re-runs as attempt 2 (interrupted mid-flight). implement runs for the first time. No work is lost, and you wrote no recovery code.

Run 1 dies while plan is in flight. Run 2 skips the persisted research, retries plan as attempt 2, and runs implement for the first time.

This falls out of one design choice: state is the source of truth, and the plan a pure function of it. Render the workflow tree, extract the ready tasks, execute them, persist their outputs to SQLite, and re-render against the new state. That’s the entire model.

The whole runtime. Events update state, state is the source of truth, and the plan is a pure function of state.

It buys three things for free: resume, because re-rendering from current state needs no event log to replay; time travel, because every render frame is a row, so forking a run is throwing away rows; and SQL debugging, because state is queryable and an event chain isn’t.
Git history for agent runs, with the actual run state in every frame.

Fork a run from any frame and branch an alternate timeline. Because every frame is a row, this is just SQL.

Human approvals are just suspension

A background agent that can’t stop and ask a human is dangerous to run unattended. So suspension is a primitive.
<Approval> durably suspends the run: the process exits, costs nothing while it waits, and lives on only as a database row with nothing running. A reviewer answers tomorrow over CLI, web, or HTTP, and bunx smthrs supervise resumes any run whose heartbeat went stale after the machine died.

Patterns are compositions on the substrate

The test of whether you abstracted the primitives well enough is whether the topologies you keep rebuilding can stop being snowflakes: if the primitives are good, named patterns fall out as compositions. We surveyed every agentic orchestration framework we could find (LangGraph, Crew, Inngest, Temporal, AutoGen, Mastra, the papers, the vendor posts): anything seen more than once and worth promoting became a component. ReviewLoop. Optimizer. ScanFixVerify. Panel. Debate. Supervisor. Saga. EscalationChain. None of them are baked into the runtime; <ReviewLoop> is about twenty lines:
That’s the whole pattern: read it, fork it, write your own. When the next pattern with no name yet shows up, and it will, compose it from the same primitives, durable and observable for free. Dynamic Workflows bakes its fan-out-and-refute topology into the runtime; we ship that as a component you can open.

Why JSX, when a model could write a script

In 2026 a lot of workflow code is written and re-tuned by other agents. Wrap a workflow in a self-improving outer loop, where one agent watches another’s traces and edits the source, and by next Thursday the workflow your agent runs is one no human ever wrote. The authoring surface has to be legible both to the agents editing it and the humans auditing what they wrote. So we picked the densest domain in any model’s training corpus: TypeScript, because prompts are template strings that interpolate, refactor, and type-check with no DSL; React, because agents write it fluently and humans review a declarative tree faster than they can simulate an imperative graph in their heads. A model can write a raw orchestration script, and Dynamic Workflows proves it writes a good one, but the question is whether you can read it back, diff it, and hand it to another agent to extend six weeks later. A JSX tree, you can. A lower-level Effect-ts API sits underneath for anyone who’d rather think in Effect.gen. We took Gstack, an existing high-token agentic workflow, and cut roughly eighty percent of its lines by composing Smithers components instead of hand-writing the orchestration.

Any model, any harness

This is the claim a skeptic should test first. The same workflow runs Claude Code, Codex, Pi, and Antigravity through their own runtimes, plus any model the Vercel AI SDK supports with tools, structured output, and MCP. Point a task at whichever agent fits and switch freely. Agent fallback is an array: agent={[claude, codex]} runs Claude first and Codex on failure. The workflow doesn’t change when the model does, which is the entire reason to have an orchestration layer in the first place.

One workflow, many harnesses. Let a frontier model plan, a fast model fan out, and a specialized harness do the edits. Swap any of them without touching the workflow.

Live frames stream over the gateway as the run executes. Every state transition, every attempt, every retry is already a row you can scrub back through.

Build the future you want this week

You shouldn’t have to wait and see what one model company ships next. Dynamic Workflows is a strong product and a sign of where everything is going, but the layer it lives on is too important to belong to a single vendor, hidden behind a research-preview flag, on one model family, with no way to resume after a crash. Smithers is MIT-licensed. The slideshow we give this talk from is itself a Smithers workflow, and the crash-resume in it is real: kill it two slides in and resume, and it picks up where it left off. github.com/smithersai/smithers