Found docs updates needed from ADK python release v2.7.1 to v2.8.0

[adk-bot]

Reference comparison: google/adk-python@v2.7.1...v2.8.0

Feature Changes

1. Global override for max_llm_calls

Doc file: docs/runtime/runconfig.md

Current state:

• max_llm_calls: Caps the total number of LLM calls per run (default: 500). Set to 0 or negative for unlimited calls, though this is not recommended for production. Values at or above sys.maxsize raises an error.

Proposed Change:

• max_llm_calls: Caps the total number of LLM calls per run (default: 500). This limit can be overridden globally by setting the ADK_MAX_LLM_CALLS environment variable. Set to 0 or negative for unlimited calls, though this is not recommended for production. Values at or above sys.maxsize raises an error.

Reasoning:
The v2.8.0 release introduces ADK_MAX_LLM_CALLS as a way to globally override the default max_llm_calls value, allowing users to configure limits dynamically.

Reference: src/google/adk/agents/run_config.py

2. Task mode and native auth for Remote A2A Agent

Doc file: docs/a2a/quickstart-consuming.md

Current state:

The main agent uses the RemoteA2aAgent class to consume the remote agent (prime_agent in our example). As you can see below, RemoteA2aAgent requires the name and an agent_card, which can be an AgentCard object, a URL (as in the example below), or a path to a local agent card file; the description field is optional and defaults to an empty string.

Proposed Change:

The main agent uses the RemoteA2aAgent class to consume the remote agent (prime_agent in our example). As you can see below, RemoteA2aAgent requires the name and an agent_card, which can be an AgentCard object, a URL (as in the example below), or a path to a local agent card file; the description field is optional and defaults to an empty string.

You can also pass authentication parameters (auth_scheme, auth_credential, and credential_key) to natively authenticate calls to the remote agent. Additionally, you can specify mode="task" to run the remote agent as a task sub-agent. In task mode, the sub-agent owns the conversation across multiple turns and only returns control when the remote A2A task reaches a terminal state via the finish_task tool.

Reasoning:
The v2.8.0 release adds support for Task mode delegation (mode="task") in Remote A2A Agents, allowing them to manage multiple turns until explicitly finished. It also adds built-in auth parameters (auth_scheme, auth_credential) to directly authenticate the agent rather than requiring custom httpx clients or interceptors.

Reference: src/google/adk/agents/remote_a2a_agent.py

3. Cloud Build private worker pool for Agent Engine deployment

Doc file: docs/deploy/agent-runtime/deploy.md

Current state:

For region, you can find a list of the supported regions on the
Agent Builder locations page.

Proposed Change:

For region, you can find a list of the supported regions on the
Agent Builder locations page.

If your organization uses VPC Service Controls (VPC-SC) or requires container builds to run on a private network, you can specify a private Cloud Build worker pool by adding the --worker_pool flag (e.g., --worker_pool=projects/MY_PROJECT/locations/MY_REGION/workerPools/MY_POOL). Alternatively, you can specify worker_pool or build_config.worker_pool in your .agent_engine_config.json file.

Reasoning:
The v2.8.0 release introduces support for Cloud Build private worker pools in Agent Engine deployments via the --worker_pool CLI flag and config file, enabling deployment in VPC-SC and private network environments.

Reference: src/google/adk/cli/cli_deploy.py

4. Native authentication resolution for Agent Registry

Doc file: docs/integrations/agent-registry.md

Current state:

Remote A2A Agents

If you are connecting to a Google A2A agent, you need to pass an
httpx.AsyncClient configured with Google authentication headers to the
get_remote_a2a_agent method.

Example:

import httpx
import google.auth
from google.auth.transport.requests import Request

class GoogleAuth(httpx.Auth):
    def __init__(self):
        self.creds, _ = google.auth.default()
    def auth_flow(self, request):
        if not self.creds.valid:
            self.creds.refresh(Request())
        request.headers["Authorization"] = f"Bearer {self.creds.token}"
        yield request

