You have a task where the model has to make several connected decisions — gather some facts, weigh them, act, react to the result, and continue until done. You do not want theory; you want a sequence of steps you can run right now and end up with a working chain. That is what this article is.
What follows is a concrete, ordered process. Each step tells you exactly what to do and produces something you can carry into the next step. Work through them in order on a real task of your own, and by the end you will have a sequential prompt that holds together instead of falling apart at step three. We will keep a single running example — a prompt that helps a user resolve a billing problem — so each step lands on something tangible.
The process assumes no special tooling. A text editor and access to a model are enough to follow every step.
Step 1: Write the Goal and the Stop
Before anything else, write two sentences in plain language: what the chain is trying to achieve, and how it will know it is finished.
State the Objective
For the billing example, the objective is "resolve the user's billing issue or escalate it to a human with a clear summary." A vague objective produces a wandering chain, so make it specific enough to test against.
Define the Stopping Condition
The stop is the test for done: "the issue is resolved, or enough information is gathered to escalate." Write it down explicitly. A chain without a defined stop either quits too early or loops forever.
Step 2: List the Decision Points
Now enumerate the decisions the chain will make, in rough order. You are sketching the path, not locking it.
Identify Each Junction
For billing, the junctions might be: identify the issue type, gather the relevant account facts, decide whether it is self-resolvable, attempt resolution or escalate. Listing junctions reveals how many steps you are really dealing with.
Mark What Each Junction Needs
Next to each decision, note what information it requires. This tells you what your state has to carry, which you will set up in the next step. Missing inputs are the most common cause of a stuck chain.
Step 3: Design the State Object
State is the memory your chain carries from step to step. Design it deliberately rather than letting the model improvise.
Choose a Structured Shape
Define state as a short, labeled list: issue type, account facts gathered, decisions made so far, open questions. A structured shape resists the drift that prose-style memory invites. The reasoning behind this is laid out in Mastering Multi-Step Prompts That Decide One Move at a Time.
Write the Update Rule
Decide how state changes after each step: append new facts, record the decision, remove answered questions. A clear update rule keeps the state honest. Without one, state grows stale and contradictory.
Step 4: Build the Decision Loop
This is the engine. Write a prompt that runs one pass of the loop, then repeats.
Structure One Pass
A single pass reads the current state, picks the next action against your criteria, executes it, observes the result, and updates the state. Have the model do exactly this and nothing more per pass. One decision per pass is the rule that keeps chains reliable.
Add the Stop Check
At the end of each pass, the prompt checks the stopping condition. If met, it produces the final result; if not, it loops. This check is what turns a pile of steps into a controlled process, much like the regression gates in Documenting Every Prompt Attack So Your Team Can Repeat It.
Step 5: State the Criteria at Each Junction
A decision is only as good as the criteria behind it, so make them explicit.
Name What to Optimize
For each junction, tell the model what matters: resolve fast, avoid wrong actions, escalate when uncertain. Spell out how to break ties. An unstated criterion gets guessed at, inconsistently.
Permit Information Gathering
Allow the model to say it needs more information before deciding, rather than forcing a premature commitment. The freedom to defer prevents a whole class of bad decisions.
Step 6: Test the Chain Against Trouble
A chain that works on the happy path is not done. Push it.
Run Awkward Inputs
Feed the chain ambiguous, incomplete, and contradictory inputs and watch where it stumbles. The weak points you find here are exactly what to harden, an approach drawn from Break Your Prompts Before Users Break Them in Production.
Check for State Drift
After a long run, inspect the state object. If it has accumulated stale or contradictory entries, tighten your update rule. State drift is the silent killer of long chains.
Step 7: Add Recovery, Then Ship
Once the basic loop is solid, add the safeguards that fit your stakes.
Insert a Checkpoint
Add a point where the chain asks whether it is still on track toward the goal. A checkpoint catches a wrong turn before it cascades. For low-stakes chains, one checkpoint may be enough; raise the count with the cost of error.
Enable Revision
Let the chain revise an earlier decision when a later step exposes it as wrong, rather than treating every decision as final. Worked examples of this recovery appear in When a Prompt Has to Choose, Then Choose Again.
Step 8: Document and Hand It Off
A working chain that only you understand is a liability. Spend a little effort making it transferable before you call it done.
Write Down the Contract
Capture in plain language what the chain does, what its state carries, and what its stopping condition is. This short document lets a teammate maintain the chain without reverse-engineering your prompt. It is the same artifact discipline that powers Documenting Every Prompt Attack So Your Team Can Repeat It.
Keep the Test Inputs With the Prompt
Store the awkward inputs you used in Step 6 alongside the prompt itself, so the next person can re-run them after any change. A chain with its tests attached is far safer to modify than one without.
Note the Known Limits
Write down where the chain is known to struggle — input types it handles poorly, stakes it was not built for. Honest limits prevent a colleague from trusting the chain in a situation it was never designed for.
A Quick Worked Pass
To make the loop concrete, here is one full pass of the billing chain in motion.
One Cycle End to End
The chain reads its state (issue type unknown, no facts gathered), chooses the next action (ask the user to describe the problem), executes it, observes the answer ("I was double-charged"), and updates state (issue type: duplicate charge). It then checks the stop — not met, since no account facts are gathered yet — and loops to choose the next action.
Why This Pass Is Reliable
Notice that the pass committed to exactly one decision, updated state explicitly, and checked the stop before continuing. Every reliable cycle looks like this. When you watch your own chain run, you should be able to point at each of those moments; if you cannot, a step is missing.
Frequently Asked Questions
Can I really do this without writing code?
Yes. The entire process is structuring instructions and state in plain language. Code only enters if you decide to automate the loop, and even then the design work you did here carries over directly.
How many decision points is too many for one chain?
There is no hard limit, but past roughly seven or eight junctions, long chains get fragile. If your task is larger, break it into sub-chains, each with its own goal and stop.
What if the model ignores my state object?
It usually means the state is buried or unstructured. Keep it short, clearly labeled, and present in every pass. A compact, visible state is far harder for the model to ignore than a long prose summary.
Do I need criteria for every single junction?
For any junction with a real choice, yes. Junctions that are purely mechanical — gather this fact, record it — need less. The decisions where the model could plausibly go two ways are where stated criteria earn their keep.
How do I know my stopping condition is good?
Test whether the chain reliably halts at the right moment across varied inputs. If it stops too early, the condition is too loose; if it loops, the condition is unreachable or unchecked. Adjust until it halts cleanly.
Should I build recovery into every chain?
No. Match recovery to stakes. A short, low-cost chain can run forward-only. A chain where a wrong step is expensive or where later steps reveal earlier errors deserves checkpoints and revision.
Key Takeaways
- Start by writing the goal and an explicit stopping condition in plain language.
- List the decision points and note what information each one needs.
- Design state as a short, structured object with a clear update rule.
- Build a loop that makes one decision per pass and checks the stop at the end.
- State optimization criteria at each real junction and allow the model to defer when uncertain.
- Test against awkward inputs, watch for state drift, then add checkpoints and revision sized to your stakes.