Amaad Martin
c75e61f5f3
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>
2.8 KiB
Workflows: multi-agent, multi-node applications
As agentic applications grow in complexity, structuring them as a single, monolithic agent can become challenging to develop, evaluate, and maintain. Agent Development Kit (ADK) supports building sophisticated agent applications by composing multiple agents and executable nodes into agent workflows. Structuring agents using multiple elements can provide a number of benefits as your agent applications grow more complex and sophisticated:
- Predictability: Create more controlled task execution flow using templated logic or graph-based execution mechanisms.
- Reliability: Ensure tasks run in the required order or pattern consistently.
- Structure: Build complex processes more manageably by composing agents elements, separating task responsibilities, and limiting data contexts for given tasks.
Workflows can be built using several structures and architectures, as illustrated in the following diagram:
Figure 1. ADK workflows can have flexible execution paths, or follow specific, templated execution patterns.
The following is a quick guide to the multiple methods for building workflows for your agent application with ADK:
-
Graph-based workflows: (ADK 2.0 and higher) This workflow type allows you to compose both AI-powered agents and deterministic execution nodes into a flexible execution graph that can include decision branching.
-
Dynamic workflows: (ADK 2.0 and higher) This workflow type allows you to compose AI-powered agents and deterministic execution nodes using full programmatic code logic.
-
Collaborative workflows: (ADK 2.0 and higher) This workflow type allows a single agent to act in a dynamic coordinator role to accomplish tasks with a set of specified sub-agents.
-
Template workflows: These pre-built workflows are extended from BaseAgent and provide fixed execution logic structures including sequences, loops, and parallel execution.
Follow the links provide above for more information about each type of ADK workflow architecture.
!!! example "Experimental: Agent Routing"
Agent Routing is an experimental feature that allows you to select between
multiple agents at runtime using router functions for fallback,
A/B testing, and auto-routing. For more information, see
[Agent Routing](/agents/routing/).