Build parallel fan-out/fan-in workflows

Learning objective

Build a parallel fan-out/fan-in workflow when subtasks can execute independently. This lesson focuses on the split, branch isolation, join, and result aggregation rather than general graph control flow or model-driven routing.

Core idea

Treat a parallel workflow as split, isolate, barrier, combine:

1. Fan out: Dispatch several known subtasks from the same validated input.
2. Isolate: Let each branch run without reading another branch’s result or depending on its completion order.
3. Fan in: Wait at a barrier until every required branch reaches a terminal state.
4. Combine: Validate the named results and synthesize one downstream input or response.

The independence test is the design gate: Could every branch start now and still produce a correct result if its peers were slow, failed, or completed in a different order? If not, the branches contain a dependency and should not share the same fan-out stage.

Google Cloud’s agentic design-pattern guidance recommends this pattern for independent tasks, such as gathering from several sources or evaluating several options. Fixed logic controls dispatch; a model does not decide which branch runs.

How it works

Define the fan-out boundary

First, normalize and validate the common input. Then give each branch only the context and permissions that its task requires. Branches may read the same immutable input, but they must not use peer results as prerequisites.

Define a contract for each result: branch identity, status, typed payload, evidence references, and error details. Store each result under a distinct key. Do not let branches overwrite the same state key or assume that list position represents a specific branch.

In Agent Development Kit (ADK), a ParallelAgent starts its declared subagents concurrently. Their events and completion order can be interleaved. Starting in ADK 2.0 for Python and Go, templated workflows are superseded by graph-based workflows, but the independence rule remains. The broader ADK workflow documentation notes that parallel children can access shared session state, so branches must use distinct output keys to avoid races. Distinct branch paths can isolate history in some memory implementations; they do not make shared writes safe.

Add a real fan-in barrier

The join is more than collecting whichever response arrives first. It must:

1. track each expected branch by identity;
2. wait until all required branches finish or reach their timeout;
3. validate every successful payload against its contract;
4. apply the declared failure policy; and
5. pass a named result set with a deterministic schema to the combining step.

The combine step may be deterministic code, an agent, or both. Use code for validation, completeness checks, and rule-based conflict resolution. Use an agent when synthesis requires semantic judgment. Preserve source identity so the synthesizer can attribute claims and handle disagreement.

Make failure semantics explicit

Choose the completion rule before execution:

• All required: Any exhausted branch failure stops synthesis and returns a typed workflow failure.
• Partial result allowed: The join marks missing or failed branches, and the synthesizer produces a visibly incomplete result only when policy permits it.
• Minimum set or quorum: The join proceeds only when the declared minimum evidence set succeeds; remaining results are optional.

Set a timeout and bounded retry policy per branch. A slow branch otherwise sets the latency of the join. Make side-effecting work idempotent before retrying it, and do not retry successful peers because one branch failed.

Key distinctions and trade-offs

Parallel orchestration makes work eligible to run concurrently; it does not guarantee simultaneous execution. Runtime limits and resource contention can queue branches. Google Cloud Workflows, for example, supports a concurrency_limit and states that parallel branches can run in any order.

Ideally, stage latency approaches the slowest required branch plus orchestration overhead, rather than the sum of branch latencies. The trade-off is higher simultaneous demand for models, tools, connections, and tokens. Parallel work can reduce elapsed time while increasing peak use and aggregation complexity.

Do not confuse these patterns:

Architecture / decision scenario

A commerce support system must assess a refund request. After validating the request, it starts three specialists:

• an order agent verifies purchase and payment records;
• a policy agent finds the applicable refund rules from product, location, and purchase date; and
• a risk agent evaluates fraud signals.

Each specialist receives the same immutable request and separate data access. None needs a peer’s answer, so the orchestrator fans them out. Each writes a named, schema-validated result with evidence references.

The barrier waits for all three because the decision requires all three checks. A deterministic function verifies completeness and applies hard rules. A response agent explains the result from the evidence. If policy lookup times out after bounded retries, the workflow returns a review-needed status; it does not decide from two results or rerun successful checks.

Making policy lookup depend on the order agent’s output would invalidate this fan-out. The team would need to move the lookup to a later stage or redesign the input so that it receives every required field before dispatch.

Common exam traps

• Choosing parallel execution merely because low latency is desirable, even though one branch consumes another branch’s output.
• Treating concurrency as guaranteed simultaneous execution or guaranteed result order.
• Letting every branch write the same state key and assuming the last value is the correct aggregate.
• Starting synthesis after the first success when the decision requires every branch.
• Retrying the whole fan-out after one failure and duplicating successful work or side effects.
• Using a model-driven coordinator to dispatch a fixed, known set of branches.
• Assuming deterministic dispatch makes model-generated results deterministic.

What to remember

• Use fan-out only when every branch can run correctly without peer results.
• Give branches immutable inputs, minimum necessary context, and distinct result keys.
• Make fan-in a barrier with named contracts, timeouts, and an explicit failure policy.
• Aggregate by branch identity, never by completion order.
• Expect lower elapsed latency but higher peak resource use and synthesis complexity.

Knowledge check

References

• Google Cloud Architecture Center, Choose a design pattern for your agentic AI system
• Agent Development Kit, Parallel template workflow agent
• Agent Development Kit, Custom template workflows
• Google Cloud Workflows, Execute workflow steps in parallel