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:
-
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?
-
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.