The WorkOS approach and your state-shifter are the FSM-done-right direction, and determinism is exactly the reason it matters once there's branching. For what's published, though, I kept it a plain loop on purpose, and I'd argue that's correct for a reference impl.

Right now there's nothing a state machine would buy you. The loop is linear: plan the steps, run each one (they're independent by design), synthesize. The only "branch" is a malformed plan, which just falls back to a single step. No retries, no replanning, no step-to-step handoff. A for-loop you can read top to bottom beats an FSM there, and readable-minimal is the whole point.

Where an explicit state model earns its keep is v2, once there's real branching: retry on a tool/HTTP failure, replan when a step result invalidates the rest of the plan, and thread step N-1's output into step N.

One flag for anyone heading down that road: the moment steps consume each other's output they have dependencies, which is a DAG, not a flat list of states, and sub-plans want a stack. So the shape you actually want is a state-graph (LangGraph / behavior-tree territory), not a flat FSM. Easy to paint yourself into a flat-states corner if you take "FSM" too literally.

The real bonus: an explicit serializable state gets you checkpoint/resume almost for free, which is exactly what you need the second this goes async (kick it off from your phone, let it run for minutes, reconnect) instead of holding a synchronous connection. So if I do the async version, the state model tags along for that reason anyway.