First-class Temporal integration for Google ADK

[IzuiT]

Is your feature request related to a problem? Please describe.
ADK apps can persist state (e.g., via SessionService) but not the execution itself. If the host dies mid-turn or a step fails transiently (rate limits, network outage, restarts), you lose in-flight progress and must re-run expensive steps. Teams are hand-wiring Temporal around ADK to get crash-safe, resumable execution, but each team rebuilds the same plumbing (retries, backoff, state handoff, observability), leading to inconsistent patterns and higher ops burden.

Describe the solution you'd like
A TemporalRootAgent (or equivalent) that starts a Temporal Workflow per ADK session/run and invokes ADK steps as Activities.

Describe alternatives you've considered

• Replace ADK’s Runner: Brittle; Runner is the core event engine and not intended to be swapped.
• Single coarse “run everything” Activity: Loses mid-flow retries and HITL gates; failures force full reruns.
• Orchestrating A2A-exposed agents from a Temporal workflow: Require to duplicate orchestration logic inside the agent and in the workflow, fragments observability.

Additional context
Temporal + OpenAI Agents integration announcement: https://temporal.io/blog/announcing-openai-agents-sdk-integration

[pinkponk]

I would be very much interested in this! We have implemented running ADK in Temporal. We took the easier: 1 session = 1 workflow, 1 invocation= 1 activity approach. Would be very good to have every step be an activity with native support from ADK+Temporal.

[hangfei]

We do support retries now.

If you want to do more integration, we suggest do it in adk-python-community. Moving this there.

[Jainish-S]

I’ve been thinking about this from different POVs. After iterating on the options like having a Temporal Runner directly into the framework or creating a separate package. I’ve concluded that flexibility is the most important factor here.

We shouldn't hardcode the state machine logic into the ADK core. Instead, I think the best design choice is to keep the integration at the Application Layer. This allows us to implement Temporal workflows specific to our own use cases without rigidly coupling the framework to one orchestration engine.

Here is the pattern I’m seeing that works best with the current ADK architecture:

For Tools (Durability): We can simply call the Temporal Workflow or Activity directly from within the function method itself. Since we already have LongRunningFunctionTool, this is a natural fit. The tool handles the "kick-off" and the Temporal backend handles the long-running durability and state management.

For Agents (Stateless): The RemoteA2aAgent is already there and provides exactly what we need to build stateless systems. We can treat Temporal workflows as remote agents behind an A2A interface, keeping the local runner lightweight and serverless friendly.

This composition over coupling approach preserves the flexibility for everyone to write their own Remote Tool Calls while still leveraging the power of Temporal where it counts.

Would like to know more if there are specific areas where this integration could be helpful.