This topic ties the module together with one continuous scenario, run start to finish: an ambiguous production problem, worked through with Sequential Thinking MCP from initial framing to an executed fix. The agent used here is Claude Code, but the workflow shape — frame, branch, revise, convert to tasks, execute — transfers directly to any of the other three clients covered in this module.
Workflow Overview: From Ambiguous Problem Statement to Executable Plan
The starting point is deliberately underspecified, the way real incidents actually arrive:
Checkout p99 latency doubled from ~400ms to ~900ms sometime after yesterday's
deploy. We don't know what changed exactly — the deploy included a dependency
bump, a new discount-code feature, and an unrelated logging change. Figure out
what's going on and fix it.
Three things make this a genuine sequential-thinking candidate rather than a quick prompt-and-answer: it's ambiguous (three plausible causes bundled in one deploy), it needs verification at each step before moving forward (guessing wrong and "fixing" the wrong thing wastes a deploy cycle), and the eventual output needs to be both a diagnosis and an executable plan, not just an opinion.
The overall shape of the workflow has four stages, each covered in its own section below: frame the problem and list what's actually unknown, branch across the plausible causes and score them against evidence, revise the branch that gets it wrong, then convert the surviving hypothesis into a concrete, executable task list.
Tips
- Resist the urge to hand the agent a pre-formed hypothesis ("it's probably the dependency bump") — let the framing stage actually enumerate all three candidates, or you'll bias it toward confirming your first guess.
- Treat the ambiguity as the reason to use this tool at all — a problem with one obvious cause and one obvious fix doesn't need a numbered, revisable chain.
- Keep the human in the loop between diagnosis and execution — ask for the plan first, confirm it, then let the agent execute, rather than granting open-ended access to deploy a fix based on an unreviewed chain.
Step 1: Framing the Problem and Enumerating Unknowns
Use sequential thinking to diagnose this. Start by listing what we actually
know versus what's speculation, and don't commit to a root cause until
you've checked logs and metrics, not just reasoned about what's plausible.
{
"thought": "Known facts: p99 went from ~400ms to ~900ms starting after yesterday's deploy. Three changes shipped together: (1) a dependency bump — need to check the changelog, (2) a new discount-code feature on the checkout path, (3) an unrelated logging change. Everything else right now is speculation and needs evidence before ruling anything in or out.",
"thoughtNumber": 1,
"totalThoughts": 8,
"nextThoughtNeeded": true
}
{
"thought": "Checked the deploy diff directly: the dependency bump was for a date-formatting library, used only in the order-confirmation email template, not in the checkout request path at all. Low prior for this being the cause — it's not even in the hot path. Flagging as unlikely rather than ruling it out entirely.",
"thoughtNumber": 2,
"totalThoughts": 8,
"nextThoughtNeeded": true
}
{
"thought": "Checked APM traces for the checkout endpoint from before and after the deploy. The added latency isn't spread evenly across the request — it's concentrated in a single new span labeled 'discount-code-validation' that didn't exist in yesterday's traces. This is now the leading hypothesis, and it's evidence-based, not just elimination by unlikeliness of the alternatives.",
"thoughtNumber": 3,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
Notice thought 3 doesn't just deprioritize the other two candidates — it actively looked at trace data and found the specific new span responsible. That's the difference between "structured reasoning" as a formatting exercise and structured reasoning that's actually doing diagnostic work: each thought either produces new evidence or draws a conclusion from evidence already gathered, never just restates the problem in different words.
Tips
- Ask explicitly for evidence-gathering before conclusions ("check logs and metrics, not just reasoned about what's plausible") — otherwise the model will happily produce a plausible-sounding root cause with no actual verification behind it.
- Watch fortotalThoughtsshrinking once real evidence narrows the field (8 to 6 here) — that's a healthy sign the chain is converging on facts, not just running out of things to say.
- A thought that neither adds evidence nor draws a new conclusion is filler — if you see one, that's a sign to ask the model to be more concrete rather than let the chain pad itself out.
Step 2: Branching Alternatives, Scoring Trade-offs, and Revising Assumptions
With the discount-code-validation span identified as the likely source, the next question is why it's slow — and here's where the initial guess turns out to be wrong, and the revision field earns its place in the transcript.
{
"thought": "Reading the discount-code-validation code (src/checkout/discountValidator.ts) — it makes a synchronous HTTP call to a third-party fraud-check API for every discount code entered, added as part of yesterday's feature. Hypothesis: this external API call is the latency source.",
"thoughtNumber": 4,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "Checked the fraud-check API's own status page and our outbound request logs — that API is responding in 40-60ms consistently, no degradation on their end. That's not enough on its own to explain a 500ms increase. The external call is real but it's not the full story — need to check what's happening around it, not just the call itself.",
"thoughtNumber": 5,
"totalThoughts": 7,
"nextThoughtNeeded": true,
"needsMoreThoughts": true
}
{
"thought": "Revising thought 4: the external API call isn't the primary cause. Found it — discountValidator.ts calls the fraud-check API once per discount code character validation retry, and the retry logic has no backoff and no cap: a malformed or rate-limited response triggers up to 8 retries sequentially before falling back. 8 retries x ~60ms average is roughly 480ms, which matches the observed latency increase almost exactly.",
"thoughtNumber": 6,
"totalThoughts": 7,
"nextThoughtNeeded": true,
"isRevision": true,
"revisesThought": 4
}
This is the chain doing its job. Thought 4's hypothesis (the external call itself is slow) was reasonable given the evidence available at the time, but it was incomplete — and rather than quietly folding the retry-logic discovery into a vague "it's more complicated than that," the chain explicitly says thought 4 needs revising and states exactly why. Anyone reading this transcript later — during a postmortem, or when a similar bug shows up in a different service six months from now — gets the real causal chain, not a cleaned-up narrative that hides the false start.
Branching would have been the right move one step earlier if there were two live hypotheses worth comparing in parallel (say, "retry logic bug" vs. "connection pool exhaustion from the new concurrent calls") — in this case the evidence was decisive enough that linear revision was the more honest representation of what actually happened, rather than manufacturing a branch for a comparison that evidence had already settled.
Tips
- Don't force a branch when evidence has already ruled out the alternative — branching is for genuinely live trade-offs, not a formatting habit applied to every step.
- A good revision states the specific new evidence that triggered it (the retry-count math here), not just "actually, I was wrong" — vague revisions are barely more useful than none at all.
- Do the arithmetic check yourself when a chain claims numbers "match" (8 retries × 60ms ≈ 480ms here) — it's a cheap sanity check and catches the rare case where a plausible-sounding explanation doesn't actually add up.
Step 3: Converting the Reasoning Chain into a Task List and Executing
Diagnosis without execution is just an interesting writeup. The last thought in the chain should convert directly into concrete, verifiable work:
{
"thought": "Fix: add exponential backoff with a hard cap of 2 retries (not 8) to the fraud-check API call in discountValidator.ts, and add a circuit breaker so a sustained failure short-circuits to a fail-open state (allow checkout, flag for manual fraud review) rather than retrying indefinitely on the checkout hot path. Also add a specific alert on discount-code-validation span duration so this class of regression is caught before it doubles p99 again.",
"thoughtNumber": 7,
"totalThoughts": 7,
"nextThoughtNeeded": false
}
From here, the pattern that works well in Claude Code is asking the agent to turn the finished chain directly into a tracked task list before touching any code — using the built-in todo tracking rather than treating the fix as one big undifferentiated edit:
Convert that final plan into a task list and work through it one item at a
time, running the checkout test suite after each change.
Which produces a concrete, ordered breakdown:
1. Add exponential backoff (base 50ms, max 2 retries) to the fraud-check API
call in discountValidator.ts
2. Add a circuit breaker (open after 3 consecutive failures within 60s,
half-open retry after 30s) wrapping the fraud-check call
3. Change the failure fallback from "reject checkout" to "allow checkout,
flag order for manual fraud review" when the circuit is open
4. Add a p99 latency alert on the discount-code-validation span,
threshold 200ms
5. Run the checkout integration test suite and confirm no regression
Executing this as five discrete, verifiable steps — each one small enough to review and each one testable in isolation — is a direct, mechanical translation of the reasoning chain's final thought. That's the actual payoff of having gone through the structured process: the fix isn't a single sprawling diff justified by a paragraph of prose, it's five reviewable commits, each traceable back to a specific numbered thought that explains why it exists.
Once the code changes land, it's worth closing the loop by confirming the fix against the original symptom — re-running the same trace query from thought 3 against a canary deploy and confirming the discount-code-validation span duration has actually dropped back toward baseline, not just trusting that the retry-cap change should theoretically fix it.
Tips
- Always convert the final thought into a discrete, ordered task list before executing — a reasoning chain is not itself an execution plan, and skipping this step tends to produce one large unreviewable diff.
- Keep the failure-mode change (fail-open with manual review, in this case) as its own reviewable step — it's a behavioral change with its own risk profile, distinct from the performance fix, and deserves separate scrutiny.
- Close the loop with real verification against the original metric, not just a passing test suite — tests can pass while the actual production symptom (p99 latency) persists if the root cause diagnosis was subtly incomplete.
Tips
The full arc here — ambiguous problem, evidence-gathering framing, a revision that corrects a reasonable but incomplete first hypothesis, and a final thought that converts cleanly into an executable, reviewable task list — is what Sequential Thinking MCP is actually for. It's not decoration on top of normal agent reasoning; it's a way to make a genuinely non-obvious diagnosis auditable, and to make sure the fix that comes out the other end is traceable back to specific evidence rather than a plausible-sounding guess.
Tips
- Judge whether a problem deserves this tool by whether the diagnosis could plausibly go wrong in a costly way if rushed — a doubled p99 on checkout qualifies; a typo in a log message doesn't.
- Insist on evidence per thought, not just structure — a well-formatted chain of guesses is no better than one big paragraph of guesses.
- Never skip the conversion-to-task-list step — it's the hinge between "the agent reasoned well" and "the agent shipped a fix you can actually review."