Agent Engine Sessions and Cloud Run

Google Cloud Build with AI Agents
,
1

Considering ADK agents:

Deployment to Agent Engine Runtime
If I deploy my ADK agent directly to the Agent Engine Runtime, I can utilize Agent Engine Sessions out of the box. In this configuration, sessions are stored in and managed by the same Agent Engine resource that runs the agent. The agent deployed to the Runtime can also have a user-managed service account attached to it.

Deployment to Cloud Run
If I deploy my ADK agent to Cloud Run, I must explicitly provide a Session service. A supported implementation within the ADK is Agent Engine Sessions. To use this, I would first need to deploy a placeholder (or “empty”) agent to the Agent Engine Runtime. This Agent Engine resource then acts as the Session service for the Cloud Run deployment; I simply need to pass the ID of the Agent Engine resource to the agent running on Cloud Run. The Cloud Run service can also be deployed with a user-managed service account.

Assuming the above is a factually correct description of the two deployment models, I have the following questions:

  1. In the Cloud Run deployment scenario, should the “empty” Agent Engine Runtime instance (providing the Sessions) be deployed with its own user-managed service account, distinct from the service account used by the agent on Cloud Run? Additionally, what would the IAM bindings look like for the Cloud Run and Agent Engine Runtime service accounts in this architecture?

  2. In the standard Agent Engine Runtime deployment scenario (without Cloud Run), are there legitimate use cases for hosting the ADK agent on the Runtime while configuring Sessions to be provided by a separate, “empty” Agent Engine resource? This would mirror the architecture used in the Cloud Run scenario. It is unclear from the documentation whether agents deployed to the Agent Engine Runtime are restricted to using Session support only from their own hosting resource.

Thank you.

2 Likes
2

Hi @dml-oliver ,

based on a first conversation I had with the Vertex AI Agent Engine team, here are some insights:

Cloud Run Deployment (with “Empty” Agent Engine for Sessions)

No UMSA needed for the “Empty” Resource: The Agent Engine resource acts purely as a passive state backend (like a database). It does not need an identity to make outbound calls. The architecture relies on the Cloud Run Service Account having roles/aiplatform.user permissions on the target Agent Engine resource.

Runtime-to-Runtime Decoupling

Yes, this is a supported pattern. You can effectively decouples Compute (Runtime A) from State (Resource B). It is the recommended path for Blue/Green deployments (tearing down Runtime A doesn’t kill sessions) and Agent Swarms (multiple distinct Agents sharing a single conversation history/context).

Let me know if you have any further questions. I would be happy to follow up.

1 Like