Google ADK and Agentic Design Patterns (Part 1): Architecture, Primitives and Multi-Agent Systems
A systems-level deep dive into Google’s Agent Development Kit and the architectural patterns shaping production-grade multi-agent systems.
This article introduces a systems-level mental model for designing agentic applications using Google’s Agent Development Kit (ADK). Rather than treating agents as glorified LLM wrappers, ADK frames them as composable, distributed cognitive services.
In Part 1, we focus on:
ADK’s architectural primitives
hierarchical composition and execution semantics
the multi-agent patterns emerging from Google’s guidance
design tradeoffs observed in real systems
Part 2 will cover memory, evaluation, guardrails, observability, and production architecture.
1. From LLM wrappers to distributed cognitive systems
The shift toward agentic architectures is less about “agents” themselves and more about a deeper transformation in how we design software systems around reasoning engines. Early LLM applications followed a predictable trajectory: prompt templates, retrieval augmentation, tool calls.
But as soon as tasks became open-ended, multi-step, and domain-spanning, single-agent approaches began collapsing under their own ambiguity. Prompt-level orchestration does not scale.
Google’s ADK represents a decisive move away from prompt-centric thinking toward structured orchestration of reasoning systems. The key shift is conceptual:
Agentic systems should be designed like distributed systems — not like prompts.
ADK’s contribution is not primarily its SDK surface, but its formalization of reusable architectural patterns for cognitive workflows.
2. A mental model for ADK multi-agent systems
ADK defines a multi-agent system as a hierarchy of specialized agents coordinating toward a shared objective. That definition embeds three foundational assumptions.
Specialization over generalization
Large monolithic agents degrade quickly when handling heterogeneous tasks. Splitting responsibilities across specialized agents improves:
controllability
interpretability
evaluation granularity
cost predictability
This mirrors microservice decomposition — but with reasoning responsibilities instead of compute ones.
Emergent behavior as a feature
Multi-agent architectures often exhibit useful emergent properties:
implicit consensus formation
error correction loops
dynamic task routing
Rather than eliminating these dynamics, ADK encourages shaping them via structured orchestration.
Explicit orchestration over implicit reasoning
A key philosophical difference between ADK and earlier agent frameworks is its emphasis on deterministic workflow control.
Instead of relying on an LLM to infer process structure, ADK lets engineers define execution topology explicitly and then insert reasoning only where needed.
This separation of concerns is arguably the most important design insight behind the framework.
3. ADK primitives: the compositional toolkit
Nearly all ADK systems emerge from three primitive agent types plus hierarchical composition semantics.
3.1 LLM Agents: cognitive execution units
LLM agents perform:
interpretation
reasoning
planning
decision-making
They sit at decision boundaries and should be used sparingly. Overusing LLM agents for orchestration often leads to fragile systems with poor reproducibility.
A useful heuristic:
If logic can be deterministic, don’t delegate it to an LLM.
3.2 Workflow Agents: execution topology
Workflow agents structure execution flows without reasoning overhead.
Core variants:
SequentialAgent
Deterministic pipelines with predictable semantics.
ParallelAgent
Concurrent decomposition with join semantics.
LoopAgent
Iterative refinement with termination criteria.
These constructs function similarly to DAG orchestration frameworks but embed naturally into agent hierarchies.
3.3 Custom Agents: deterministic integration layers
Custom agents typically encapsulate:
external system integration
rule-based transformations
heavy compute steps
In practice, production systems rely heavily on custom agents for reliability and cost efficiency.
4. Hierarchical composition and execution semantics
ADK systems typically resemble execution trees:
root orchestrator defines intent
intermediate agents transform state
leaf agents execute specialized tasks
Shared session state
A defining feature of ADK systems is shared session state across sub-agents. This enables implicit coordination without heavy message passing but introduces design challenges:
state bloat
race conditions in parallel execution
unclear ownership boundaries
In complex systems, explicit state contracts often outperform implicit sharing.
Tools vs sub-agents
One recurring design decision:
Tools
Stateless, atomic capabilities.
Sub-agents
Stateful, multi-step reasoning workflows.
A practical rule:
If the capability needs reasoning or iteration, it should likely be a sub-agent.
5. The emerging multi-agent pattern taxonomy
Google’s guidance implicitly converges on a set of recurring patterns. These are not rigid templates but composable execution motifs.
5.1 Sequential pipelines
The simplest structure: deterministic stepwise processing.
Strong fit for:
ETL-like reasoning workflows
structured analysis pipelines
compliance transformations
Tradeoff: limited adaptability to uncertainty.
5.2 Hierarchical orchestrator-worker systems
Perhaps the dominant real-world pattern.
Structure:
planner agent decomposes goals
workers execute specialized subtasks
synthesizer aggregates results
Works well for:
research agents
analytics workflows
enterprise copilots
Main risk: cascading failure from planner errors.
5.3 Router architectures
A routing agent dispatches requests to specialized workers.
Strong fit for:
multi-domain copilots
service desks
modular enterprise platforms
Key challenge: misrouting due to ambiguity.
5.4 Parallel decomposition
Tasks split into independent subtasks executed concurrently.
Best suited for:
large-scale research
ensemble reasoning
consensus workflows
Primary tradeoff: reconciliation complexity.
5.5 Iterative refinement loops
Critic-generator loops and self-improvement cycles.
Ideal for:
long-form writing
code generation
design optimization
But expensive and latency-heavy.
5.6 Agent-as-tool ecosystems
Agents exposed as reusable internal services.
This pattern becomes critical in large organizations where agent capabilities must be discoverable and composable.
5.7 Human-in-the-loop governance
In regulated domains, humans serve as supervisory agents enforcing:
safety constraints
accountability boundaries
subjective judgment
Hybrid systems often outperform fully autonomous ones in production.
5.8 Hybrid compositions
Most real systems combine patterns dynamically:
hierarchical + parallel
router + loop
sequential + HITL
The art lies in knowing where to introduce structure and where to allow flexibility.
6. Real-world tradeoffs
Latency and cost explosion
Each additional agent multiplies model calls. Parallelization reduces latency but increases spend.
Orchestration brittleness
LLM-driven planners introduce unpredictability. Deterministic fallbacks are essential.
Observability complexity
Multi-agent systems require:
structured tracing
per-agent evaluation
state introspection
Traditional logging is insufficient.
Evaluation challenges
Testing agents individually does not guarantee system reliability. Emergent failures often occur only in integrated runs.
7. Design heuristics
Based on production experience and evolving guidance:
Structured workflows → sequential pipelines
Open-ended tasks → hierarchical orchestration
Multi-domain systems → routing patterns
High-throughput systems → parallel decomposition
High-risk domains → HITL
But more importantly:
Prefer simpler systems until complexity is justified by measurable gains.
Conclusion
Google ADK does not introduce fundamentally new capabilities. Its significance lies in crystallizing a shared vocabulary for designing agentic systems as structured, composable architectures.
The real lesson is not about tools, it is about adopting a systems engineering mindset for reasoning infrastructure.
