If you lead a platform or infrastructure team and are wiring agents into real systems on Google Cloud, Cloud Run’s documentation now covers a lot of the agent runtime. Here is how I’d work through it. Hosting an agent on Cloud Run is three separate decisions, made for each agent. The first is which resource type matches the agent’s loop. The second is where its untrusted tool code runs. The third is which identity it holds. Make the identity decision first, because the functional and identity types can’t be changed or unset once you set them on a resource.
Everything below comes from Google’s Cloud Run documentation. The agent hosting guide was last updated November 2, 2026, and the worker pool sandbox guide October 30, 2026. Several features are still beta or preview, so check their status before you commit.
Match the resource to the loop
Google’s guide to hosting AI agents on Cloud Run lists four resource types:
- Services: stateless, request-driven agents that handle variable traffic and can scale to zero, such as chatbot APIs.
- Instances: stateful, always-on singleton agent loops that need VM-like lifecycle commands.
- Worker pools: background agent fleets that pull tasks from queues such as Pub/Sub or Kafka and scale horizontally without a public HTTP endpoint.
- Jobs: run-to-completion work like batch evaluations or scheduled syncs.
I’d choose by how the agent’s control loop starts and stops, not by framework. Cloud Run supports ADK, LangGraph, Dify and n8n, among others, so the framework doesn’t narrow anything. If a user’s request starts the loop, use a service. If the loop starts from a queue, use a worker pool. The “no public endpoint” property of worker pools is the one I’d value most for agents that act on internal systems. A singleton that has to stay alive between interactions needs an instance. Use a job only when the work has a clear end.
Run tool code in a sandbox, not in the agent
An agent that writes and runs code, or drives a browser, shouldn’t do it inside its own process. Cloud Run sandboxes exist to keep that work separate. By default a sandbox can’t reach the parent workload, its environment variables, its secrets or the metadata server, and each sandbox is isolated from the others. Because it starts inside the existing instance, it comes up faster than a new Cloud Run resource for each task would. You enable it with the --sandbox-launcher flag and call the sandbox binary from your code.
The isolation is real, but it doesn’t add capacity. The worker pool sandbox guide says sandboxes share the host container’s CPU and memory, and that you need to size the container for your app plus every sandbox running at the same time. I’d cap how many sandboxes one worker can run at once and treat that cap as a capacity setting. Sandboxes are also ephemeral. If a multi-step task needs state between calls, export it with --export-tar or --sync-tar, or use bind mounts. Write that state somewhere other than /tmp, because the archives don’t capture /tmp.
As of the October 30 update, the worker pool commands still run under gcloud beta.
Give the agent its own identity, and decide it first
The Agent Platform features guide adds two properties to a Cloud Run resource: a functional type (agent or mcp-server) and an identity type (agent-identity or service-account). Once you set either one, you can’t change or unset it. A workload marked agent must use agent-identity. It then gets registered in Agent Registry and receives a system-managed identity tied to its lifecycle, with identity certificates on by default.
That rule about permanence is why I’d decide identity before anything else. For a real agent, I’d take agent-identity over a shared service account. The authentication guide shows each agent getting its own principal. You then grant IAM roles to that principal, such as roles/aiplatform.user for Vertex AI, and roles/run.invoker on any agent or MCP server it is allowed to call. That gives you a permission boundary for each agent instead of one boundary for everything that shares a service account.
The certificates add something useful. With mTLS-bound tokens, you can call Cloud Run resources set to ingress=internal, which keeps agents and MCP servers off the public internet without a VPC network. For agent-to-agent calls, I’d use bound tokens instead of the default unbound ones.
There is one gap to check. The features guide covers configuration on services and jobs. It doesn’t show worker pools. If your design pairs a queue-driven worker pool with sandboxes, confirm that agent identity is available for that resource type before you build around it.
When this doesn’t apply
This approach fits teams that already run on Cloud Run and want their agents inside the same IAM model. It fits less well if you need features that are still in beta or preview to be generally available before production. Sandbox launching on worker pools and sandboxes on instances are both in that category as of November 2026. It also fits less well if some agents need managed long-term memory or managed code execution from Agent Engine, which requires at least one Agent Engine instance alongside Cloud Run.
For each agent you plan to ship, write down how its loop starts, what untrusted code it runs, and which principal it should act as. Settle the principal first, since the functional and identity types can’t be changed on a resource once set. The resource type and the sandbox setup can follow from those answers.