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.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.
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, soplan waits for research with no wiring.
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.
The whole runtime. Events update state, state is the source of truth, and the plan is a pure function of state.
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:
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 inEffect.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.