The short version

Efficient tool use follows the structure of the work. Independent calls can start together. A call that needs a real identifier, result, or decision from another call must wait.

The useful distinction is not fast versus slow. It is independent versus dependent.

Draw the graph before launching work

For each proposed tool call, identify its required inputs and where those inputs come from. If every input is already known and no other call can change its meaning, it may belong in a parallel group.

After that group completes, a join point combines the results. A later lookup may then depend on the selected item, and the final synthesis may depend on that lookup.

This pattern often alternates: parallel reads, sequential selection, another parallel group, and a final decision.

Example

An assistant preparing a project comparison can retrieve the budget, schedule, and requirements at the same time. It must wait for those documents before choosing the project that needs attention. A subsequent owner lookup uses the selected project’s identifier, so it cannot safely begin before the selection.

Guessing the identifier to launch the lookup early is not an optimization. It changes the task into a speculative request and can produce an answer about the wrong object.

Make the prompting rule concrete

Run tool calls together when they are independent and every required input is known. Wait when a call needs a value or decision from an earlier result. Never invent identifiers or use placeholders to force parallel execution.

This rule defines efficient behavior more clearly than “use tools quickly.”

Handle errors at the join point

Parallel calls can fail separately. Preserve each failure and decide whether the missing result blocks the task. Do not synthesize as if every source returned successfully.

Concurrency also increases service load. Respect rate limits and avoid launching broad speculative work when a smaller group can answer the question. The ideal group is the smallest set of independent calls that materially advances the task.

Be careful with state changes

Two writes can conflict even if their parameters are known. Consider ordering, shared state, approval, and the effect of partial failure before treating mutations as independent. Evidence retrieval is often a good first target for parallelism; consequential actions need a stricter dependency analysis.

Practical checklist

  • List real inputs for every call.
  • Group only genuinely independent operations.
  • Wait at the join point.
  • Preserve partial failures.
  • Sequence dependent lookups and decisions.
  • Check shared state before parallel writes.

Try it

Map a workflow that reads three proposals, chooses one, finds its owner, and drafts a response. Mark the parallel group, join point, dependent lookup, and final synthesis.