httpx_client = httpx.AsyncClient(auth=GoogleAuth(), timeout=httpx.Timeout(60.0))
remote_agent = registry.get_remote_a2a_agent(
    f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID",
    httpx_client=httpx_client,
)

Proposed Change:

Remote A2A Agents

Authentication for Google A2A agents is now automatically handled by the ADK. When you call get_remote_a2a_agent, the Agent Registry client automatically resolves the appropriate authentication provider scheme from the agent's IAM bindings, meaning you do not need to manually configure and pass an authenticated httpx.AsyncClient.

Example:

# Authentication is resolved automatically from the registry bindings.
remote_agent = registry.get_remote_a2a_agent(
    f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID"
)

If you need to override the automatically resolved authentication, you can pass custom auth_scheme and auth_credential parameters directly to get_remote_a2a_agent.

Reasoning:
Agent Registry's get_remote_a2a_agent was updated in v2.8.0 to automatically resolve the auth_scheme from the agent's IAM bindings via GcpAuthProviderScheme, leveraging the new native authentication capabilities of RemoteA2aAgent and eliminating the need to manually pass an authenticated httpx.AsyncClient.

Reference: src/google/adk/integrations/agent_registry/agent_registry.py

5. New Model Armor Integration

Doc file: docs/integrations/model-armor.md

Current state:

(New file)

Proposed Change:

Create a new documentation page for the Model Armor integration. It should document the ModelArmorPlugin and ModelArmorConfig. Detail that it screens user inputs (via prompt_template_name) and model outputs (via response_template_name) using Google Cloud Model Armor. Mention that it works in both unary (run_async) and live (run_live) modes using standard callbacks, and describe how to configure blocked messages (input_blocked_message, output_blocked_message) and failure behavior (block_on_screening_failure). Note the requirement to install google-adk[gcp] to use it.

Reasoning:
The v2.8.0 release introduces a brand new native integration plugin for Google Cloud Model Armor, adding powerful input/output safety guardrails, which currently lacks a dedicated documentation page.

Reference: src/google/adk/integrations/model_armor/_plugin.py

6. Context Caching for Anthropic Claude models

Doc file: docs/context/caching.md

Current state:

Context caching with Gemini

Supported in ADKPython v1.15.0Java v0.1.0Kotlin v0.7.0

When working with agents to complete tasks, you may want to reuse extended
instructions or large sets of data across multiple agent requests to a
generative AI model. Resending this data for each agent request is slow,
inefficient, and can be expensive. Using context caching features in generative
AI models can significantly speed up responses and lower the number of tokens
sent to the model for each request.

The ADK Context Caching feature allows you to cache request data with generative
AI models that support it, including Gemini 2.0 and higher models. This document
explains how to configure and use this feature.

Proposed Change:

Context caching

Supported in ADKPython v1.15.0Java v0.1.0Kotlin v0.7.0

When working with agents to complete tasks, you may want to reuse extended
instructions or large sets of data across multiple agent requests to a
generative AI model. Resending this data for each agent request is slow,
inefficient, and can be expensive. Using context caching features in generative
AI models can significantly speed up responses and lower the number of tokens
sent to the model for each request.

The ADK Context Caching feature allows you to cache request data with generative
AI models that support it, including Gemini 2.0 and higher models, as well as Anthropic Claude models (via Vertex AI or LiteLLM). For Claude models, caching utilizes Anthropic's ephemeral prompt caching mechanism through cache_control blocks. This document
explains how to configure and use this feature.

Reasoning:
The v2.8.0 release introduces support for context caching (ContextCacheConfig) for Anthropic Claude models, so the documentation should be updated to reflect that it is no longer exclusive to Gemini.

Reference: src/google/adk/models/anthropic_llm.py

7. Explicit memory_id support in Memory Bank

Doc file: docs/sessions/memory.md

Current state:

• Direct Creation (Default): By default, add_memory calls the underlying
  memories.create API. Each MemoryEntry you provide is added as a distinct,
  separate memory item.

Proposed Change:

