> ## Documentation Index
> Fetch the complete documentation index at: https://smithers.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# The Few Concepts You Need
> The minimum mental model to talk to your agent about Smithers: durability, loops, approvals, rewind, any model, isolation.
Six ideas, each one sentence, one picture, one thing you can say to your coding agent.
## 1. Durability: finished work stays finished
Every completed step is saved as a *frame*: crash mid-run and Smithers reloads the last one and continues, never re-running work that already succeeded. That's **render → execute → persist**. (Deep version: [How It Works](/how-it-works).)
```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
A[Run starts] --> B[Step done
frame saved]
B --> C[Step done
frame saved]
C --> X[crash]
X -.resume.-> D[Reload last frame]
D --> E[Continue from here]
style X fill:#fde,stroke:#c33
style D fill:#dfe,stroke:#3a3
```
> "Kick off the implement run. If my laptop sleeps, just resume it."
## 2. It loops until true, not once-and-done
Smithers runs implement → check → review until a condition is met, not one swing and done. One-shot output is where slop comes from; a real exit condition is what gets you quality.
> "Keep implementing and re-running the tests until they all pass."
## 3. Approvals: a paused run is just a row in a database
Put a human in the loop: a run waiting for approval is a paused row in SQLite, costing nothing, no process burning, no timer, no idle compute, whether it waits a day or a week. Approve, and it resumes exactly where it stopped.
> "Plan the migration, then pause for my approval before touching the database."
## 4. Time travel: rewind, fork, retry
Frames let you rewind to any earlier one, fork from there, and try a different approach without losing the original run: the first attempt becomes a branch you compare against, not a dead end. (Details: [How It Works](/how-it-works#time-travel).)
> "Rewind that run to before the refactor and try a different approach."
## 5. Any agent, any model
**Any agent, any model, any machine:** a frontier model plans while a cheaper one fans the work out, you pick the right brain for each step.
| Step | Good fit | Why |
| ----------------------- | -------------------------- | --------------------------------------------- |
| Plan / architect | A frontier model | Hard reasoning, one call, worth the cost |
| Fan-out implementation | Cheaper, faster models | Many parallel tasks, each small |
| Review / second opinion | A different model entirely | Independent eyes catch what the author missed |
> "Use a frontier model to plan, then fan the implementation out across cheaper models."
## 6. Isolation: parallel work doesn't collide
Each agent gets its own worktree or sandbox, so two editing the same repo don't trample each other and the results merge back cleanly: ten tickets, ten worktrees, ten agents, no shared mutable mess. The `kanban` workflow does exactly this.
> "Work all the open tickets at once, each in its own branch."
## The one rule above all six: you drive it through your agent
You never hand-write any of this. You describe the work in plain English, and **driving it through your agent** is what renders the loop, the gate, the fan-out, the isolation. These six are the vocabulary for asking for exactly the run you want.
## Read next
**How-to:** how the conversation works, what to say, what comes back.
**Reference:** curated authoring workflows, archived examples, the kinds of work you can hand off.
**Explanation (deeper):** the render, execute, persist loop, frames, and resume, in detail.
**Explanation (deeper):** why a JSX runtime, and why time travel comes for free.