What Is Agent Runtime in GCP? Google's Managed Agent Host, Explained
Agent Runtime is Google Cloud's managed service for hosting AI agents, part of Gemini Enterprise Agent Platform. Until April 22, 2026 it was called Vertex AI Agent Engine. You deploy agent code from ADK, LangGraph, LangChain, or custom Python, and Google runs scaling, sessions, long-term memory, and tracing around it.
The name changed in April 2026
If you learned this product as Vertex AI Agent Engine, it is the same service under a new name. Google's release notes for April 22, 2026, the day of the Cloud Next '26 announcement, list Vertex AI as now part of Gemini Enterprise Agent Platform and map each old name to a new one: Vertex AI Agent Engine became Agent Runtime, Agent Builder Sessions became Agent Platform Sessions, and Memory Bank became Agent Platform Memory Bank. The console entry reads Agent Platform (formerly Vertex AI).
The transition is not finished in the documentation. Some pages say Agent Runtime, some say Agent Platform Runtime, and a June 2026 release note still refers to agents deployed on Agent Engine. Search for both names when you hit an error message or a code sample.
What Agent Runtime manages for you
Google's platform overview describes Agent Runtime as a high-performance, scalable runtime environment for deploying and managing agents, with sub-second cold starts and support for long-running agents, and calls it stateful. In practice, the split of responsibility looks like this.
You write: the agent itself. The model calls, prompts, tools, and control flow, in a framework or plain Python.
Google runs: the serving infrastructure and scaling, session state through Agent Platform Sessions, long-term recall across sessions through Memory Bank, and tracing. Since June 18, 2026, OpenTelemetry tracing is on by default for newly deployed Agent Development Kit agents.
Adjacent services you attach: Code Execution, which runs model-generated Python in a sandbox; Agent Identity, which gives each agent its own identity for access control and audit; and Agent Gateway, described as a central policy enforcement point for every tool call an agent makes.
Frameworks and deployment paths
Agent Runtime is not tied to Google's own framework. The docs have creation guides for Agent Development Kit, LangChain, LangGraph, AG2, LlamaIndex (in preview), Agent2Agent agents (in preview), and custom agents for anything else.
Google documents five ways to deploy. You can deploy an in-memory agent object, typically from a notebook. You can deploy from source files, Python only, without staging in Cloud Storage, which suits CI/CD and Terraform. You can deploy a prebuilt container image from Artifact Registry when you want control over the build, or build from a Dockerfile. And you can deploy from a Git repository connected through Developer Connect.
The container route is the one to choose if portability matters. An image that follows the runtime contract keeps the agent code independent of how it was packaged.
How it compares conceptually
Against running it yourself on Cloud Run or GKE
Any agent is ultimately a process, so you can containerise it and run it on Cloud Run or Kubernetes. What you give up is the agent-specific layer: managed sessions, Memory Bank, per-agent identity, and agent-aware tracing all become things you build and operate. Agent Runtime trades that work for dependence on Google's APIs and metering. Google's release notes say session and Memory Bank compute metering took effect on September 1, 2026, so check current pricing before you size a workload.
Against AWS
The closest AWS equivalent is Amazon Bedrock AgentCore Runtime, which also hosts framework-agnostic agent code and adds sessions, identity, and memory as separate services. AWS documents that each AgentCore session runs in a dedicated microVM. The two platforms are converging on the same shape: bring your own agent loop, and rent the runtime around it.
Against a harness
Agent Runtime does not decide how your agent prompts the model, which tools it offers, or how it manages context. That is the harness, and it remains your code. A runtime can make an unsafe action impossible by withholding credentials. It cannot make a wasteful agent efficient.
What it does not solve
A managed runtime hosts the loop; it does not supply the knowledge the loop needs. Agents that answer from internal documents still need retrieval, and agents that reread the same reference material on every session pay for it in tokens. Memory Bank recalls facts about users and past conversations; it is not a document index. Teams keep a separate retrieval layer, such as RDK over a private vault, with an 80 to 90 percent token reduction on repeated or reference-heavy work.
Frequently asked questions
- What is Agent Runtime in GCP?
- Agent Runtime is Google Cloud's managed service for deploying and operating AI agents, part of Gemini Enterprise Agent Platform. You bring agent code written with Agent Development Kit, LangGraph, LangChain, AG2, LlamaIndex, or plain Python, and Google runs it with scaling, session state, long-term memory, and tracing. It was called Vertex AI Agent Engine until April 2026.
- Is Vertex AI Agent Engine the same as Agent Runtime?
- Yes. Google's release notes for April 22, 2026 list Vertex AI Agent Engine as renamed to Agent Runtime, when Vertex AI became part of Gemini Enterprise Agent Platform. Sessions and Memory Bank were renamed at the same time. Some documentation and samples still use the older name, so search for both when troubleshooting.
- Do I have to use Google's Agent Development Kit?
- No. Google documents Agent Runtime guides for LangChain, LangGraph, AG2, LlamaIndex, Agent2Agent, and custom agents alongside Agent Development Kit. Deployment options include in-memory agent objects, Python source files, container images from Artifact Registry, Dockerfiles, and Git repositories through Developer Connect, so the framework choice stays yours.
- Should I use Agent Runtime or Cloud Run for an agent?
- Use Agent Runtime when you want managed sessions, memory, per-agent identity, and agent-aware tracing without building them. Use Cloud Run or GKE when you already operate containers, want full control over state and networking, or need to stay portable across clouds. The agent code can be the same; the difference is who operates the layer around it.