• Direct Creation (Default): By default, add_memory calls the underlying
  memories.create API. Each MemoryEntry you provide is added as a distinct,
  separate memory item. If you set the id field on a MemoryEntry (or provide "memory_id" in custom_metadata), it will be used as the final component of the memory resource name instead of letting the service generate one.

Reasoning:
The v2.8.0 release introduces the ability to specify an explicit memory_id when calling add_memory to create Memory Bank entries with predictable resource names.

Reference: src/google/adk/memory/vertex_ai_memory_bank_service.py

8. Configurable API Version for Gemini/Vertex

Doc file: docs/agents/models/google-gemini.md

Current state:

Gemini Interactions API {#interactions-api}

Proposed Change:

Configure API Version

For the Vertex AI backend, the google-genai SDK defaults to v1beta1, which exposes the latest preview features. Production deployments that require a stable, SLA-eligible endpoint can override this default to use the GA Vertex AI API (v1).

You can set the API version explicitly on the Gemini model configuration using the api_version parameter:

from google.adk.models import Gemini

model = Gemini(model="gemini-2.5-pro", api_version="v1")

Alternatively, you can configure it globally by setting the GOOGLE_GENAI_API_VERSION environment variable (e.g., export GOOGLE_GENAI_API_VERSION="v1"). An API version embedded directly in the base_url path (e.g., a trailing /v1) takes precedence over both.

Gemini Interactions API {#interactions-api}

Reasoning:
The v2.8.0 release introduces explicit control over the Google GenAI SDK's API version via the api_version property on the Gemini class and the GOOGLE_GENAI_API_VERSION environment variable, enabling users to easily switch between v1 and v1beta1.

Reference: src/google/adk/models/google_llm.py

9. interaction_status flag for LlmResponse

Doc file: docs/live/dev-guide/part3.md

Current state:

| Text Events | Model's text responses when using response_modalities=["TEXT"]; includes partial, turn_complete, and interrupted flags for streaming UI management |

Proposed Change:

| Text Events | Model's text responses when using response_modalities=["TEXT"]; includes partial, turn_complete, interaction_status, and interrupted flags for streaming UI management. interaction_status is an Enum value (IN_PROGRESS or IDLE) indicating if the model is fully done responding to the user's prompt or will take multiple turns. |

Reasoning:
The v2.8.0 release introduces interaction_status to LlmResponse (and consequently Event), allowing developers to disambiguate whether turn_complete means the model is finished (IDLE) or will follow up with another turn (IN_PROGRESS).

Reference: src/google/adk/models/llm_response.py

10. Data Agent lifecycle management tools

Doc file: docs/integrations/data-agent.md

Current state:

• list_accessible_data_agents: Lists Data Agents you have permission to access in the configured GCP project.
• get_data_agent_info: Retrieves details about a specific Data Agent given its full resource name.
• ask_data_agent: Chats with a specific Data Agent using natural language.

Proposed Change:

• list_accessible_data_agents: Lists Data Agents you have permission to access in the configured GCP project.
• get_data_agent_info: Retrieves details about a specific Data Agent given its full resource name.
• ask_data_agent: Chats with a specific Data Agent using natural language.
• create_data_agent: Creates a new Data Agent.
• update_data_agent: Updates an existing Data Agent.
• delete_data_agent: Deletes a Data Agent.

Note: The modification tools (create_data_agent, update_data_agent, and delete_data_agent) are only available if enable_data_agent_modification is set to True in your DataAgentToolConfig.

Reasoning:
The v2.8.0 release introduces new Data Agent lifecycle management tools (create_data_agent, update_data_agent, delete_data_agent) which are gated by the enable_data_agent_modification configuration flag.

Reference: src/google/adk/tools/data_agent/data_agent_toolset.py

11. MCP tools list caching

Doc file: docs/tools-custom/mcp-tools.md

Current state:

5. Filtering (Optional): You can use the tool_filter parameter when creating an McpToolset to select a specific subset of tools from the MCP server, rather than exposing all of them to your agent.

Proposed Change:

5. Filtering (Optional): You can use the tool_filter parameter when creating an McpToolset to select a specific subset of tools from the MCP server, rather than exposing all of them to your agent.
6. Caching (Optional): You can set tool_list_cache_ttl_seconds to cache the tools list response from the MCP server for a specific duration, avoiding a network round-trip on every turn.

Reasoning:
The v2.8.0 release introduces tool_list_cache_ttl_seconds to McpToolset to cache the tools/list response, optimizing performance for remote MCP servers.

Reference: src/google/adk/tools/mcp_tool/mcp_toolset.py

Bug Fixes and Security Enhancements

12. Sub-agent limitation for EnterpriseWebSearchTool

Doc file: docs/tools/limitations.md

Current state:

!!! warning

Built-in tools cannot be used within a sub-agent, with the exception of
`GoogleSearchTool` and `VertexAiSearchTool` in ADK Python because of the
workaround mentioned above.

Proposed Change:

!!! warning

Built-in tools cannot be used alongside sub-agents (agent delegation), with the exception of
`GoogleSearchTool` and `VertexAiSearchTool` in ADK Python because of the
workaround mentioned above. Note that `EnterpriseWebSearchTool` does not support this workaround and cannot be combined with sub-agent delegation.

Reasoning:
ADK LLM Flow refactoring explicitly prevents EnterpriseWebSearchTool from being combined with sub-agent delegation since the Gemini API does not allow it and it doesn't support the bypass_multi_tools_limit workaround.

Reference: src/google/adk/flows/llm_flows/agent_transfer.py

13. Security redaction and restricted permissions for DebugLoggingPlugin

Doc file: docs/observability/logging.md

Current state:

Full debug capture to a file

Supported in ADKKotlin v0.6.0

To record the same activity in full, as YAML appended to adk_debug.yaml rather than truncated console output, use the DebugLoggingPlugin:

Proposed Change:

Full debug capture to a file

Supported in ADKPythonKotlin v0.6.0

To record the same activity in full, as YAML appended to adk_debug.yaml rather than truncated console output, use the DebugLoggingPlugin.

In Python, the DebugLoggingPlugin automatically redacts credential objects (such as AuthCredential), any state keys containing sensitive substrings (like api_key or password), and armored private keys. However, the output file still holds raw prompts and responses, so it is created with restricted 0o600 file permissions.

Reasoning:
The v2.8.0 release significantly enhances DebugLoggingPlugin security by automatically redacting sensitive credentials and enforcing 0o600 file permissions to prevent accidental exposure.

Reference: src/google/adk/plugins/debug_logging_plugin.py

14. Safe unpickling restriction for session migrations

Doc file: docs/sessions/session/migrate.md

Current state:

A migration script is provided to facilitate the migration process. The script
reads data from your existing database, converts it to the new format, and
writes it to a new database. You can run the migration using the ADK Command
Line Interface (CLI) migrate session command, as shown in the following examples:

Proposed Change:

A migration script is provided to facilitate the migration process. The script
reads data from your existing database, converts it to the new format, and
writes it to a new database. You can run the migration using the ADK Command
Line Interface (CLI) migrate session command, as shown in the following examples:

If your v0 database contains arbitrary Python objects (e.g., callables or custom classes) in its state, the migration will fail for security reasons because ADK now restricts unpickling to known types. To migrate a database you trust that contains such objects, add the --allow-unsafe-unpickling flag to your command.

Reasoning:
The v2.8.0 release introduces a restricted unpickler for legacy session state to prevent arbitrary code execution vulnerabilities. Session migration will now fail on databases containing arbitrary objects unless the user explicitly passes the new --allow-unsafe-unpickling flag to authorize reading them.

Reference: src/google/adk/sessions/migration/migrate_from_sqlalchemy_pickle.py

[saurabh4269]

I can open a PR for section 5 (Model Armor integration page): docs/integrations/model-armor.md adapted from the adk-python guide on main, plus a cross-link from docs/safety/index.md. The page will include install, configuration, regional endpoint notes, and the documented limitation that tool output is not screened.

If that scope matches what you had in mind for #2179, I will submit the PR shortly.