Gemini 3 function calls fail with missing thought_signature error after multiple tool uses

[haseryo0403]

Describe the bug

When using Gemini 3 models with ADK's native Gemini integration (not LiteLLM), complex tasks involving multiple tool calls fail with a 400 error stating that function calls are missing thought_signature.

Important: This issue occurs even when using Gemini(model="gemini-3-pro-preview") directly, not LiteLLM. As mentioned in #3627 (comment) , the recommendation is to use ADK's native Gemini integration to avoid thought_signature issues, but this error shows that native integration alone does not solve the problem.

To Reproduce

from google.adk import Agent
from google.adk.models.google_llm import Gemini

agent = Agent(
    name="search_agent",
    model=Gemini(model="gemini-3-pro-preview"), # Using native Gemini, not LiteLLM
    tools=[google_search_tool],
)

# Execute complex task requiring multiple tool calls
response = await agent.ask_stream(
    messages=[Message(role=MessageRole.USER, contents=[
        TextContent(text="Complex task requiring multiple searches")
    ])]
)

Error

400 Bad Request
{
  "error": {
    "code": 400,
    "message": "Unable to submit request because function call `default_api:google_search` in the 5. content block is missing a `thought_signature`. Learn more: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/thought-signatures",
    "status": "INVALID_ARGUMENT"
  }
}

The error occurs in the 5th content block after multiple tool invocations.

Expected behavior

ADK's native Gemini integration should automatically handle thought_signature requirements for function calling. Users should not need to manually manage this Gemini 3-specific requirement.

Environment

• OS: macOS
• Python version: 3.13
• ADK version: Latest
• Are you using LiteLLM: No (using native Gemini class)
• Model: gemini-3-pro-preview

Additional context

• Related: Cannot use Gemini 3 with litellm / vertex AI #3627 (comment) suggests using native Gemini integration, but this issue shows that's not sufficient.

[OhVIton]

👍

[Infinnerty]

Same issue... why is working with ADK so painful at times.

---

Environment:

• google-adk: 1.19.0 (also tested dev branch commit e6be5bc)
• google-genai: 1.52.0
• Model: gemini-3-pro-preview
• Endpoint: Vertex AI (global)

Description:
When using Gemini 3 with thinking enabled (ThinkingConfig(thinking_level="low", include_thoughts=True)),
multi-turn function calling fails after 5+ sequential tool calls with:

400 INVALID_ARGUMENT: function call default_api:get_fundamentals_data in the 8. content block
is missing a thought_signature

Reproduction:

1. Create an LlmAgent with Gemini 3 and thinking enabled
2. Give it tools that the model will call sequentially (e.g., fetching data for multiple tickers)
3. Send a query that triggers 5+ sequential function calls
4. Error occurs on the model call after the function responses

Expected:
ADK should preserve thought_signatures in conversation history when building subsequent LLM requests.

[surajksharma07]

@haseryo0403 Thanks for reporting this.

I've confirmed the issue - ADK isn't preserving thought_signatures when building conversation history for subsequent LLM calls (happens in src/google/adk/flows/llm_flows/contents.py:444).

As a temporary workaround, you can remove the planner=BuiltInPlanner(thinking_config=...) from your agent to avoid the error, though you'll lose thinking capabilities.

We'll look more into ADK's content processing to explicitly preserve thought_signature fields from model responses.

[surajksharma07]

@wyf7107 Please have a look into it.

[haseryo0403]

@haseryo0403 Thanks for reporting this.

I've confirmed the issue - ADK isn't preserving thought_signatures when building conversation history for subsequent LLM calls (happens in src/google/adk/flows/llm_flows/contents.py:444).

As a temporary workaround, you can remove the planner=BuiltInPlanner(thinking_config=...) from your agent to avoid the error, though you'll lose thinking capabilities.

We'll look more into ADK's content processing to explicitly preserve thought_signature fields from model responses.

@surajksharma07 @wyf7107

Thank you for identifying the root cause!

I tried removing the planner=BuiltInPlanner(thinking_config=...) from my agent as you suggested, but unfortunately I'm still getting the same error.

