Smithers: a durable runtime for coding-agent workflows you can rewind and fork

The disposable session problem Smithers is built around

Claude Code, Codex and similar harnesses already fan out subagents, and the README concedes that for work fitting in one sitting they are the right tool. The limitation it identifies is that this fan-out is ephemeral: it lives inside one session, one vendor and one terminal. When the session ends or the process crashes, the orchestration is gone. An approval prompt blocks the terminal rather than suspending anything. A bad decision at step nine means starting the whole thing again.

Smithers targets the case where the unit of work is an agent editing a real repository over many steps and that work has to be inspectable, approvable and recoverable. The README frames the boundary explicitly: if you want one answer from one prompt, call the model directly. If you want a coding agent to change a repo across many steps, pause for a human, run several agents that review and converge, or survive crashes and replay a run, that is the intended use. The audience is therefore engineers running long agent tasks against version-controlled code, not people looking for a chat interface.

Every step is a database row, which is what makes rewind work

The mechanism the README repeats is that each completed step is persisted the moment it finishes, so live watching, rewind, fork and replay are properties of the storage model rather than separate features bolted on. A run is a sequence of frames; forking takes an earlier frame and branches an alternate timeline from it. Because persistence happens per step, a crash mid-loop resumes at the current iteration instead of iteration one.

A workflow itself is a JSX tree of tasks, authored against primitives such as Loop, which the README defines as repeating tasks until a condition is met. You are not expected to hand-write these files. The README states that you describe the outcome in plain English and your coding agent authors the workflow from the same primitives the built-in pack uses, which is why it calls prompting the authoring step.

Harnesses are swappable: Claude Code, Codex, Cursor, Pi, Antigravity, Hermes and OpenClaw are named, plus any model through the AI SDK. The claim is that the same workflow runs across them, so changing the harness does not mean rewriting the workflow. Memory is handled by wrapping tasks in a Memory element, after which agents pick up remember and recall tools mid-task and retain a digest afterward.

Installing Smithers and running a first workflow

Smithers is driven by your coding agent rather than a GUI. The README gives one command, run from inside your project, which installs the smithers skill into the coding agents on your machine and scaffolds a .smithers/ directory.

bunx smthrs init

After that command, the README says the scaffold contains the authoring workflows create-workflow, create-skill and docs-driven-development, with former recipes left in examples/init-pack/. To also wire the MCP server into every detected agent, the README gives a second command:

bunx smthrs mcp add

The first real use is a prompt rather than a file. The README's example is to ask your agent to orchestrate work and keep iterating until tests pass. The agent picks a workflow, starts the run and continues through retries and review loops. A workflow file, when you look at one, imports from the smthrs package:

import { createSmithers, Loop, CodexAgent } from "smthrs";
import { z } from "zod";

const { Workflow, Task, smithers, outputs } = createSmithers({
  input: z.object({ request: z.string() }),
  impl: z.object({ summary: z.string(), filesChanged: z.array(z.string()) }),
  review: z.object({ approved: z.boolean(), feedback: z.string() }),
});

The README shows two agents in that example, a coder and a reviewer, each a CodexAgent with its own model and reasoning effort, the reviewer running with sandbox read-only. The point of the loop is that review feedback is fed back in and the cycle repeats until approval, with every iteration persisted. The README also points to examples/parallel-tickets.jsx for the larger pattern: splitting a request into tickets, implementing them in parallel worktrees, gating on approval, and landing through a merge queue.

Where Smithers is the wrong tool

The README answers this itself, and it is worth taking at face value. If you want one answer from one prompt, the table says no. Smithers adds a runtime, a scaffolded directory and a persistence layer, and none of that pays for itself on a question a single model call can answer.

A second limitation is visible in the repository layout rather than the prose. The workflow files are JSX and TypeScript, and the package imports zod for schemas. The README's premise is that your agent writes these files, but the files are still code that lives in your repository, so a team that does not want generated JSX committed alongside application code will find the model awkward. The README does not describe a GUI editor for workflows, and it states plainly that Smithers is not a GUI you click.

A third point is that the repository is a pnpm workspace with a Rust workspace beside it: Cargo.toml defines a crates/flows-jj member and notes that a pinned jj fork is a git dependency fetched and built from its own checkout. That is a real build surface for anyone working on the project itself, even though end users installing through the skill may never touch it. The README does not document rollback of a scaffolded .smithers/ directory or of the installed skill, so plan to inspect what init writes before running it in a repository you care about.

How this differs from Temporal and LangGraph

The README links to comparisons against Temporal and against LangGraph, and the distinction it draws is about who drives the work. Temporal is a general durable-execution system: you write workflow code in a supported language and the server guarantees execution semantics, with orchestration as the thing you build. LangGraph models agent behaviour as a graph of nodes and edges, with the graph as the artifact you maintain. Smithers puts the coding agent in the driver's seat and makes the run durable underneath it, so the artifact is a JSX workflow that a coding agent authored from a prompt, and the harness executing each step can be swapped between Claude Code, Codex, Pi or an AI SDK model.

The practical difference is where the authoring effort goes. With Temporal or LangGraph you write the orchestration explicitly and the durability is a property of the platform. With Smithers the README claims you never write a workflow by hand, and the durability comes from persisting each step as a row. That trade cuts both ways: less authoring ceremony, but your orchestration is generated, and reviewing a generated JSX tree is a different skill from reviewing a graph you wrote. The README does not publish a migration path from either system.

Maintenance, release cadence and licence

The repository is not archived, and the last push was on 2026-08-17. Releases run v0.33.0 on 2026-08-02, v0.34.0 on 2026-08-13 and v0.35.0 on 2026-08-17, so the cadence over that window was roughly weekly and the version is still pre-1.0. The CHANGELOG.md at the repository root is the place to read before upgrading, since the README does not describe a deprecation policy or a compatibility guarantee across minor versions.

The licence is MIT, and the repository ships a LICENSE file plus THIRD_PARTY_NOTICES.md, which is where dependency obligations are recorded. One caveat worth stating without giving legal advice: the README points at Hindsight for semantic recall by meaning, and that is a separate component whose licence the README does not describe, so teams with licence review processes should check it independently before enabling it. Upgrade cost is shaped by the pre-1.0 version number and by the fact that workflows are generated code: a primitive change can alter what your agent writes, so diffing .smithers/ after a version bump is the concrete check.

Editorial conclusion

Adopt Smithers when the unit of work is a coding agent editing a real repository across many steps and you need approvals, crash recovery, and the ability to fork or replay a run; skip it when a single prompt to one model already answers the question, since the README's own table says so. Before committing, verify the per-agent support matrix at smithers.sh/agents/overview for the harness you actually use, check that the scaffolded .smithers/ pack contains the workflows you expect, and confirm on your own hardware that a run resumes after you kill the process. The MIT licence covers the repository, but the README points at Hindsight for semantic memory, and that component's terms are not described in the README.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes