To choose an AI workflow, look at which parts of the task depend on each other.
A focused question may need one model call. A task with dependent stages may benefit from prompt chaining. Separate analyses may run in parallel, followed by a step that reconciles their findings.
The useful distinction is what information each step needs before it can begin. Start there, then decide whether another call earns its cost.
One call for a focused task
Use one call when the task has a clear output and the necessary context can be supplied together.
For example, ask a model to explain a small code diff. Supply the diff, relevant surrounding code, and the intended behavior. If that produces an adequate explanation, splitting the task into multiple calls adds coordination without an established benefit.
A small diff does not always imply a self-contained task. If understanding it requires tracing behavior across the repository, gathering that context becomes part of the work. One request to a coding agent may trigger several model calls and tool interactions; it is not necessarily a single-call workflow.
Start with one call when the information and scope make that practical. Add stages when a specific limitation gives them a purpose.
Prompt chaining for dependent steps
Prompt chaining connects calls so that an earlier result becomes input to a later step.
Suppose you need migration instructions for an API update. A first call compares the old and new API contracts and identifies compatibility changes. A second call uses those findings, together with the relevant contracts, to draft migration instructions.
The sequence matters because the instructions depend on knowing what changed. Give the first step a concrete output: the affected operation, the old behavior, the new behavior, and the evidence supporting the finding.
That intermediate result also creates a place to inspect the work. If a claimed breaking change is unsupported, correct it before it becomes migration advice.
A chain does not make the findings correct by itself. If the first step misses a breaking change, the next step may produce clear instructions that still omit it. Pass the evidence needed to check the findings, rather than only a compressed conclusion.
Use a chain when the dependency is real and separating the stages makes their outputs easier to inspect or improve.
Parallel work for separate analyses
Parallel work fits when subtasks can proceed without waiting for each other's results.
For example, give the same API proposal and relevant system constraints to separate calls reviewing security, performance, and compatibility. Each review can begin from that shared input. Their findings then feed into a synthesis step.
This pattern is often called fan-out/fan-in: distribute the work, then bring the results together.
Independent execution does not imply independent concerns. A security recommendation may introduce extra checks that affect performance. A compatibility constraint may rule out another reviewer's preferred change.
Synthesis must resolve those tensions against the requirements and evidence. Collecting three reviews into one document is not enough. The output should explain which recommendations to adopt, which to reject, and which conflicts still need a decision.
Parallel analysis can reduce elapsed time compared with running the same reviews sequentially. It still uses multiple calls and adds synthesis work. Reviewers can also share the same blind spots, especially when they receive the same incomplete context.
Use parallel work when the analyses can start independently and their separate contributions justify combining them.
Combine patterns where the dependencies require it
These choices are building blocks, not mutually exclusive architectures.
An API migration workflow might start by identifying compatibility changes. Once those findings are checked, separate reviews can examine different risks in parallel. A final call can draft migration instructions from the reconciled findings.
Each stage needs a reason. A review must wait if it needs information that an earlier stage has not produced. Conversely, putting independent reviews in a sequence can create unnecessary waiting.
The same reasoning helps keep a workflow small. A narrow change may need only a focused explanation. A proposal with several distinct concerns may justify additional analysis. Do not expand every task into the largest available workflow.
Choose the next step by its input
For each proposed step, identify its required input and the output it contributes.
If the task can be completed adequately with the supplied context in one call, start there. If a later step needs an earlier result, consider a chain. If separate analyses can start from the available inputs, consider parallel work and define how their findings will be reconciled.
Then check whether the added calls improve the result enough to justify their cost, latency, and coordination. Dependencies determine what can run together; they do not guarantee that splitting the work is worthwhile.
Before adding another step, ask: What input does this step need, and is that input already available?