`. **Complex workflows are easier for humans to read.** React's functional composability means a 30-task pipeline reads like a component tree, not a YAML graph. A reviewer can `cmd+click` a `` to see what it expands to. Reuse is just import-and-render. **LLM prompts can be MDX files that take props.** A prompt is a component. It accepts inputs, embeds expressions, and renders to a string the agent sees. Versioning prompts means versioning files. Testing prompts means rendering them. These are real benefits. But they're all *secondary*. ## The actual reason: agent experience Every workflow engine asks the agent to learn a new DSL: a custom YAML schema, a node-and-edges graph format, a state-machine transition table, each a domain the agent has seen little training data for. React, by contrast, is one of the most heavily represented domains in the training corpus of every modern model: JSX, hooks, conditional rendering, composition patterns, prop drilling, state colocation. Agents have seen millions of examples of each and write it fluently, idiomatically, without coaching. So Smithers does the obvious thing: **map orchestration onto a domain agents are already optimized for.** A workflow becomes a component tree, a dependency a conditional render, a loop `` with the same `key` semantics agents already know, and an iteration's previous output reads with the same mental model as state in a parent component. This is agent experience: just as DX (developer experience) is the discipline of designing tools humans love, agent experience designs tools agents are good at. Setting an agent up to perform well on a hard problem often just means expressing the problem in a domain it has already mastered. That is why, as Smithers has stabilized, it has become the orchestration tool agents reach for. Other engines are more featureful and the API isn't small, but **agents write workflows that run correctly more often, with less back-and-forth coaching, than they do with bespoke DSLs.** They write a workflow, it runs. They debug a failed task, they fix it. They refactor a 200-task pipeline, they don't break it. ## The objection, answered The skeptical objection persists: React is for views, and we've forced it to do another job. This gets the history backwards: React is fundamentally a reconciler, a general-purpose engine that diffs a declarative tree against its prior version into a minimal set of imperative operations. React Native drives native views, Ink drives terminal UIs, React Three Fiber drives a 3D scene graph, and Smithers drives a task graph. The reconciler is the abstraction. The DOM was just the first host. We're a different host. ## Read next * [How It Works](/how-it-works): the render → execute → persist loop. * [JSX API](/jsx/overview): setup, tsconfig, and the minimal workflow. * [Tour](/tour): six-step worked example.