State Machines or Agents? Choosing Control for Clinical Workflows

I build most clinical workflows as deterministic state machines, not open-ended agents, and I want to explain why, because the industry momentum runs the other way. The pitch for autonomous agents is seductive: hand the model a goal and let it figure out the steps. In a lot of domains that is the right call. In healthcare, where a wrong step can reach a patient, I start from the opposite end. I want to know exactly what the system will do, in what order, before it ever runs.

The tradeoff, put simply, is the one the LangChain team described well: more autonomy gives an agent more potential value, at the cost of reliability, and determinism is the better call for sensitive or preset workflows. Clinical workflows are exactly that. So my default architecture is a state machine that encodes the workflow explicitly, with an agent allowed to operate only inside tightly bounded steps, and a human at the gates that matter.

Agency versus reliability

Every agent architecture sits somewhere on a spectrum from fully deterministic to fully autonomous, and where you land should be decided by the cost of being wrong. At one end is a graph or state machine, where you encode the domain knowledge into the workflow itself and the model only fills narrow gaps. Tools like LangGraph describe this as a low-level orchestration framework for long-running, stateful agents, built for controllability. At the other end is an open agent, maximum autonomy, maximum flexibility, minimum guarantees. In between, middleware lets you drop deterministic checks and approvals into an otherwise agentic loop. In healthcare I sit close to the deterministic end and move toward autonomy only where the stakes are low and the evidence is strong.

A reference architecture

My default clinical architecture is a deterministic backbone with one place the model is allowed to think, and a human at the gate before anything commits. Tap any node. The shape is deliberately boring: intake normalizes the input, a validation gate rejects anything malformed, a single bounded agent step does the one open-ended thing that actually needs a model, a human reviews before commit on anything high-stakes, the action commits, and everything is logged for audit. The agent is powerful but caged. It cannot invent new steps or skip the gate. That is the point.

The workflow as explicit states

Encoding the workflow as explicit states and transitions is what turns a vague AI feature into something you can test, certify, and trust. When the workflow is a state machine, every path is enumerable. You can list the states, the allowed transitions, and what has to be true to move between them. That is what makes it testable and auditable, and it is why regulators and safety reviewers can actually reason about it. The flow below is the backbone. The agent lives inside one state. Everything else is deterministic, and that is a feature, not a limitation.

Deterministic, agentic, or human, per step

You do not choose one control model for the whole system. You choose per step, based on stakes and how well-defined the step is. If the step is well-defined and repeatable, make it deterministic, no model needed. If it genuinely needs open-ended reasoning and the stakes are low, let an agent handle it. If it is well-defined but the stakes are high, keep it deterministic and add a human gate. And if it is both ambiguous and high-stakes, that is where a human decides and the model only assists. Most clinical workflows are mostly deterministic steps with one or two agent steps and a couple of human gates.

Who acts at each stage

Making the roles explicit, system, agent, and human, keeps the agent from quietly taking on work that should have a person on it. The system runs the deterministic states. The agent reasons inside its one bounded step. The human owns the gate before anything irreversible. Writing this down as lanes stops the slow creep where an agent, because it can, starts making calls that should have a clinician's name on them.

None of this is anti-agent. Agents are extraordinary, and I use them. But in clinical software, autonomy is a cost as much as a capability, and the right architecture spends it deliberately. Build the state machine first. Give the agent one room to think in, with the door watched. That is how I get from an impressive demo to something I would actually put in front of a patient.