Agent Platform’s Sessions and Memory Bank services can store conversation state and longer-term memories for an ADK agent running on Cloud Run or GKE. The agent continues to run in your chosen environment while Agent Platform manages these two services.

This post covers the integration: create the backing resource, grant the runtime identity access, and pass the Sessions and Memory Bank URIs to the container. It assumes you already have a containerized ADK agent.

Create the Agent Platform resource

First, create the reasoningEngine resource that will provide Sessions and Memory Bank. Create an Agent Platform resource for Sessions and Memory Bank covers that process and prints the required environment variables:

export SESSION_SERVICE_URI=agentengine://projects/PROJECT/locations/REGION/reasoningEngines/ENGINE_ID
export MEMORY_SERVICE_URI=$SESSION_SERVICE_URI

Both services can use the same resource.

Authorize the runtime identity

The Cloud Run service or GKE pod needs a Google service account that can access the Agent Platform resource. The companion scripts grant roles/aiplatform.user at the project level. This is broader than access to a single resource, so review the role and binding scope against your production requirements.

Cloud Run

The companion Cloud Run deployment script creates a dedicated trading-agent service account and grants it roles/aiplatform.user. It then deploys the container with that identity.

The script reads the Alpaca credentials and both service URIs from the environment or the repository’s .env file. It exits before deployment if any value is absent. From the example repository, run:

cd 06_DeployToCloudRun
./deploy_cloudrun.sh

The deployment uses --no-allow-unauthenticated, so callers must authenticate. The example passes credentials as environment variables; for a production service, consider using Cloud Run’s Secret Manager integration for credentials.

GKE

Kubernetes ServiceAccounts identify workloads inside the cluster. Workload Identity Federation for GKE links a Kubernetes ServiceAccount to a Google service account, allowing selected pods to call Google Cloud APIs without a service-account key.

The companion Workload Identity script creates the trading-agent Google and Kubernetes service accounts, grants the Google service account roles/aiplatform.user, and connects the two identities. The deployment script runs that configuration automatically before applying the Kubernetes manifest.

Make sure kubectl points at the target cluster, then run:

cd 07_DeployToGKE
./deploy.sh

The script reads the Alpaca credentials and service URIs from the environment or .env, creates the trading-agent-secrets Kubernetes Secret, and applies deploy.yaml. The manifest selects the trading-agent Kubernetes ServiceAccount and imports the four values with envFrom.

GKE encrypts customer content at rest by default. For sensitive workloads, review access to Secrets and whether you need application-layer secrets encryption before using this pattern for production credentials.

Verify the integration

After deployment, create a session and send a second request using the same session ID. The second request should have access to the first exchange. If it does not, check the runtime identity, SESSION_SERVICE_URI, project, and region.

The URI alone does not create long-term memories. Your agent or client must also add a completed session or a specific memory to Memory Bank. Verify that separately by writing a memory, starting a new session for the same user, and confirming that the agent can retrieve it.

Clean up

When the test is complete, remove resources you no longer need: the Cloud Run service or GKE workload, Kubernetes Secret, IAM bindings, service accounts, and backing reasoningEngine. This prevents unused resources and project-level grants from remaining in place.