Module · Executions & debugging
AI-led debugging
Lesson 8 of 11 · 6 min
Reading execution data is a skill, and like any skill it is slow before it is fast. Meanwhile the run says completed, the output looks wrong, and you have twenty minutes.
AI Debug sits on every node that has executed, alongside the tabs showing inputs, outputs and raw structure. You choose how much of the run to include, ask a question in ordinary English, and get an answer grounded in this specific execution rather than in general advice about workflows.
Scope is the only setting that matters
Two things are always included: the shape of the workflow, and the configuration of the node you are on. On top of that you choose how much execution data to hand over.
| Scope | When it is the right one |
|---|---|
- When it is the right one
- When it is the right one
- When it is the right one
- When it is the right one
Widening the scope makes the answer worse, not better. It is tempting to hand over the whole run every time on the theory that more context helps. It does the opposite: with everything included, the model has to guess what you care about, and its answer drifts toward the general. A question about one node, scoped to that node, gets a specific answer. The instinct to widen is almost always the instinct to avoid deciding what you are actually asking.
Asking a question worth answering
The question box takes plain English, and the quality of what comes back tracks the quality of what goes in more than anything else on the screen.
- Weak:
Why is this failing?— and the node did not fail, so the honest answer is that it did not, which helps nobody. - Better:
This node completed but entity_id came back empty. What in the input or config would cause that?— names the symptom, names the field, and asks about cause. - Also good: asking it to check your reasoning. “I think the condition took the false branch because total was 0 — is that what the data shows?” It will tell you when you are wrong, and being told quickly is the point.
The pattern is the same one that made prompts work in the AI path: say what you observed, say what you expected, and ask about the gap. “Why is this broken” is not a question about this run.
What to do with the answer
The response is structured around a root cause, and it is usually right. It is also a model reading a record, which means:
Verify the root cause against the run before you act on it. The answer will name a node and a field. Go and look at that field in the execution. If it says what the answer says it says, fix it. If it does not, you have learned something more useful than the answer — the model was reasoning from the shape of the problem rather than from your data, and the real cause is elsewhere.
Suggested fixes are suggestions. A proposed configuration change is a hypothesis, and you now have a cheap way to test one: apply it, save, and Run From Here. Two seconds of verification is worth more than any amount of confidence in the explanation.
It is at its best on the failures this course has been warning about. Empty fields on a completed node, a value that is a literal <not found> string, a branch that went the way you did not expect, a count that is zero when it should not be. Those are exactly the cases where the record contains the answer and reading it takes a skill you are still building.
What breaks
It cannot see what is not in the run. If the workflow never fired, if the trigger read a field that does not exist, or if the problem is in another workflow entirely, there is no execution data to reason about and you will get a plausible answer about the wrong thing. Absence of a run is still diagnosed by noticing the absence.
It does not know your intent. A workflow can execute exactly as configured and still do the wrong thing, because the configuration expresses the wrong rule. The model sees the rule you wrote, not the one you meant, and will explain the behaviour rather than question it. That gap is yours.
A confident explanation of a green run is worth checking twice. Asked why a completed node produced nothing, a model will find a reason. Sometimes the reason is that nothing was wrong and your expectation was — which is a legitimate answer and not one it always offers.
Try it
- Take the broken node from the last lesson — a misspelled entity type on a node that completed — and ask AI Debug about it with the scope on that node alone.
- Ask the same question with the scope widened to the entire execution and compare the two answers. The narrower one should be sharper; if it is not, your question was vague.
- Now ask it to check a conclusion you have already reached. Getting contradicted is the fastest use of this tab.
- Apply its suggested fix, Save, and Run From Here. Verify rather than trust — and note how short that loop is.
- Finally ask it about a run that completed and was correct. Read how it handles having nothing to find.
Next: the last three lessons are complete builds — a WhatsApp support agent, a voice agent and a calendar-to-tasks automation, each assembled from nodes you now know.