Makes sense, and the flexibility argument is real — editing a prompt beats rewiring nodes.
The tradeoff I’d flag: prompt-driven escalation means your catch rate is whatever the model’s judgment happens to be on that run, with no floor under it and no easy way to measure it. I hit a version of this on an SMS pipeline where escalation depended on the model emitting a flag. Passed everything I wrote. Then a realistic message — serious part buried at the end of a long chatty one — got a genuinely good reply and no flag. Green execution, nobody notified.
Worth knowing which failure you’re actually exposed to:
- If you’re using structured output / json_schema mode, the field is always present — the soft spot is the model’s judgment of when it’s true.
- If you’re prompting “return JSON” without a schema, the field can go missing entirely on longer or unusual inputs.
Either way, ambiguous phrasing is what surfaces it, not clear-cut cases. A billing dispute phrased politely and buried mid-message, or account deletion asked sideways — “thinking about closing my account, what happens to my data?” The obvious ones always flag.
What worked for me was a cheap deterministic check on the inbound message for the high-stakes categories, running independent of the model output. Model flag stays, it’s just not the only path — gives you a floor.
Separate thing, if you branch on that boolean in an IF/Switch node: make sure the field contains only the expression, no trailing space. n8n renders it to string and the comparison silently fails false. Cost me a few hours: N8n: Switch node silently routes false when comparing a boolean — "Wrong type: 'true ' is a string but was expecting a boolean"