Agents on Google Cloud: Cloud Run, Cloud Run Jobs or Vertex AI Agent Engine
Google Cloud gives you three natural places to run an agent, and the choice follows the same logic as on AWS: how long a session runs, whether it needs accelerators, and how much of the runtime you want to operate. The model can be Gemini, Claude through Vertex AI’s Model Garden, or anything reachable over HTTPS. The runtime is a separate decision.
Cloud Run services: request-response agents
A container that serves HTTP, scales on concurrent requests, and can scale to zero. Requests can run for up to 60 minutes. Responses can stream, and a single instance can handle many concurrent requests, which suits agents: they spend most of their time waiting on a model API.
Use it for interactive agents where a session is a request, or a short series of requests with state kept in Firestore, Memorystore or Cloud SQL. Set concurrency deliberately. Defaults can vary by deployment method and configuration. Load-test the configured concurrency with your CPU, memory and downstream limits rather than treating a default as a capacity estimate.
Cloud Run jobs: batch and long-running work
A job runs containers to completion rather than serving requests. Tasks can run for up to 168 hours (seven days), with a lower limit of one hour for tasks using GPUs. A job can also fan out into many parallel tasks, each with its own index.
Use it for agent work that isn’t interactive: nightly triage of a backlog, a research job over a document set, or an evaluation run. The fan-out model suits evals in particular. One task per test case, results written to a bucket, and a final step that aggregates them.
Vertex AI Agent Engine: managed agent runtime
Agent Engine deploys agent code built with the Agent Development Kit or other supported frameworks, and runs it with managed sessions, memory and scaling. It’s Google’s counterpart to Bedrock AgentCore. Choose it when you want session handling and memory managed for you, and your framework is supported. Check current quotas, regions and pricing against a Cloud Run estimate before committing, because this is the fastest-changing of the three.
GPUs, if you self-host a model
Cloud Run supports GPUs on services and jobs (NVIDIA L4 with 24 GB, among others), with scale to zero. That makes it a reasonable way to serve a small open model for classification or extraction next to your agent, without running a GKE cluster. The cold start includes loading the model weights, so an interactive path needs minimum instances. This post covers whether self-hosting is worth it at all.
Choosing
| If the agent… | Start with |
|---|---|
| answers interactively within minutes | Cloud Run service |
| runs batch or long jobs, up to days | Cloud Run jobs |
| needs managed sessions and memory, on a supported framework | Vertex AI Agent Engine |
| serves a small self-hosted model | Cloud Run with GPU, minimum instances for interactive use |
The IAM detail that matters most
Every Cloud Run service or job runs as a service account, and that service account is what the agent’s code, and anyone who manipulates the agent, can use. Three rules:
Give each agent its own service account. Don’t use the Compute Engine default service account. In older projects it was automatically granted the broad Editor role. Newer organizations enforce the iam.automaticIamGrantsForDefaultServiceAccounts constraint to prevent that, but check yours. A dedicated account with only the roles the agent needs is the baseline.
Treat iam.serviceAccounts.actAs like AWS’s iam:PassRole. To deploy or configure a Cloud Run workload with service account X, the caller needs actAs on X (granted by roles/iam.serviceAccountUser). Invoking an existing job has separate run permissions; it does not generally require actAs merely because the job uses X. It’s the same escalation shape as PassRole. An orchestrator that can deploy or run workloads as any service account can run code as the most privileged one in the project. Grant roles/iam.serviceAccountUser on the specific service account, not at the project level, where it applies to every service account in the project.
Prefer invoking to deploying. An orchestrator that starts existing jobs needs run.jobs.run on those jobs, which is much less than permission to create or update them. Creating new workloads at runtime is where actAs comes in and where the risk is. Keep it out of agent roles unless the design really requires it.
For CI, use Workload Identity Federation instead of service account keys, so there are no long-lived keys to leak.
Where this stops
This covers where the loop runs and who it runs as. The rest (limits in code, idempotent tools, evals, logs of every action) is the same on any cloud, and the AWS-focused posts on this site carry over directly. The IAM skill linked below is written for AWS. The questions it asks (what can this role pass, launch or create, and what’s the worst case?) apply unchanged to service accounts.