When an AI workflow gives you output you can't use, the instinct is to blame the model and rewrite the whole prompt. That almost never fixes it, because a workflow is a chain of steps, and usually one step is broken, not all of them. Rewriting everything just moves the break somewhere new.
If you came from the video, that's the idea: stop treating the workflow as one black box. Here's the part that doesn't fit in sixty seconds: how to actually pull the chain apart, find the one link that fails, and turn that failure into a rule so it stops happening. I'll walk one real example the whole way through.
Why "the AI is bad" is almost always wrong
Say your workflow takes some input, does three or four things to it, and hands you a result. When the result is wrong, the failure happened at a specific step: the model read the wrong file, your instructions were vague at step two, or the data going in was already broken before the AI touched it. "The AI is bad" is a verdict on the whole chain. Your job is to find the one link, and you can't do that while you're staring at the final output.
So make each step observable. Instead of input goes in, answer comes out, you want to see what each step received and what it produced. Once you can see the intermediate results, the broken step usually announces itself.
How to find the broken step
This is the sequence I run every time, in order. Don't skip to step four and start rewriting the prompt. That's the mistake that keeps people stuck.
List the steps out loud
Write down what the workflow actually does, one line per step. "Pull the property details, then draft a description, then check it against the fair-housing rules, then format it." Most people have never written this down, and half the bugs are visible the moment you do, because you realize two things are quietly happening in one step.
Print what each step hands to the next
Have the workflow show you the intermediate output between steps, not just the final result. If you can't see it, add a line to each step: "before you continue, show me exactly what you're passing on." This is the whole game. You're looking for the first step whose output is already wrong.
Run one bad case by hand
Take a single input that produced bad output and walk it through step by step. Feed step one's input to step one alone and read what comes out. Then step two. The moment an output looks wrong, stop. That step is your break. Everything downstream was just faithfully processing garbage.
Fix that one step, then rerun the whole set
Only now do you change something, and only the broken step. Then run your full set of test cases again, not just the one you fixed, because fixes have a habit of breaking a case that used to pass. If everything still passes, the fix is real.
The worked example: a listing-description workflow that keeps missing
Here's a concrete one. A real-estate agent set up a workflow to write listing descriptions. It takes the details from the MLS export (beds, baths, square footage, features), writes a warm paragraph, and formats it for the portal. It worked great in the demo. In real use, a chunk of the descriptions come out wrong: wrong bathroom count, a "cozy backyard" for a condo with no yard, and once a description that mentioned a "quiet street" for a place on a main road. She was ready to scrap the whole thing.
We listed the steps: (1) read the MLS row, (2) pull out the key features, (3) write the paragraph, (4) format. Then we printed each step's output for one bad listing. Step one read the row fine. Step two, feature extraction, is where it fell apart: the MLS export used "0" in the yard field to mean "no data entered," and the workflow read that "0" as a real value, sometimes as blank. The writing step then filled the gap with a pleasant guess. The paragraph step wasn't broken. It was doing exactly what a writing step does with missing information: inventing something plausible.
The break was step two, plus a data problem underneath it. The fix wasn't a better prompt for the writer. It was a rule at the extraction step: if a field is "0" or empty, mark it "unknown" and never describe it. Plus a rule for the writer: only describe features that are confirmed, and leave out anything unknown rather than guessing. Two narrow fixes at the two steps that were actually wrong. The pretty-prose step, the one she almost rewrote first, we never touched.
The checklist I run when something breaks
Copy this and work top to bottom. It keeps you from jumping to the fix before you've found the fault.
[ ] I wrote out every step of the workflow, one line each
[ ] I can see the output BETWEEN steps, not just the final one
[ ] I picked one input that produced bad output to trace
[ ] I found the FIRST step whose output was already wrong
[ ] I checked whether the input to that step was already broken
(a data problem, not an AI problem)
[ ] I changed only that step, not the whole prompt
[ ] I reran ALL my test cases, not just the one I fixed
[ ] Nothing that used to pass is now failingKeep a failure log so the same break can't come back
Finding the break once is good. The real win is never chasing the same one twice. Every time a case comes out wrong, log it: what went in, what the workflow did, what it should have done, and the rule you added. After a week you'll see the same two or three failure types over and over, and each one turns into a permanent rule and a permanent test case. That's how a flaky workflow slowly becomes one you trust.
Date | Input | Which step broke | What it did | What it should do | Rule I added
-------------------------------------------------------------------------------------
[..] | [..] | [step 2, extract]| [..] | [..] | [treat "0"=unknown]
[..] | [..] | [..] | [..] | [..] |
Review weekly. Turn every repeat failure into an explicit rule
at the step that broke, and add the tricky input to your test set.What goes wrong when people debug a workflow
The first trap is rewriting the final step because that's where you saw the bad output. In the listing example the bad text showed up in the paragraph, so the paragraph looked guilty. But it was innocent. If you only ever look at the end of the chain, you'll keep polishing a step that was never the problem while the real break stays put.
The second is not checking the input. A lot of "AI mistakes" are data mistakes wearing a costume. The export had a "0" that meant two different things, and no prompt in the world fixes ambiguous source data. Before you blame the model, ask whether what went into that step was already wrong. If it was, the fix is at the data, or a cleaning step, not the AI.
The third is fixing one case and calling it done. You patch the condo-with-no-yard problem, ship it, and next week it invents a garage instead. You never had a test set, so you never noticed the fix was narrow. Keep a small set of real cases, including the weird ones, and rerun the whole set after every change. A fix that breaks two old cases to save one new one is not a fix.
The last one is treating a fix as permanent without watching it. Run the workflow live a few more times on real inputs after you change something, the same way you'd watch a new hire before trusting them alone. Failures that only show up on real, messy inputs are exactly the ones your demo never had. If you're building the workflow itself, my guide to building your first AI agent covers giving each step real context and a place to record what it did, which is what makes steps observable in the first place. And when the fix means picking a different tool for one step, how to choose which AI tool to pay for is the decision I'd run.
Bad output is a symptom, not a diagnosis. Make each step show its work, trace one bad case until an output first looks wrong, and fix only that link. The step where you saw the problem is rarely the step that caused it.