Putting a thinking step inside a flow

Up to now every step in your flows has been mechanical: move this, copy that, notify someone. This lesson adds the step that is not mechanical — a place in the middle where the flow asks a model to read something and produce something. It is the most useful addition you will make, and the one that needs the tightest leash.

The shape that works: narrow input, narrow output, no decisions. "Read this enquiry and pull out the company name, the quantity, and the deadline as three fields" is a good AI step: the input is one message, the output is three short strings, and nothing branches on the result. "Read this enquiry and decide whether to accept it" is a bad one, and not because the model would necessarily choose wrong — because nobody will notice when it does.

Give it a shape to fill, not a request to interpret. The step should say what fields it wants, in what format, and its instruction for the case where the answer is absent — "if the deadline is not stated, return the word NONE". A flow that receives "I couldn't find a deadline, but based on the tone it sounds urgent" cannot use it: the next step expects a date. Half the failures of AI-in-a-flow are not wrong answers, they are right answers in the wrong shape.

And build the escape hatch before you need it. Every AI step gets a rule for what happens when the output does not fit — route to a human queue, not onward into the flow. The rule is one line and it is the difference between a bad extraction becoming a bad row in a sheet, which you will find in three weeks, and it becoming an item in your morning review, which you will fix in ten seconds.

Cost and speed change the design more than accuracy does. An AI step is slower than a mechanical one and it is not free, so putting one inside a loop that runs over a hundred items is a different decision from putting one on a trigger that fires twice a day. The habit worth building early: filter first, then think. Cut the list down mechanically, and only then hand what remains to the expensive step.

One quiet property to design around: the same input will not always produce a byte-identical output. For extraction that rarely matters. For anything you compare against a previous run — "has this changed since yesterday?" — it matters a lot, and the fix is to compare the extracted fields rather than the generated text. Build the comparison on the structured part, never on the prose.