Work organised as a continuous pull with no fixed iteration, controlled instead by a limit on how much may be in progress at once.
Flow-based delivery removes the iteration boundary and replaces it with a constraint on quantity: nothing new starts until something in progress finishes. Planning happens at the moment an item is pulled rather than at a scheduled event, so a change of priority takes effect at the next pull instead of waiting for a cycle to end. The trade is predictability of the review point for responsiveness to what has just arrived, which is why the approach suits work whose volume and urgency fluctuate. Without a limit on work in progress it is not flow-based delivery at all, only an unbounded queue drawn on a board.
See also
A cap on how many items may be in progress at once, which forces work to be finished before anything new is started.
The number of work items completed per unit of time, counted where work leaves the system rather than where it is started.
The fixed length of the cycle a team plans, works and reviews in. Its value comes from repeating, not from being short.
One turn of a team's working cycle, fixed in length, ending in something that could in principle be delivered.
Where this comes up
Predictive work gets an ending for free, the day the thing is handed over. Iterative work has to manufacture one, which is why so much of it never formally ends at all.
Cadence is the beat the work runs to. Delivery cadence is how often finished output reaches the people who asked for it. Teams conflate the two and then wonder why nobody feels the pace.
Iteration-based agile fixes the length of the cycle and commits a batch to it. Flow-based agile fixes the amount of work in progress and pulls the next item when a slot frees.