Files
Amaad Martin c75e61f5f3 docs: normalize Typescript to TypeScript across the site (#2079)
The site rendered one language under two names. Tab labels were split
137 `TypeScript` / 53 `Typescript`, with three pages carrying both
spellings at once (custom-agents.md 7/7, patterns.md 1/7,
function-tools.md 4/1), and the language-support badges were split 67/18
the same way. Because pymdownx.tabbed slugifies tab labels to lowercase,
both variants rendered and linked fine, so no link check or build warning
ever flagged it -- it was visible only to readers, as two names for one
SDK.

Every user-visible occurrence is normalized to `TypeScript`, plus the two
inconsistencies that turned up while doing it. 80 changed lines, accounted
for exactly:

  53  tab label       === "Typescript"            -> === "TypeScript"
  18  badge span      lst-typescript">Typescript  -> TypeScript
   3  prose mention   cloud-run.md, mcp-tools.md, workflows/patterns.md
   2  api-reference/index.md card heading and link text
   1  badge div attr  title="...Python and Typescript."
   1  mkdocs.yml nav  Typescript ADK              -> TypeScript ADK
   1  code fence      ```javascript -> ```typescript on a .ts include
   1  artifacts/index.md closing summary sentence
  ---
  80

The first six rows are pure casing: 78 lines that differ from their
originals by nothing but `Typescript` -> `TypeScript`. The last two are
not, and are the reason this is not a `sed`:

llm-agents.md:872 fenced `--8<-- ".../capital_agent.ts"` as ```javascript.
It was the only javascript-fenced `.ts` include in docs/ (the other 189
TypeScript fences are correct), and it cost that one snippet its
TypeScript highlighting.

artifacts/index.md:1084 closed the page by naming languages and got the
list wrong. It described reaching the artifact methods "using Python's
context objects or directly interacting with the `BaseArtifactService` in
Java" -- a two-language enumeration at the end of a page that carries
Python, TypeScript, Go, Java and Kotlin tabs (11/10/10/10/11), and one
that contradicts :556, which correctly names four of them. The
enumeration is dropped rather than extended: the sentence now describes
the two ways to reach these methods -- through the context object, or
through `BaseArtifactService` -- which is what the page actually teaches
and does not rot when a sixth language is added.

docs/api-reference/index.md is included even though the rest of
docs/api-reference/ is generated output that must not be touched. That
tree holds 3,140 generated HTML files and exactly one hand-authored page:
this one. It is Markdown, it is the only api-reference entry mkdocs.yml
lists as `.md` rather than `index.html` (:272, :441), it uses Material
`grid cards` and `:fontawesome-*:` shortcodes, and it carries a
`CONTRIBUTORS:` note citing issues #1716 and #1717. Its TypeScript card
already said "TypeScript" twice in its body text while its heading and
link text said "Typescript"; those two are now consistent with the body.
No generated file is modified.

Not in this change: the broken `SseConnectionParams` sample in
mcp-tools.md (docs-ts/p6c-mcp-ts-sample) and the `@google/adk` example
version bumps (docs-ts/p6b-example-versions). Only the casing of the
prose line above that sample is touched here.

Verified: `mkdocs build` exits 0 with an empty warning set on both main
and this branch, and the two warning sets are identical. A rendered
before/after diff of the whole site shows every `__tabbed_*` id, every
tab radio id and every heading anchor unchanged. Zero `=== "Typescript"`
and zero `lst-typescript">Typescript` remain anywhere in the repo.

Co-authored-by: Amaad Martin <amaadmartin@google.com>
2026-08-05 15:58:49 -07:00

4.6 KiB

Parallel template workflow agent

Supported in ADKPython v0.1.0TypeScript v0.2.0Go v0.1.0Java v0.2.0

The ParallelAgent class is a template workflow agent that executes its sub-agents concurrently. This execution strategy can dramatically speed up workflows where two or more tasks can be performed independently. For scenarios prioritizing speed and involving independent, resource-intensive tasks, this templated workflow facilitates parallel execution, which can significantly reduce overall processing time. When using this workflow type, it is important that each sub-agent can operate without depending on the other sub-agents. This workflow type is particularly beneficial for operations like multi-source data retrieval or heavy computations, where parallelization yields substantial performance gains.

As with other templated workflows, the execution of a ParallelAgent object is not controlled by an AI model, and is deterministic in how it executes its sub-agents. The sub-agents specified in the parallel execution set may or may not utilize AI models, but the overall execution of those sub-agents is ultimately managed by the ParallelAgent object you define.

!!! note "Alternative: graph-based workflows"

Starting in ADK 2.0 for Python and Go, templated workflows have been superseded

by more flexible workflow structures, including
[graph-based workflows](/graphs/) and
[dynamic workflows](/graphs/dynamic/).

How it works

When the ParallelAgent's run_async() method is called:

  1. Concurrent Execution: It initiates the run_async() method of each sub-agent present in the sub_agents list concurrently. This means all the agents start running at (approximately) the same time.
  2. Independent Branches: Each sub-agent operates in its own execution branch. There is no automatic sharing of conversation history or state between these branches during execution.
  3. Result Collection: The ParallelAgent manages the parallel execution and, typically, provides a way to access the results from each sub-agent after they have completed (e.g., through a list of results or events). The order of results may not be deterministic.

Independent Execution and State Management

It's crucial to understand that sub-agents within a ParallelAgent run independently. If you need communication or data sharing between these agents, you must implement it explicitly. Possible approaches include:

  • Shared InvocationContext: You could pass a shared InvocationContext object to each sub-agent. This object could act as a shared data store. However, you'd need to manage concurrent access to this shared context carefully (e.g., using locks) to avoid race conditions.
  • External State Management: Use an external database, message queue, or other mechanism to manage shared state and facilitate communication between agents.
  • Post-Processing: Collect results from each branch, and then implement logic to coordinate data afterwards.

Parallel Agent{: width="600"}

Full Example: Parallel Web Research

Imagine researching multiple topics simultaneously:

  1. Researcher Agent 1: An LlmAgent that researches "renewable energy sources."

  2. Researcher Agent 2: An LlmAgent that researches "electric vehicle technology."

  3. Researcher Agent 3: An LlmAgent that researches "carbon capture methods."

    ParallelAgent(sub_agents=[ResearcherAgent1, ResearcherAgent2, ResearcherAgent3])
    

These research tasks are independent. Using a ParallelAgent allows them to run concurrently, potentially reducing the total research time significantly compared to running them sequentially. The results from each agent would be collected separately after they finish.

???+ "Full Code"

=== "Python"
    ```py
     --8<-- "examples/python/snippets/agents/workflow-agents/parallel_agent_web_research.py:init"
    ```

=== "TypeScript"
    ```typescript
     --8<-- "examples/typescript/snippets/agents/workflow-agents/parallel_agent_web_research.ts:init"
    ```

=== "Go"
    ```go
     --8<-- "examples/go/snippets/agents/workflow-agents/parallel/main.go:init"
    ```

=== "Java"
    ```java
     --8<-- "examples/java/snippets/src/main/java/agents/workflow/ParallelResearchPipeline.java:full_code"
    ```