Before handing a workflow to an agent, first mark the steps that cannot be undone

Zach Lloyd discusses a design tradeoff in a tweet: in factory-style infrastructure, how much support to give to deterministic “if this, then that” logic and how much room to leave for free orchestration.

They ultimately chose a flexible approach. Users define the shape of the workflow with a blueprint, which looks like a DAG. What actually moves the work forward is the orchestration agent. It decides how to proceed next and when to bring a human in. There is no Zapier-style deterministic pattern matching here. The agent looks at context and the guidance provided by the code blueprint and makes judgments; the original says it uses something like a Jev classifier. If the guidance is incomplete, or a human asks for a different path, the agent can change course.

One easily overlooked point in this design: the blueprint describes the shape, while the agent owns the process. Teams need to answer which nodes must be predictable and which can be decided on the fly.

There are three perspectives in the replies. Zero Clicks says: use a graph where it matters, and leave freedom everywhere else. Asmir asks: if the agent deviates from the blueprint, does that in turn update the blueprint? Or does the agent judge from scratch every time? This question points to a learning loop. If deviations happen only once, the system does not accumulate experience; if every deviation is written back to the blueprint, the blueprint becomes organizational memory. Daniel Lenton’s distinction is more direct: look at whether a step can be undone. If it can be undone, let the agent do it first and tell the human afterward. He had previously been asked too many small questions. This criterion is actionable. Reversibility determines authority, which is clearer than saying “human-AI collaboration” in general.

My judgment: most workflow systems treat “flexibility” as a selling point, but the truly difficult part is identifying irreversible operations. Payments, deletions, external sends, and changes to production configuration require deterministic boundaries. Drafts, retrieval, classification, and internal handoffs can be handed to the agent. The blueprint should not be a flowchart decoration; it needs to express permissions and rollback conditions. Nor should the orchestration agent guess from scratch every time. Whether deviations from the blueprint update the blueprint determines whether the system is a temporary scheduler or a factory that can learn. The original gives no answer. If every deviation is judged from scratch, the blueprint is just for show. This question is worth pursuing further.