Application patterns
Workflows
A workflow is a fixed sequence of steps. You decide the order. The model does a small job at each step.
Mental model
An assembly line, not a colleague wandering the building. Each station has one job and a handoff.
A single prompt that classifies, extracts, retrieves, and drafts will fail in ways you cannot attribute. Separate calls make the failure obvious.
When to use
- The steps are known in advance, even if one step's output chooses a branch.
- You want to test or replace one step without touching the others.
When not to use
- The task really is one step. A workflow would only add latency.
- You cannot name the next step until the model has explored. That is a loop, and it costs more.
- Input
- Step one
- Step two
- Checked result
Example
Support reply, as a workflow:
- Classify the ticket.
- Extract the order id and product.
- If the label is
billing, retrieve the billing policy. Otherwise retrieve the product guide. - Draft the reply from that policy and the extracted fields.
- A grader checks that the draft does not promise a refund the policy forbids.
You can unit-test step 1 without running step 4. When drafts go wrong, you can see whether the label was already wrong.
Implementation notes
Pass structured output from one step into the next. Do not ask step 4 to re-read the whole ticket and redo classification "just in case."
Branches should be code. if label === "billing" is clearer than asking the model to "decide the whole process."
Record the intermediate objects. They are what you put in an eval when production misbehaves.
Common mistakes
- Calling five steps a workflow when they are the same prompt repeated.
- Hiding a branch inside a paragraph instead of returning a label your code can route on.
- Adding a step you cannot score.