Is there anything else I should check or any other workaround I could try in the meantime?

Thank you for your continued support!

[surajksharma07]

@haseryo0403 Thanks for the update.

Since you're still seeing the error even without the planner, it seems Gemini 3 might be generating thought_signatures automatically.

Could you share your full agent setup code?
I'd like to check if thinking is being enabled elsewhere (via generate_content_config or model defaults).

Also, are you using the agent directly or through a Runner?
This will help us narrow down where the thought_signatures are coming from and why ADK isn't preserving them in your specific case.

[haseryo0403]

@surajksharma07

Current Configuration

1. Agent Setup

agent = Agent(
    name=app_name,
    description=self.DESCRIPTION,
    model=model,
    tools=tools,
    instruction=str(instruction) if instruction else RootAgentSystemPrompt.DEFAULT_INSTRUCTION,
)

return Runner(
    app_name=app_name,
    agent=agent,
    session_service=session_service,
    artifact_service=artifact_service,
)

NOT using planner=BuiltInPlanner(thinking_config=...)

2. Runner Configuration

events = runner.run_async(
    session_id=session.id,
    user_id=session.user_id,
    new_message=self.messages_to_adk_compatible_provider.to_single_content(
        new_user_messages, llm_model
    ),
    run_config=RunConfig(
        streaming_mode=StreamingMode.SSE,
        max_llm_calls=2500
    ),
)

No thinking configuration in RunConfig either.

3. Models Used

• gemini-3-pro-preview (GEMINI_30_PRO) ← Error occurs here
• gemini-2.5-pro
• gemini-2.5-flash

4. Additional Context

I do use ThinkingConfig(include_thoughts=False, thinking_budget=0) in two separate helper methods :

# In __function_call_to_tool_use method 
response = await client.models.generate_content(
    model='gemini-2.5-flash-lite',
    contents=prompt,
    config=GenerateContentConfig(
        thinking_config=ThinkingConfig(
            include_thoughts=False,
            thinking_budget=0
        ),
        response_mime_type='application/json',
        response_schema=ToolUseJsonSchema,
    ),
)

# In __function_response_to_tool_result method
response = await client.models.generate_content(
    model='gemini-2.5-flash-lite',
    contents=prompt,
    config=GenerateContentConfig(
        thinking_config=ThinkingConfig(
            include_thoughts=False,
            thinking_budget=0
        ),
        response_mime_type='application/json',
        response_schema=ToolResultJsonSchema,
    ),
)

However, these are separate generate_content calls for generating summaries, not part of the main agent conversation flow managed by the Runner.

---

Thank you for the continued investigation! I hope this information helps identify the cause.

[surajksharma07]

@haseryo0403 Thank you for the detailed config.

This clarifies things - you're not explicitly enabling thinking, but gemini-3-pro-preview appears to be generating thought_signatures by default (it's built into Gemini 3 models).

The separate ThinkingConfig calls you mentioned aren't related since they use a different model.

The core issue is that ADK's conversation history builder doesn't preserve thought_signatures regardless of whether thinking was explicitly requested or auto-enabled by the model.

We're investigating a fix to ensure these signatures are maintained across all function calls.
I'll keep you updated on progress.

[mark-lawrenson]

We ran into this as well and implemented a workaround in before_model_callback.

It seems ADK executes parallel tool calls sequentially, creating interleaved history:
model(fc) -> user(fr) -> model(fc) -> user(fr)

But Gemini expects them grouped:
model([fc, fc]) -> user([fr, fr])

We added logic in the callback to detect this interleaved pattern and merge the content blocks before sending to the LLM. This catches both in-memory turns and reloaded sessions.

Also worth checking if thought_signature is being preserved correctly if you're using a custom session store - we had to make sure the binary blob survived serialization.

[surajksharma07]

@mark-lawrenson Thanks for sharing that workaround.

The interleaved history pattern issue you mentioned is a great insight.

@haseryo0403 upgrading to v1.20.0 should help with thought_signature preservation (commits 31cfa3b, 632bf8b),
but if you still see issues with parallel tool calls, mark-lawrenson's before_model_callback approach to merge interleaved content blocks is worth trying.