Managed Agents: previous_interaction_id with reused remote MCP environment ends in opaque 500

Gemini API
1

Product/API: Gemini API Interactions, Managed Agents preview (agent model antigravity-preview-05-2026)

We are seeing a reproducible failure in a paid API project when combining documented server-side continuity with a reused managed-agent environment that has a remote MCP server.

Reproduction:

  1. Create a stored, background interaction for the managed agent with a remote environment and remote MCP definition. The first interaction completes successfully and returns an environment ID.
  2. Create a second stored, background interaction using the same agent, the same environment ID, the same remote MCP definition, and previous_interaction_id set to the first completed interaction ID.
  3. The create request is accepted and returns a background interaction ID.
  4. Polling that interaction later fails with a generic HTTP 500 / opaque background error.

Control:

  • The same second-turn request succeeds when we reuse the same environment, omit previous_interaction_id, and replay the complete visible transcript.
  • The remote MCP server and tool calls succeed on the first turn and in the replay control.

Expected:

  • The documented previous_interaction_id continuity contract works for Managed Agents with a reused remote MCP environment; or
  • the create request rejects an unsupported combination synchronously with an actionable 4xx error.

Impact:
We cannot use native server-side conversation continuity for managed agents that access a remote MCP server. We must replay the visible transcript while reusing only the environment, increasing request size and weakening parity with other hosted-agent runtimes.

Could Google confirm whether this combination is supported, expose a diagnostic error/request correlation for the background failure, and fix either execution or validation?

All project IDs, interaction IDs, environment IDs, MCP URLs, credentials, and customer payloads are intentionally omitted.

2

Thank you for flagging this, it does seem like a bug. We’ll work on a fix and provide updates here.

3

Hi again, we can’t reproduce the issue. Would you mind posting reproduction here or sending me a DM directly?

4

@Aleksander_Niebylsk1

  • We can’t repro this using your instructions above.
  • We have a suspicion it’s due to resurrecting interaction IDs where there was a previous failure.
  • But since we can’t reproduce using your exact instructions, we’re hesitant to fix that and call it done.

Can you provide a code sample to repro?