AlphaCodium gave the pattern a memorable name
The term was popularized by the AlphaCodium work on code generation, which used a staged process rather than asking a model to solve a programming problem in one pass. The broader idea is simple: move reliability work out of a heroic prompt and into an observable sequence.
A flow can collect requirements, draft an artifact, run a deterministic check, return the failure, and ask for a bounded revision. The checker adds information only when it tests something the generation step did not assume.
Deterministic orchestration separates a flow from an agent
In a flow, application code usually determines the next stage. In an agentic loop, the model may choose the next action from the current state.
Chain-of-thought is internal reasoning, while flow engineering produces external artifacts and transitions that the host can inspect.
A schema repair flow has an honest stopping condition
For structured extraction, one stage produces JSON, a validator checks it against a schema, and a repair stage receives the actual validation errors. The workflow stops when validation passes or a retry limit is reached.
The agentic workflow playbook shows a larger delivery flow with human review. Flow engineering is unnecessary when a deterministic parser already solves the task, and the common misuse is adding model stages that merely restate the same unchecked output.
The artifact between stages is the real interface
A useful flow specifies what each stage receives, what it must return, and which failure moves the process elsewhere. Passing a free-form transcript between every stage makes the sequence difficult to test and allows an early error to spread invisibly.
Structured artifacts such as a requirements list, patch, test report, or citation map make the handoff inspectable. The flow earns its extra calls only when a later stage can reject or improve an earlier artifact using new information.
DSPy optimizes a flow only against what its metric can see
DSPy expresses LLM programs as modules and uses examples plus a metric to optimize instructions, demonstrations, or other program parameters. It can tune model calls inside a flow, but it does not choose the system's operating boundary or make the evaluation trustworthy.
Consider a support classifier that returns a category and urgency. Development examples provide the expected labels, while the metric can penalize a missed urgent ticket more heavily than a category error.
The optimizer can improve only the behavior visible in that dataset and score. A higher development result says nothing about tone, citation quality, or new ticket types unless the evaluation checks them, so the compiled program should be tested on held-out cases and versioned with its model, optimizer, examples, and metric.
Continue with these glossary entries: