1. End-to-end full process design

It incorporates concepts that many frameworks have never covered.

1. Intelligent orchestration system

Flexible workflow engine • Supports two orchestration modes:

• Preset pipeline : Through workflow agent (SequentialSequential execution/ParallelParallel execution/LoopLoop execution) to build a deterministic process
• Dynamic routing system : intelligent decision-making based on LLM drive (LlmAgentTransfer mechanism) to achieve adaptive behavior flow

2. Multi-agent architecture

Modular collaboration system • Adopting layered combination architecture: building scalable applications through the layered combination of multiple specialized agents • Core capabilities:

• Distributed task coordination
• Smart delegation mechanism
• Inter-Agent Communication Protocol

3. Tool Integration Ecosystem

Multi-dimensional capability expansion

1. Pre-built toolset : out-of-the-box components such as search engines and code executors
2. Custom extensions : support user function development
3. Ecosystem Integration :

• Compatible with third-party frameworks such as LangChain/CrewAI
• Support Agent tooling (calling other Agents as tools)

4. Deployment solution

Full-scenario deployment matrix

5. Evaluation and monitoring

Three-dimensional evaluation system

1. Results quality assessment : final output accuracy/completeness
2. Process traceability assessment : step-by-step verification of execution traces (based on predefined test cases)
3. Performance indicator monitoring : runtime indicators such as response delay/resource consumption

6. Trusted Agent Development

Responsible AI Practice Framework

1. Safety protection :

• Input and output filtering mechanism
• Sensitive data control
• Interpretability :
• Transparency in decision-making process
• Auditable execution logs
• Ethical constraints :
• Bias Detection Algorithms
• Value Alignment Specification

2. Core Agent Types

ADK provides three types of core agents to build complex applications:

1. The LLM agent is driven by the Large Language Model (LLM) and has the capabilities of natural language understanding, logical reasoning, and dynamic decision-making. It can independently select tool chains and is suitable for tasks that require flexible language processing.

2. The process control agent includes three modes: sequential execution (Sequential), parallel processing (Parallel), and loop operation (Loop). It accurately controls the execution logic of other agents through predefined processes and is suitable for structured business processes.

3. Custom agents are developed by inheriting the BaseAgent base class, which supports the implementation of personalized business logic, special control flow or customized system integration to meet the needs of highly customized scenarios.

The three types of agents can be used in combination to build complex intelligent systems, and developers can flexibly choose according to scenario requirements.

3. Design features of ADK's multi-agent framework

1. System core components

Components	Technical characteristics	Implementation Mechanism	Design considerations
LLM Agent	- Based on large language models such as Gemini - Support dynamic task delegation ( transfer_to_agent) - Bindable Toolset	- Automatically generate function calls - via output_keySave output to state	- Need to be clarifieddescriptionFor routing decisions - directives need to contain delegation logic
Workflow Agent	- Does not directly handle tasks - Three subcategories:   ▪  SequentialAgent   ▪ ParallelAgent   ▪ LoopAgent	- passsub_agentsDefine subtask flows - automatically manage context branches ( InvocationContext.branch)	- Parallel execution needs to avoid state key conflicts - Loop execution needs to be set max_iterationsor termination condition
Custom Agents	- InheritanceBaseAgent - accomplish_run_async_implMethods - non-LLM logic (such as database operations)	- Free accesssession.state - passEventActions(escalate=True)Terminating the loop	- Suitable for deterministic tasks - Need to handle state persistence by yourself

2. Comparison of Workflow Agents

type	Execution Control	State Management	Typical code characteristics
Sequential Agents	- Strictly presssub_agentsList Order Execution - Pre-Order Agents output_keyAutomatically becomes the next input	- Share the sameInvocationContext - Status keys are passed directly	<br>SequentialAgent(<br> sub_agents=[A, B, C]<br>)<br>
Parallel Agents	- All sub-agents start at the same time - The execution order is uncertain	- Shared base state - Each sub-agent gets independent branchpath	<br>ParallelAgent(<br> sub_agents=[X, Y],<br> state_keys=["api1","api2"]<br>)<br>
Recurrent Agents	- Repeated execution of subagent sequence - Shared state at each iteration	- passEventActions.escalateTerminate - can read historical iteration status	<br>LoopAgent(<br> max_iterations=5,<br> sub_agents=[process, check]<br>)<br>

3. In-depth comparison of communication mechanisms

mechanism	Trigger method	Data Flow	Applicable scenarios
Shared state	- Passive reading and writingsession.state - passoutput_keyAutosave	One-way transmission: producer → state dictionary → consumer	- Sequential pipeline - intermediate results in loop iterations
LLM Delegation	- LLM generationtransfer_to_agent()Called by AutoFlowInterception Processing	Dynamic jump: current agent → target agent (need to be in sub_agentsWithin range)	- Uncertain task routing - Scenarios that require LLM to understand semantics (such as customer service transfer)
Explicit call	- passAgentToolWrapper Agent - LLM explicit call tool for the parent agent	Synchronous return: parent agent → child agent → result returns to parent agent	- Deterministic function calls - scenarios where direct return values ​​are required (such as mathematical calculation services)

4. Design pattern technical details

model	Agent combination	Key ADK Features	Implementation Example
Coordinator mode	1 LLM coordinator + N specialized sub-agents	- LLMtransfer_to_agent - Sub-agents are cleardescription	Customer Service System: - Routing Agent   transfers to "Payment" or "Technical" sub-agent according to the type of question
Generate-Review	SequentialAgent [Generator, Reviewer]	- Generator Settingsoutput_key="draft" - Reviewer readsstate['draft']	Content creation: - Generate text → Check factuality → Output final result
Parallel Collection	SequentialAgent [   ParallelAgent[Collector 1, Collector 2],   Aggregator ]	- Parallel agents define independentoutput_key - Aggregator reads multiple state keys	Data dashboard: - Get sales/inventory data in parallel → combine and generate reports
Iterative Optimization	LoopAgent [   Handler,   Condition Checker (Trigger escalate) ]	- Checker passedEventActions(escalate=True)Termination loop - Processor update state['current_result']	Code optimization: - Generate code → Run test → Continue to optimize if it fails
Human intervention	Custom tools + external system integration	- Tool call blocked waiting for human input - via CallbackContextRecovery Process	Financial approval: - Pause the process for large transactions → Wait for manual approval → Continue execution

4. Features of adk tool

1. Modular design concept
• Tools are designed as independent modular components (such as Python functions or agents) that interact with the core LLM through standardized interfaces.
• Supports synchronous/asynchronous tool calls, especially processing time-consuming tasks through Long Running Function Tools
1. Dynamic call mechanism
• Adopt intelligent function calling process: LLM first performs intent recognition → tool selection → parameter generation → execution → result integration
• Supports tool chain calling, the output of the previous tool can be used as the input of the subsequent tool
1. Context-awareness
• Provides rich runtime context via ToolContext:
• State management: support multi-level session state persistence (app/user/session level)
• Process control (EventActions): can skip summary, transfer to other Agents or terminate LoopAgent
• Authentication integration (auth_response): automatically handles authentication processes such as OAuth
• Data Service: Directly access Artifact Service storage files and call Memory Service to retrieve history
1. Multi-type tool support
• Built-in tools: Google Search, RAG and other common functions are available out of the box
• Custom Tools: Support developers to create Function Tools with clear functions
• Agent-as-Tool: Sub-Agent can be called as a dedicated tool
• Third-party integration: compatible with LangChain/CrewAI and other ecological tools
1. Developer-friendly design
• Emphasize the normative nature of tool definitions:
• Require clear function names (verb-noun structure)
• Type Hints
• Structured docstring (must include parameter descriptions and return value examples)
• It is recommended to return a dictionary containing the status field to clearly indicate the execution result.
• Automatically process non-dict return values ​​and encapsulate them into a standard format
1. Intelligent guidance mechanism
• LLM uses tool metadata (name/parameters/docstring) to make independent decisions about calling logic
• The tool function name can be directly referenced in the Agent instruction, and the calling conditions and exception handling strategies can be described in natural language.

These features enable ADK to ensure the standardization of tool calls while maintaining the flexibility of LLM drivers, making it suitable for building intelligent agent applications that require complex system interactions.

Features Classification	Core Competencies	Technical Implementation
Modular design	Tools are decoupled from LLM as independent components (Python functions/agents)	Support Function Tools, Agent-as-Tool, Long Running Tools
Dynamic call mechanism	LLM autonomous decision-making tool call process	Five-step process: intent identification → tool selection → parameter generation → execution → result integration
Context-aware	Get full context information when the tool is running	passToolContextProvides: • State (state management) • EventActions (process control) • Authentication/data services
Multi-type tool support	Covering ecosystem integration from built-in to third-party tools	Three types of tools: 1. Built-in tools (such as Google Search) 2. Custom Function Tools 3. Third-party tools (LangChain, etc.)
Development Specifications	Enforce standardized tool definitions to improve LLM call accuracy	Requirements: • Semantic function names (such as get_weather) • Type Hints • Structured docstrings
Intelligent Guidance	Control tool usage logic via natural language commands	In the Agent directive: • Specify the calling conditions (such as "when the user asks about the weather") • Define the error handling strategy (such as "retry if an error is returned")

Key benefits :

1. Balance between flexibility and standardization : maintain LLM's autonomous decision-making while constraining tool behavior through standardized interfaces
2. Full-link integration : a closed loop from tool definition, context management to result processing
3. Enterprise-level extension : support production environment requirements such as authentication and state persistence

Of course, it also supports the most popular mcp function

Summary of the core features of ADK calling MCP:

Features	illustrate
Separation of protocols and frameworks	MCP is a standardized communication protocol, and ADK is an AI development framework.MCPToolsetBridging for intercommunication
Bidirectional integration mode	1. ADK calls external MCP services as a client 2. ADK tools are exposed to other clients through MCP services
Dynamic tool discovery	ADK runtime dynamically obtains the tool list provided by the MCP server, without pre-hard-coding tool definitions
Asynchronous communication mechanism	The whole process is based on asynchronous IO (asyncio), and both tool calls and result returns are non-blocking operations.
Connection lifecycle management	MCP connections must be managed explicitly (viaexit_stack), to avoid resource leakage
Protocol conversion layer	Automatic conversion: - MCP tool description → ADK tool interface - ADK tool results → MCP response format
Hybrid deployment support	Supports local inter-process communication (stdio) and remote SSE connection modes
State retention	MCP sessions maintain a long connection state, which is different from stateless HTTP requests

Key implementation points:

1. Client mode : ADK throughMCPToolsetEncapsulates the following operations:

• Start/connect to the MCP service process (such asnpxRun Node.js service)
• Conversion tool interface (list_tools→BaseTool）
• Proxy tool call (call_toolForwarded to MCP service)

• Server mode : Need to implement by yourself:

• ADK tool to MCP description conversion (adk_to_mcp_tool_type）
• Call ADK tools and package the results (such as JSON serialization toTextContent）

Typical application scenarios:

• Quickly integrate existing MCP services (such as file operations/map API)
• Open ADK ecosystem tools to other AI systems that support MCP (such as Claude)

5. Full analysis of ADK framework deployment methods

1. Main deployment plan

Deployment	Technical Implementation	Target customers	Core Advantages
Fully managed service	Google Vertex AI Agent Engine	Google Cloud Deep User	Automatic expansion and reduction/no maintenance
Containerized Services	Google Cloud Run	Teams that need Serverless containers	Pay-as-you-go/Quick Start
Custom Containers	Docker + K8s/YARN	Hybrid Cloud/Non-Google Cloud Users	Fully autonomous and controllable
Local service	Built-in HTTP server	Development and debugging stage	Quick Verification

2. Real choice for non-Google cloud users

graph TD
    A[Agent built by ADK] --> B[Standard Docker image]
    B --> C{deployment target}
    C --> D [self-built K8s cluster]
    C --> E[Third-party container service]
    C --> F[edge device]

VI. ADK evaluation process and features

1. Operation process

graph TD
    A[Define evaluation objectives] --> B[Prepare test data]
    B --> C{Select evaluation method}
    C -->|Unit test| D[Create .test.json file]
    C -->|Integration test| E[Create .evalset.json file]
    D --> F [Run pytest/adk eval]
    E --> G[Run adk web/adk eval]
    F --> H[Generate evaluation report]
    G --> H

2. Operation characteristics

1. Two-dimensional evaluation system

2. Dynamic threshold configuration

{
  "criteria" : {
    "tool_trajectory_avg_score" :  0.9 ,
    "response_match_score" :  0.7
  }
}

3. Session state process

graph LR
    S[initial state] --> T1[user question 1]
    T1 --> A1 [Agent response 1]
    A1 --> T2[User Question 2]
    T2 --> A2 [Agent response 2]
    A2 --> F[Final Status Verification]

3. Business value analysis

1. Quality Assurance Matrix

2. Typical application scenarios

• Financial field : Verify whether the loan approval agent strictly follows the "credit inquiry → risk assessment → approval generation" process
• E-commerce field : Test the after-sales work order processing logic (such as the "paid but not shipped + more than 48 hours" scenario)

VII. Summary of AI Agent Security Framework

Google Cloud Vertex AI uses multi-layered protection mechanisms to ensure the security, reliability and brand alignment of AI Agents:

1. Core protection mechanism

2. Main risks and responses

3. Best Practices Charts

graph TD
    A[User input] --> B{Safety fence?}
    B -- Security --> C[Tool Call]
    B -- Intercept --> D[Return to default response]
    C --> E[Authentication]
    E --> F[Parameter check]
    F --> G[Execution: Sandbox/Least Privileges]
    G --> H[Output Filter]
    H --> I[Evaluation Log]

4. Key recommendations

• Principle of least privilege : Tools only expose necessary functions, throughtool_contextDynamic restrictions (such as allowing queries only to specific tables).
• Defense in depth : Combination of Gemini filter (content layer) + callback validation (logic layer) + network isolation (infrastructure layer).
• Cost optimization : High-frequency security checks use lightweight models (such as Gemini Flash Lite).
• Brand safety : Customize system instructions to prohibit discussion of competitors or content that deviates from the brand tone.

Through the above layered protection, a powerful and secure AI Agent system can be built.

8. Conclusion

Intuitive experience and comparison

adk compares frameworks such as crewai, agno, pocektflow, and langgraph

Crewai and Agno all have the concept of orchestration, but they prefer a multi-agent architecture. Pocketflow and Langraph both use graph engines as a means of orchestration.

CrewAI is more like building a complete set of operating mechanisms for companies and organizations. After trying out its tool set, I found that many of its internal tools use the adapter model to reference more mature tool libraries. However, this mechanism also has disadvantages because it is just a simple adapter.

Agno is very lightweight, much lighter than crewai. It also integrates toolsets such as rag, and also involves knowledge base, etc. In fact, it also has a simple webui inside, and in terms of performance tracking, it also integrates its own performance and debugging framework (it is turned on by default, and needs to be turned off through environment variables, which is quite hidden, so you need to pay attention to it)

I won't comment much on langraph, after all, I don't use it much and the documentation is quite complicated

Pocektflow is actually from the graph school, but it is absolutely lightweight. In fact, it is similar to adk in that it has the concepts of before, during, and after the agent. I think post processing is really important for LLM-type applications.

Its official website also summarizes many MAS (multi-agent design patterns)

These two pictures have summarized it very well, so I won’t say more.

Of course, Google's adk also has a corresponding summary of the involved patterns. In fact, the two can be combined and published in a separate article, agent design patterns

Agno's teams correspond to the MAS design model, which has three types:

Crewai also has the concept of teams, but I don’t really like Crewai because the code base is actually quite large.

AI’s final summary and suggestions for the above content

Based on a comprehensive analysis of the Google ADK framework and combined with the public information of the industry's mainstream frameworks, we can draw the following objective comparison:

ADK's core differentiated advantages

1. Enterprise-level engineering design

• The only tool chain that provides a full life cycle from development and debugging to production deployment (compared to LangChain/CrewAI, which focuses on the development phase)
• Built-in Vertex AI deep integration to support enterprise-level requirements: VPC-SC isolation, IAM permission control, audit logs, etc.

• Deterministic workflow (similar to PocketFlow’s DAG orchestration)
• Dynamic LLM routing (AutoGen-like dialogue coordination)

• Also supports:
• This is the essential difference from pure DAG frameworks (PocketFlow/LangGraph) or pure dialogue frameworks (AutoGen)

• Deep integration of Gemini series models, Vertex AI services, Google Search, etc.
• Provide MCP protocol support and other proprietary communication solutions (industry exclusive)

Objective comparison with mainstream frameworks

Typical application scenario suggestions

1. Preferred ADK scenario

• Enterprise applications that need to connect to Google Cloud services
• Strict security compliance requirements (such as finance, medical care)
• Hybrid workflow (preset process + dynamic decision-making)

• Rapid Prototyping → PocketFlow
• Multi-model research → AutoGen
• Non-Google Technology Stack → CrewAI

Observation of evolution trend

1. Signs of frame fusion

• CrewAI adds SequentialWorkflow (similar to ADK's SequentialAgent)
• PocketFlow adds LLM node support (similar to ADK's LlmAgent)

• Frameworks are borrowing core ideas from each other:

• Limited support for non-Google environments (e.g., cannot deploy directly to AWS/Azure)
• The openness of the tool ecosystem is weaker than that of community-driven frameworks such as LangChain

In summary, ADK represents the current engineering benchmark for enterprise-level AI agent development, and is particularly suitable for teams that use Google Cloud extensively. Its design philosophy is influencing the entire industry, but developers still need to make choices based on specific technology stacks and scenario requirements.