Workflow Design Doctrine: The Iron Rules

Structural cleanliness isn't the same as robustness

An earlier set of "Iron Rules" kept an authored graph structurally clean — single-responsibility nodes, native integrations over ad-hoc HTTP calls, a real terminal output. What it didn't teach was designing for failure and control flow: a happy-path-only graph looks perfectly clean and will still fall over the first time a fetch is flaky or a candidate needs to be rejected and retried. Most real processes — qualify-then-reject loops, ordering gates, fallback on a flaky fetch, an approval gate before an irreversible action, validate-then-rollback, bounded batches over an unbounded input — are mostly exception handling, and a straight-line graph drops all of it.

Injected at both ends of authoring

The doctrine is injected into the synthesis prompt that first drafts a graph and the reviewer prompt that critiques one — the same preamble backs both, so a graph is designed for robustness and independently audited against the same standard, not just designed once and trusted. It also feeds the orchestrator's own architecture knowledge, so an operator agent reasoning about a workflow design has the same doctrine available that the synthesizer used to build it.

Continue