Work on several things

One lookup is easy to follow. A batch introduces another question: must each call wait for the previous one, or can several calls make progress together?

Start with the result you need

Suppose you need one answer for each input, in the same order. That requirement is different from “give me the first answer that arrives.” Decide which result your caller needs before choosing a concurrency operation.

The standard library's task functions express these choices. task.map_all works on all inputs concurrently and returns results in input order. task.map_limit bounds the number worked on at once. Taking results in completion order requires a different arrangement, using operations such as task.first.

Completion order can matter

If you select whichever answer arrives first, arrival order affects the program's result. A recorded run must retain the choices needed to reconstruct that result. If scheduling changes no value the program sees, the record does not need a transcript of every scheduling step.

Do not confuse a task inside a Flow run with a worker process in an application. Flow describes the program's concurrent work; the host supplies the implementations behind Tool calls.

Try reasoning before adding code

Imagine three inputs A, B and C. Their calls finish C, A, B. What order should an input-ordered map return? A, B, C. What should “first completed” return? C. Write that expectation down before changing the workflow.

The fan-out example shows the complete pattern. The completion-order example shows the other requirement. Read the two side by side and identify where their returned order comes from.

Exact rules: concurrency.