Blog
Google ADK in 2026: Where It Fits in Gemini Enterprise Agent Platform
Google did not rebrand ADK. In April 2026, Google Cloud introduced Gemini Enterprise Agent Platform as the evolution of Vertex AI. The Agent Development Kit (ADK) kept its name and its role: it is the open-source, code-first framework for defining and orchestrating agents. Agent Platform is the broader managed environment around it.
That distinction sounds small, but it changes how I would design a system. ADK, Agent Runtime, Agent Platform and the Gemini Enterprise app solve different problems. Treating them as one product usually leads either to too much platform too early or to production responsibilities that nobody has explicitly owned.
This is the map I wish every architecture diagram started with.
The short version: four names, four jobs
| Name | What it is | The question it answers |
|---|---|---|
| Google ADK | An open-source, code-first agent framework | How do I define agents, tools, workflows and their execution logic? |
| Gemini Enterprise Agent Platform | Google Cloud's end-to-end platform for the agent lifecycle | How do I build, scale, govern and improve agents across an organization? |
| Agent Runtime | The managed hosting layer inside Agent Platform | Where does the deployed agent run, scale and expose a remote interface? |
| Gemini Enterprise app | The employee-facing surface for discovering, using and governing agents | How do people in the organization find and use approved agents? |
Google's own overview now lists ADK alongside Gemini Enterprise Agent Platform, the Gemini Enterprise app, Agent Garden, A2A and Cloud Run. That is the clearest signal that ADK is one building block in a portfolio, not the former name of the portfolio and not a product that disappeared. The Google Cloud AI-agent overview describes ADK as the open-source SDK for multi-agent orchestration, memory and developer tooling.
What Google actually renamed
The platform change is precise: Google calls Gemini Enterprise Agent Platform the evolution of Vertex AI. The new platform keeps model selection and model-building capabilities, then extends the lifecycle around agents with integration, orchestration, operations, security and governance.
ADK sits inside the Build side of that platform as the code-first option. The current Agent Platform architecture groups the stack into four concerns:
- Build: Agent Studio for low-code work, ADK for code-first orchestration, Agent Garden for samples, Model Garden for model choice, and MCP connectivity.
- Scale: Agent Runtime, sessions and Memory Bank.
- Govern: Agent Identity, the Registry and Agent Gateway.
- Optimize: evaluation plus Cloud Observability for traces, logs and metrics.
This is more than a label change, but it is not a reason to replace every mention of ADK. The accurate migration sentence is:
Existing ADK knowledge still applies to the framework. What changed is the name and scope of the managed Google Cloud platform around it.
Historical tutorials that deploy an ADK agent to a Vertex-named service may need updated commands, console paths or production guidance. Their explanation of agents, tools, callbacks and orchestration does not become conceptually invalid just because the platform boundary moved.
A useful architecture map
There are two entry points into the same ecosystem: people enter through an application; builders enter through a development platform.
Employees ───────────────► Gemini Enterprise app
│
│ discovers, runs and governs registered agents
▼
Builders ─► Gemini Enterprise Agent Platform
├─ Build: ADK | Agent Studio | Agent Garden | Model Garden
├─ Scale: Agent Runtime | Sessions | Memory Bank
├─ Govern: Agent Identity | Registry | Agent Gateway
└─ Optimize: Evaluation | Traces | Logs | Metrics
│
├─ deliver an agent into Gemini Enterprise
└─ expose it through your own product or API
The Gemini Enterprise app is not a framework. It is a secure surface where employees can discover and use Google-built, partner-built and custom agents. Google documents that teams can build custom agents with Agent Studio or ADK in Agent Platform and then govern them in the Gemini Enterprise app.
The Agent Platform is not limited to ADK. Its managed runtime also supports other frameworks and custom agents. ADK is the most direct Google-native code path, not a lock that forces every layer of the system to be Google-specific.
The runtime naming trap
The easiest technical mistake in this stack is assuming that ADK Runtime and Agent Runtime are the same thing. They are not.
ADK Runtime: the execution engine in the framework
Inside ADK, a Runner coordinates an event loop. It receives a user message, invokes agent logic, processes events, coordinates session and artifact services, commits state changes and yields output to the calling application. The ADK runtime documentation describes this yield, process and resume cycle in detail.
This runtime exists when you execute an ADK agent locally, in a container, on Cloud Run or on a managed agent service. It is part of how the framework runs your code.
Agent Runtime: the managed cloud service
Agent Runtime is the managed hosting environment inside Gemini Enterprise Agent Platform. It deploys and scales agents remotely and connects them to platform services such as sessions, long-term memory, identity and observability.
A compact way to remember the boundary:
ADK Runtime = how the agent loop executes
Agent Runtime = where Google Cloud hosts and operates the deployed agent
One can run inside the other. They should still be separate boxes in an architecture review because they have different failure modes, cost models and ownership.
Can you use ADK without Agent Platform?
Yes. ADK is designed to be deployable in several environments. Its current deployment guide documents Agent Runtime, Cloud Run, GKE and other container-capable infrastructure.
That leaves four sensible adoption patterns.
1. ADK locally or in your existing infrastructure
Use this when the main uncertainty is the agent itself: tool boundaries, orchestration, evaluation cases and whether an agent is even the right abstraction.
You keep infrastructure choices open and avoid adopting organization-level governance before the workload deserves it. You also own the production work: authentication, persistence, scaling, deployment, telemetry and incident response do not appear merely because the agent works in a local UI.
2. ADK on Cloud Run
Cloud Run is a strong fit when the agent behaves like a containerized application or service and your team already knows how to operate that model. It gives you a managed compute boundary without requiring the complete Agent Platform lifecycle.
The tradeoff is responsibility. You decide how sessions persist, how long-term memory works, how an agent authenticates to downstream systems, how traces are shaped and how versions are promoted. That can be exactly the control you want, or a growing list of platform work you did not intend to build.
3. ADK on Agent Runtime
Choose the managed agent runtime when agent-specific operations are becoming the problem: persistent sessions, managed memory, agent identity, deployment revisions, traces, evaluations or integration with other Agent Platform services.
The benefit is not that ADK suddenly becomes “production-ready” after deployment. Production readiness is a property of the whole system. The benefit is that several recurring operational capabilities become managed platform concerns with documented interfaces and controls.
4. Agent Platform plus the Gemini Enterprise app
Add the app layer when the goal is organizational distribution: approved agents need to be discoverable by employees, governed centrally and connected to enterprise data under the appropriate permissions.
This is a different decision from choosing ADK. A team can build an excellent ADK agent for its own product and never expose it in Gemini Enterprise. Another team may want the app as the main user experience and use ADK only for the custom logic behind one registered agent.
What should remain portable
I would keep the agent's business logic as independent as practical from its deployment destination. In concrete terms:
- Agent instructions, tool contracts and orchestration belong in the ADK application.
- Authentication and authorization belong at explicit trust boundaries, not hidden inside prompts or tool descriptions.
- Session state, durable memory and business records are different data classes; do not collapse them into one store because a platform offers all three.
- Evaluation cases should run before and after a deployment change. A green deployment says the service started, not that the agent still behaves correctly.
- Observability should preserve invocation, agent, model and tool-call boundaries so a trace can answer where time, tokens and failures went.
Portability does not mean pretending every runtime is identical. Agent Runtime, Cloud Run and GKE expose different operational contracts. It means the agent definition is not also your deployment script, identity policy, storage model and user interface.
A decision sequence that avoids platform-first architecture
When I review this stack, I use the decisions in this order:
- Is this actually an agentic workload? If a deterministic workflow can do the job, use it. A framework is not a reason to add model-driven decisions.
- What must the execution loop do? Define agents, tools, state transitions, human approvals and stop conditions in ADK or another suitable framework.
- What state must survive? Separate turn history, session state, long-term memory, artifacts and system-of-record data.
- What is the trust model? Identify the end user, the agent identity and each downstream permission. “The service account can access it” is not a complete authorization design.
- What operational work do we want to own? This is the real Cloud Run versus Agent Runtime question.
- Where will users consume the agent? Your product, an API, an event-driven process and the Gemini Enterprise app are different delivery surfaces.
- How will we know it still works? Define evals, traces, latency and cost boundaries before increasing autonomy.
This sequence keeps the platform proportional to the workload. It also makes migration less dramatic: moving from a container to a managed agent runtime changes an explicit operations layer, rather than forcing a rewrite of an application whose responsibilities were mixed from the start.
The practical answer
If someone asks “Should we use Google ADK or Gemini Enterprise Agent Platform?”, the question contains a category error.
- Use ADK when you need code-first control over agent behavior and orchestration.
- Use Agent Runtime when you want Google Cloud to operate the agent-specific hosting layer.
- Use the wider Agent Platform when lifecycle, governance and optimization need to work consistently across agents and teams.
- Use the Gemini Enterprise app when employees need a governed place to discover and run those agents.
You may need one layer, several layers or eventually all of them. The right architecture is not the one with the most Google product names in the diagram. It is the smallest one that makes execution, state, trust, operations and distribution explicit.
If that map is clear and the remaining question is how to turn it into a production architecture, I keep the implementation side separate on the Google ADK integration page. For the broader platform-choice question, the Google versus Anthropic agent-platform comparison covers the tradeoffs without declaring a universal winner.
Last technically reviewed: 3 August 2026. Product names and platform capabilities can change; the linked Google Cloud and ADK documentation is the source of truth for current availability.
Questions or a different architecture read? Reach me on LinkedIn or X.
Matteo Gazzurelli is a Fractional CTO and Agentic AI Consultant based in Brescia, Italy. With 25+ years in software development and multiple Google Cloud and AI certifications, he helps startups and SMBs implement multi-agent systems on Google (Gemini Enterprise Agent Platform + ADK) and Claude (Managed Agents, Code) — systems that work in production, not just in demos. Connect on LinkedIn or learn more at gazzurelli.com.