A composite agency team had shipped a prompt that was supposed to guide users through resolving an account problem in a handful of steps. It demoed beautifully. In production it unraveled: the chain re-asked questions users had already answered, occasionally recommended a fix that contradicted an earlier conclusion, and now and then never reached an answer at all. Support tickets piled up, and the team could not reliably reproduce the failures.
This case study follows that team through the full arc — the situation they were in, how they diagnosed the problem, the decisions they made to redesign the chain, how they executed the rebuild, and what changed afterward. The scenario is illustrative rather than a literal account, but every step maps to a real, common pattern in prompting for sequential decision making. The point is to show how the principles play out under pressure, not in a tutorial.
What makes the story useful is that the team's first instinct — rewrite the wording — was wrong, and the fix that worked was structural. That gap is the heart of the lesson.
The Situation
The team owned a guided resolution flow: a user describes a problem, the chain asks clarifying questions, gathers facts, and proposes a resolution or escalates.
What Was Breaking
Three symptoms recurred. The chain repeated questions, suggesting it had no memory of prior answers. It sometimes contradicted itself, recommending something that conflicted with a conclusion two steps earlier. And on messy inputs it occasionally looped without resolving.
The First, Wrong Instinct
The team's first move was to rewrite the instructions more clearly and add more examples. It helped at the margins and fixed nothing fundamental, because the problem was not clarity. This is the trap generic advice leads to, and it is why What Reliable Multi-Decision Prompting Demands From You argues structure over wording.
The Diagnosis
Rather than tweak wording again, the team traced specific failures backward from the bad output to find the cause.
Following the Failures
Tracing the repeated-question failures revealed there was no explicit state — the chain relied on the model to remember answers, and over longer conversations it did not. The contradictions traced to the same root: with no recorded conclusions, later steps had nothing to stay consistent with.
Naming the Root Causes
They landed on three root causes: implicit state, no stopping condition, and no recovery when a step went wrong. Every symptom mapped to one of these — the exact failure modes catalogued in Seven Ways Sequential Decision Prompts Quietly Go Sideways.
The Redesign Decisions
With the causes named, the redesign was straightforward in principle, if careful in execution.
Introduce Explicit State
They added a structured state object carried through every step: the problem type, facts gathered, conclusions reached, and open questions. Each decision now read from and wrote to this object instead of relying on the model's memory.
Add a Stopping Condition and Criteria
They defined an explicit stop — resolved or ready to escalate with a summary — and stated the criteria at each junction, including a rule to escalate rather than guess when uncertain. This made decisions consistent and gave the chain a finish line.
The Execution
Rebuilding the chain was incremental, and the team validated each change before moving on.
Building the Loop
They restructured the prompt around a single-decision-per-pass loop: read state, choose the next action against the criteria, act, observe, update state, check the stop. One decision per pass replaced the previous tangle that tried to do too much at once. This is the loop laid out in Build a Step Ladder of Prompts for Decisions That Chain.
Stress Testing Before Shipping
Before release, they ran the chain against deliberately awkward and contradictory inputs to find where it still broke, using the mindset in Break Your Prompts Before Users Break Them in Production. Two state-update bugs surfaced and were fixed before any user saw them.
The Outcome
The rebuild changed the chain's behavior in ways the team could observe, not just feel.
What Improved
The repeated-question complaints stopped, because state now remembered every answer. The self-contradictions disappeared, because later steps stayed consistent with recorded conclusions. And the looping ended, because the stopping condition gave the chain a definite finish.
What It Cost
The redesign was not free — it took longer than the wording tweaks and added structural complexity to the prompt. But it was the complexity that made the chain reliable, and the team judged the trade worthwhile given the support burden the old version created.
The Lessons
The arc holds a few lessons that generalize well beyond this one flow.
Structure Beats Wording
The team's biggest lesson was that sequential failures are usually structural, not verbal. No amount of clearer instructions fixes a chain that has no explicit state. Reach for structure first.
Diagnose by Tracing Backward
Tracing failures backward from the bad output to the missing mechanism — rather than guessing at fixes — was what turned a vague mess into three nameable causes. That diagnostic habit transfers to almost any chain that misbehaves.
What the Team Would Do Differently Next Time
With the rebuild behind them, the team reflected on how they would approach the next sequential prompt from the start, rather than discovering its weaknesses in production.
Design State First, Not Last
In the rebuild, state was a retrofit bolted onto a chain that had not been built for it. Next time, the team would design the state object before writing any decision logic, because every decision reads and writes state and should be built around it from the beginning. Starting with state would have prevented the original failures outright.
Write the Stopping Condition Before the Steps
The original chain had no defined finish, which is why it looped. The team concluded that the stopping condition should be one of the first things written, not an afterthought, because it shapes what each step is working toward. A chain that knows its finish line behaves differently from one that does not.
Stress Test From the Start
The two state bugs caught during the rebuild's stress testing would have been cheaper to catch on day one. The team's takeaway was to bring adversarial, messy inputs into testing from the first working version rather than saving them for the end:
- Build a small set of deliberately awkward inputs alongside the first draft.
- Run them after every meaningful change, not just before release.
- Treat each new production failure as a permanent addition to that input set.
This mirrors the always-on instinct in the broader stress-testing practice and would have shortened the whole painful arc.
Frequently Asked Questions
Why didn't rewriting the instructions fix the problem?
Because the failures came from missing structure, not unclear language. The chain had no explicit memory of prior decisions, so no amount of clearer wording could make it stay consistent across steps. The fix had to add state, not polish prose.
How did the team find the root causes?
They traced specific failures backward from the bad output to the missing mechanism. Repeated questions pointed to absent state; contradictions pointed to the same gap; looping pointed to a missing stopping condition.
What was the single most important change?
Introducing an explicit, structured state object. It directly fixed the repeated questions and contradictions, and it gave every later decision something consistent to build on.
Did the redesign make the prompt more complex?
Yes, and deliberately so. The added structure — state, stopping condition, decision loop — was the source of the reliability gain. The team accepted the extra complexity because the old simplicity was the cause of the failures.
How did stress testing change the outcome?
It surfaced two state-update bugs before release. Running the chain against contradictory and awkward inputs exposed breaks that clean testing would have missed, so they were fixed before users encountered them.
Can a small team replicate this approach?
Yes. The whole arc — trace failures backward, name the structural causes, add state and a stopping condition, build a one-decision loop, stress test — needs judgment and care, not a large team or special tooling.
Key Takeaways
- A demo-perfect chain unraveled in production through repeated questions, self-contradiction, and looping.
- The team's first instinct, rewriting instructions, failed because the problem was structural, not verbal.
- Tracing failures backward revealed three root causes: implicit state, no stopping condition, and no recovery.
- The fix was an explicit structured state object, a defined stop, stated criteria, and a one-decision-per-pass loop.
- Stress testing against awkward inputs caught two state bugs before release.
- The enduring lesson: sequential failures are usually structural, so reach for state and structure before reaching for better wording.