When is it unsafe to execute multiple agent tool calls in parallel?

Multiple proposed calls do not imply independence

Concurrency is safe only when the operations' data and effect dependencies permit it. A recommendation that needs a freshly fetched account cannot run correctly before that fetch completes. Two independent reads may be parallelizable, while two writes to the same resource may conflict even if neither consumes the other's output.

The application executes tool calls and maps outputs to the corresponding call identifiers. It must enforce a valid execution plan rather than assuming that a model's list is a concurrency contract.

fetch_account ----\
                  -> prepare_recommendation -> review
fetch_policy -----/

Validate a dependency plan before execution

Python 3, standard library only. This builds dependency layers; it does not perform parallel execution. Every graph is validated before any side effect would be allowed.

def layers(graph):
    known = set(graph)
    if any(not set(deps) <= known for deps in graph.values()):
        raise ValueError("unknown dependency")
    remaining = {node: set(deps) for node, deps in graph.items()}
    completed = set()
    plan = []
    while remaining:
        ready = sorted(node for node, deps in remaining.items()
                       if deps <= completed)
        if not ready:
            raise ValueError("dependency cycle")
        plan.append(ready)
        completed.update(ready)
        for node in ready:
            del remaining[node]
    return plan

graph = {"account": [], "policy": [],
         "recommendation": ["account", "policy"]}
plan = layers(graph)
assert plan == [["account", "policy"], ["recommendation"]]
print("execution layers:", plan)
try:
    layers({"a": ["b"], "b": ["a"]})
except ValueError as error:
    print(error)

Expected output:

execution layers: [['account', 'policy'], ['recommendation']]
dependency cycle

Add the constraints a graph cannot infer

Validate the graph's identifiers, dependency references and cycles before beginning. Resolve outputs by stable call identity rather than whichever operation finishes first. Validate each result before supplying it to a dependent step.

Dependencies in a model proposal are untrusted. The application knows additional requirements: authorization, mutually exclusive resource mutations, transaction boundaries, concurrency limits and human approvals. Add those constraints or reject the plan. A missing edge is not proof that two effects commute.

Handle failures explicitly. If fetching policy fails, do not let a downstream recommendation proceed using an empty object and describe it as validated. Decide whether independent successful work remains useful, whether siblings should be canceled and how late results are reconciled.

Test ordering, not just final text

Record execution events and assert that every prerequisite completed successfully before its dependent step began. Test out-of-order completion, a missing result, duplicate call identifiers, a cycle and one slow dependency. Use harmless fixtures before enabling external writes.

The example does not implement a distributed scheduler, concurrent result storage or rollback. It shows one invariant: a validated dependency plan can separate independent layers from dependent steps. Real effects still need their own concurrency and retry protections.

Source checked 2026-10-08: OpenAI function calling describes application-side execution and call/output correspondence. The graph algorithm, effect-dependency discussion and tests are our own AI-assisted material, not an automatic provider execution guarantee.