What does Google ADK's ParallelAgent isolate between branches, and what do they share?

## What fan-out buys you `ParallelAgent` exists for one reason: independent work that would otherwise be serialised. Three market analyses that each take six seconds cost eighteen seconds in a `SequentialAgent` and roughly six in a `ParallelAgent`. Since neither composition type calls a model itself, the whole saving is real wall-clock latency, not tokens — you still pay for every branch's inference. ## The isolation: separate branches of history Each sub-agent runs in its own branch of the invocation's event history. Practically, this means branch A's messages, tool calls and tool results are not injected into branch B's prompt. That is deliberate and it is what makes concurrency safe at the prompt level: if branches shared one linear history, they would be interleaving messages into each other's context in a non-deterministic order, and each branch's prompt would balloon with work it does not care about. The corollary is that a branch cannot see, and must not depend on, what a sibling branch is doing. Any design where branch B reads what branch A "just produced" is not parallel — it is a sequence you have accidentally made concurrent, and it will pass in testing whenever A happens to finish first. ## The sharing: one session state Session state is not branched. All branches read and write the same store, and that is the single most important operational fact about `ParallelAgent`: - **Distinct output keys are mandatory.** If two branches both declare `output_key="summary"`, both write it, and the value you keep is whichever branch completed last. Nothing errors. You lose an entire branch's work and the run looks successful. Name keys per branch — `summary_market`, `summary_legal`, `summary_technical`. - **Reads are unsynchronised.** A branch that reads a key another branch is writing gets whatever happens to be there at that instant. If a placeholder in a branch's instruction references a key that only a sibling produces, you have built a race. - **State is also how the merge works.** Because state survives the parallel block, a downstream agent can read all branch keys at once. That is the intended join. ## There is no join step `ParallelAgent` finishes when its branches finish; it does not synthesise anything. The merge is your job and it is an agent. The canonical structure is a `SequentialAgent` whose members are the `ParallelAgent` and then a synthesiser `LlmAgent` whose instruction templates in each branch's key: `SequentialAgent(sub_agents=[ParallelAgent(sub_agents=[a, b, c]), synthesiser])` Write the synthesiser's placeholders in the optional form so a branch that produced nothing degrades to a partial answer rather than breaking prompt assembly. ## The operational hazards a senior is expected to raise **Concurrency against shared limits.** Eight branches are eight simultaneous model requests plus whatever their tools call. You are now generating a burst against a per-minute quota, a downstream API, or a connection pool that was sized for serial traffic. Fan-out width is a capacity decision, not a stylistic one — and rate-limit rejections under a burst look like flaky agents, not like a quota problem, in the trace. **Failure semantics.** Treat an exception in one branch as something that can take down the parallel step rather than quietly yielding a partial result. If best-effort is what you want, make each branch tolerant on its own — catch inside the branch's tools and have the branch write an explicit "unavailable" value to its key — so the merger sees a missing-data marker rather than the whole invocation failing. Designing for partial results is a decision you make in the branches, not something you get for free. **Tail latency, not average.** A parallel block costs as much as its slowest branch. Adding a fourth branch that is usually fast but occasionally times out converts a reliable six-second step into an occasionally-thirty-second one. Fan-out improves the mean and worsens the tail; if you have an end-to-end SLO, bound each branch's own work rather than assuming concurrency has made latency a non-issue. **Debuggability.** Branched history is a gift when reading a trace — each branch reads as its own coherent conversation — but it means "what did the agent see" now has three answers. When you reconstruct an incident, reconstruct per branch, and remember that the shared state a branch read may have been written by a sibling mid-flight. ## The summary an interviewer is listening for "Context is per branch, state is shared." Everything else — distinct output keys, an explicit merger agent, rate-limit bursts, worst-case tail latency, deliberate partial-failure handling — falls out of that one sentence, and being able to derive it rather than recite it is what separates the senior answer from the documentation answer.