Using Agent Platform Memory Bank and Sessions from other runtimes

3 min read

Did you know that Agent Platform offers a leading memory bank service, that can be used even if you’re deploying your agentic workload to GKE or Cloud Run? Memory Bank is a fully managed service that in addition to being able to save specific memories you give it, can review the entire session history and derive .

Memory Bank lets you make any agent a personal agent by automatically extracting pertinent information to build a profile of the user’s preferences.

Using it inside Agent Platform’s runtime is easy, no configuration is needed, you just need to instruct ADK to save the memory. Using it on GKE and Cloud Run is nearly as simple. You just need a resource identifier, a service account configured to access it, and to pass both those details when deploying. Here’s how.

Create the agent platform resource

To deploy, you need to first create a platform agent resource. Follow my post on creating the platform agent resource for instructions

Authorize the service account

Next, you simply need to authorize the service account that your agent runs under the ability to connect to the memory bank service. Why is this needed? Following the principle of least privilege, agents typically cannot access other services inside your Google Cloud project, rather you configure exactly what services are needed, in this case, Agent Platform.

Cloud Run

For cloud run, you first configure the service account.

# Dedicated service account (Google Service Account) for the Cloud Run deployment.
GSA="trading-agent"
GSA_EMAIL="${GSA}@${PROJECT_ID}.iam.gserviceaccount.com"

# --- Step 1: Service account + IAM ---
# Run the agent as a dedicated identity (not the default Compute SA) scoped to
# just Vertex AI, so it can reach the Agent Platform Sessions + Memory Bank.
echo "Configuring service account ${GSA_EMAIL}..."

# Create the runtime service account (ignore error if it already exists)
gcloud iam service-accounts create "$GSA" --project "$PROJECT_ID" 2>/dev/null || true

# Grant Vertex AI access (Sessions + Memory Bank)
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member "serviceAccount:${GSA_EMAIL}" \
  --role roles/aiplatform.user \
  --condition=NoneCode language: PHP (php)

Alternatively, you can update the default service account, though this isn’t recommended as it can result in over broad grants.

GKE

Kubernetes has it’s own Service Account identity, which somewhat mirrors Google Service Accounts. This allows you to grant access to pods in specific namespaces, not just the whole cluster.

To link the two systems, we use a system called Workload Identity, where you create a Google Service Account, and a Kubernetes Service Account, and link them.

#!/bin/bash
set -e

# project where GKE runs (and the reasoning engine lives)
PROJECT_ID="$(gcloud config get-value project 2>/dev/null)"
if [[ -z "$PROJECT_ID" || "$PROJECT_ID" == "(unset)" ]]; then
  echo "Error: no gcloud project configured. Run 'gcloud config set project PROJECT_ID'." >&2
  exit 1
fi

# Kubernetes namespace where the agent will be deployed
NAMESPACE="trading"

# Sets up Workload Identity so the trading-agent pod can authenticate to
# Vertex AI (the agentengine:// Sessions + Memory services) without keys.

GSA="trading-agent"               # Google service account
KSA="trading-agent"               # Kubernetes service account (matches deploy.yaml)
GSA_EMAIL="${GSA}@${PROJECT_ID}.iam.gserviceaccount.com"

# 0. Namespace (ignore error if it already exists)
kubectl create namespace "$NAMESPACE" 2>/dev/null || true

# 1. Create the Google service account (ignore error if it already exists)
gcloud iam service-accounts create "$GSA" --project "$PROJECT_ID" 2>/dev/null || true

# 2. Grant it Vertex AI access (Sessions + Memory)
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member "serviceAccount:${GSA_EMAIL}" \
  --role roles/aiplatform.user \
  --condition=None

# 3. Create the Kubernetes service account (ignore error if it already exists)
kubectl create serviceaccount "$KSA" --namespace "$NAMESPACE" 2>/dev/null || true

# 4. Let the KSA impersonate the GSA
gcloud iam service-accounts add-iam-policy-binding "$GSA_EMAIL" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${NAMESPACE}/${KSA}]" \
  --condition=None

# 5. Annotate the KSA to link it to the GSA
kubectl annotate serviceaccount "$KSA" --namespace "$NAMESPACE" \
  iam.gke.io/gcp-service-account="$GSA_EMAIL" --overwrite

echo ""
echo "Workload Identity configured for ${NAMESPACE}/${KSA} -> ${GSA_EMAIL}"

Deploy

With the Agent Platform resource created, and authorized, you now simply need to reference the memory and session URI in your configuration, whether on Cloud Run or GKE.

Set these variables using the resource ID of your agent platform resource.

Cloud Run

To configure the Sessions and Memory service, we need to make 2 additions to our Cloud Run deploy. Specify the service account that we created above, and the SESSION_SERVICE_URI and MEMORY_SERVICE_URIs

echo "Deploying to Cloud Run..."
gcloud run deploy "$SERVICE_NAME" \
  --source . \
  --region "$REGION" \
  --service-account "$GSA_EMAIL" \
  --set-env-vars "SESSION_SERVICE_URI=${SESSION_SERVICE_URI},MEMORY_SERVICE_URI=${MEMORY_SERVICE_URI},GOOGLE_GENAI_USE_VERTEXAI=TRUE,GOOGLE_CLOUD_PROJECT=${PROJECT_ID},GOOGLE_CLOUD_LOCATION=${REGION}," \
  --no-allow-unauthenticated

Code language: PHP (php)

GKE

Similarly, in GKE, we need to specify the Kubernetes Service account created above, and the environment variables set to the sessions and memory store.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: trading-agent
  namespace: trading
  labels:
    app: trading-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: trading-agent
  template:
    metadata:
      labels:
        app: trading-agent
    spec:
      # Workload Identity: this KSA must be bound to a GSA with roles/aiplatform.user
      # so the agentengine:// Sessions + Memory services can authenticate.
      serviceAccountName: trading-agent
      containers:
        - name: trading-agent
          image: us-west1-docker.pkg.dev/gke-autopilot-test/trading-agent/trading-agent/agent:v1
          ports:
            - containerPort: 8080
          # All env vars from docker-env.
          env:
            - name: GOOGLE_GENAI_USE_VERTEXAI
              value: "TRUE"
            - name: SESSION_SERVICE_URI
              value: agentengine://projects/213543088169/locations/us-west1/reasoningEngines/5365555170895724544
            - name: MEMORY_SERVICE_URI
              value: agentengine://projects/213543088169/locations/us-west1/reasoningEngines/5365555170895724544

Conclusion

With these simple steps, we can make any agent, including those deployed on Cloud Run or GKE into a personalized agent, taking advantage of Agent Platform’s fully managed memory store.