Principles only become useful when you can see them operating on a real task. Sequential decision making is especially abstract until you watch a chain make its first choice, react to the result, and make the next one — sometimes well, sometimes badly. This article walks through specific scenarios, shows the decisions at each junction, and points out exactly what made the chain hold together or fall apart.
The examples span different shapes of work: a support triage flow, a research planning loop, a data-cleaning sequence, and a guided onboarding chain. They are illustrative, not literal transcripts, but each is built to surface a particular lesson about how sequential prompts succeed or fail. Watch what the state carries, how each decision uses it, and where recovery does or does not happen.
Read these less as templates to copy and more as cases to learn the pattern from. The same loop appears in all of them, just dressed in different tasks.
Example 1: Support Ticket Triage
A chain receives a customer message and has to route it correctly through a series of decisions.
How the Chain Works
It first classifies the issue type, then gathers the account facts that type requires, then decides whether the issue is self-resolvable or needs a human. State carries the issue type, the facts gathered, and the decision so far. Each junction reads that state to choose its next move.
What Made It Succeed
The chain worked because the issue type was decided first and carried in state, so every later step knew what facts to gather. The stopping condition — resolved or ready to escalate — kept it from looping. This is the explicit-state discipline from Mastering Multi-Step Prompts That Decide One Move at a Time in action.
Example 2: Research Planning Loop
A chain breaks a research question into sub-questions, investigates each, and decides what to ask next.
How the Chain Works
Rather than planning all sub-questions up front, it picks the single most informative next question, gathers an answer, updates its running understanding, and re-decides. State holds what is known and what remains open.
What Made It Fail at First
An early version planned every sub-question in advance. The first answer made half the plan irrelevant, but the chain kept following it and wasted steps on dead questions. Switching to one-question-at-a-time fixed it — the exact mistake catalogued in Seven Ways Sequential Decision Prompts Quietly Go Sideways.
Example 3: Data-Cleaning Sequence
A chain processes a messy dataset through ordered transformation decisions.
How the Chain Works
It inspects the data, decides the next cleaning operation, applies it, observes the result, and decides again — deduplicate, normalize formats, fill or flag gaps — until the data meets a defined quality bar that serves as the stop.
What Made It Succeed
It re-checked the data state against reality after each operation instead of trusting that the last step did what it intended. That validation caught a normalization step that silently corrupted dates, before later steps built on the bad data. The instinct comes straight from What Reliable Multi-Decision Prompting Demands From You.
Example 4: Guided Onboarding Chain
A chain walks a new user through setup, adapting each question to prior answers.
How the Chain Works
It asks the most useful next setup question, records the answer in state, and chooses the following question based on what is still unknown. When all required setup facts are gathered, the stop triggers and it finalizes the configuration.
What Made It Fail at First
An early version did not carry state explicitly and re-asked questions the user had already answered, which felt broken to users. Adding a structured state object that recorded each answer eliminated the repetition. This is the implicit-state trap in plain view.
Example 5: Multi-Step Approval Flow
A chain routes a request through conditional approval steps where each gate depends on the last.
How the Chain Works
It evaluates the request against the first gate's criteria, and depending on the result either advances, requests more information, or rejects. State carries which gates have been cleared and what each decided.
What Made It Succeed
Explicit, stated criteria at each gate made the decisions consistent and auditable — anyone could trace why a request advanced or stopped. The chain also allowed a gate to request information rather than forcing a premature decision, avoiding wrong rejections.
What the Examples Share
Across all five, the same structure produced reliability, and the same omissions produced failure.
The Common Pattern
Every successful chain made state explicit, decided one step at a time, defined a clear stop, and reacted to observed results. Every failure traced back to skipping one of those.
The Common Failures
Failures clustered around implicit state, up-front over-planning, and trusting summaries without validation. Pressure-testing the chains against messy inputs — the approach in Break Your Prompts Before Users Break Them in Production — surfaced these before they reached users.
Reading the Examples Side by Side
Lined up next to each other, the five scenarios reveal that the differences between them are surface details and the similarities are the substance.
What the State Carried
In every example, the state object held the same three kinds of thing: facts gathered, decisions or conclusions reached, and open questions still to resolve. The support chain carried issue type and account facts; the research loop carried known answers and remaining questions; the approval flow carried cleared gates. Different labels, identical roles.
Where the Decisions Diverged
The junctions differed in what they optimized for. Triage optimized for correct routing, research for information gain, data cleaning for quality, onboarding for completeness, and approval for policy compliance. Each chain stated those criteria explicitly, and that statement is what kept the decisions consistent across runs.
The Tell-Tale Signs of a Healthy Chain
A few signs separated the healthy chains from the fragile ones:
- The state object was short and structured, never a sprawling transcript.
- Each pass committed to exactly one decision and then observed its result.
- A stopping condition was checked, so the chain always knew whether it was done.
- On a wrong turn, the chain could re-check or revise rather than barrel ahead.
Whenever one of those was missing, a failure showed up somewhere in the run.
Frequently Asked Questions
Can I use these examples as templates directly?
Better to use them as patterns than templates. The tasks differ, but the underlying loop — explicit state, one decision per step, a clear stop, reaction to results — transfers. Copy the structure, not the specifics.
Why did the research example fail with an up-front plan?
Because the first answer changed what questions were worth asking, but the fixed plan could not adapt. Deciding the next question one at a time let each choice react to what the previous answer revealed.
What is the role of validation in the data-cleaning example?
It caught a step that silently corrupted data before later steps depended on it. Re-checking the actual state against reality, rather than trusting that each operation worked, is what prevented the corruption from cascading.
How did the onboarding chain avoid repeating questions?
By carrying every answer in an explicit, structured state object and choosing the next question from what was still unknown. Without that state, the chain re-asked answered questions because it had no memory of them.
Do all these examples need recovery logic?
Not equally. The data-cleaning and approval flows benefit most from validation and the ability to revise, because wrong steps are costly there. Lighter chains like onboarding rely more on clean state than on heavy recovery.
What is the single biggest lesson across the examples?
That explicit state plus one-decision-at-a-time is what separates chains that hold together from chains that drift. Nearly every success and failure traced back to whether those two were in place.
Key Takeaways
- Sequential decision making becomes concrete when you watch a chain choose, observe, and choose again on a real task.
- Support triage, research planning, data cleaning, onboarding, and approval flows all run the same underlying loop.
- Successes shared explicit state, one decision per step, a clear stop, and reaction to observed results.
- Failures clustered around implicit state, up-front over-planning, and trusting summaries without validation.
- Validation against ground truth caught silent corruption before it cascaded in the data-cleaning case.
- Treat the examples as patterns to learn the loop from, not templates to copy verbatim.