Google Cloud Opens Gemini Enterprise Agent Platform, but Control Is the Real Test

Google Cloud made several Gemini Enterprise capabilities generally available on July 29, only three months after introducing its expanded Agent Platform. The release moves persistent memory, seven-day execution, agent identity, governance, evaluation, and observability into broader production use. The conflict is clear: longer autonomy creates more value, but it also gives software more time and authority to make consequential mistakes.

This is not simply another collection of agent-building tools. Google is trying to supply the operating layer between an AI model and the enterprise systems it can change. That layer must preserve context, assign permissions, record actions, enforce policy, and measure outcomes across workflows lasting days.

Amazon and Microsoft are pursuing the same control point through Bedrock AgentCore and Microsoft Foundry. The contest is no longer centered only on which company offers the most capable model. It increasingly concerns which cloud can make autonomous work manageable enough for security teams, developers, and business owners to approve.

Google Cloud Turns Its Agent Preview Into a Production Platform

The release shifts Gemini Enterprise Agent Platform from an ambitious framework toward an operational system that businesses can deploy and govern.

Google introduced the current platform on April 22 as an evolution of Vertex AI. Its stated purpose was to combine model access, agent development, deployment, security, and optimization in one environment. The company also said future Vertex AI services and roadmap updates would arrive through Agent Platform, rather than as a separate product line.

Three months later, Google has made seven central capabilities broadly available. Agent Memory Bank preserves structured context across sessions. Agent Runtime supports asynchronous work lasting up to seven days. Agent Identity gives each agent a dedicated identity for access control and auditing.

Agent Gateway, Agent Registry, Agent Evaluation, and Agent Observability complete the control layer. Together, they manage tool connections, catalog deployed agents, measure behavior, and trace execution. Google describes these capabilities in its Agent Platform update, which frames the release around scaling agents securely.

The seven-day runtime is the most visible change. A conventional chatbot responds within a session, then waits for another request. A long-running agent can manage a sales sequence, monitor supply-chain conditions, or coordinate an onboarding process across several days.

That persistence changes the engineering problem. The agent needs durable state, recovery logic, permission boundaries, and a record of each action. A temporary model error becomes more serious when the same process continues operating after the user closes the application.

Memory Bank addresses part of that challenge by extracting selected facts into structured schemas. It can retain preferences, account history, and previous decisions without forcing the agent to reconstruct everything from a transcript. Google says this design supports lower-latency personalization across long-running work.

The distinction between stored memory and raw conversation history matters. A transcript contains everything said, including irrelevant details and outdated instructions. Structured memory selects information intended to remain useful. However, that selection process also creates a new failure point because the system can save an incorrect inference.

Google is therefore selling runtime and memory as a pair. The runtime keeps work alive, while Memory Bank keeps its context available. Neither feature independently makes an agent dependable, but together they let developers attempt workflows that exceed a single request.

The release also expands the platform’s scope beyond agents built entirely with Google models. At launch, Google said Model Garden offered access to more than 200 first-party, third-party, and open models. That choice suggests the company wants to control deployment and governance even when customers select another provider’s model.

That strategy makes Agent Platform more significant than a Gemini distribution channel. Google is positioning it as infrastructure for heterogeneous agent fleets. The platform succeeds if organizations treat its identity, registry, gateway, and monitoring services as shared controls across those fleets.

Why Google Cloud Is Competing on Agent Control

Enterprise buyers are becoming less constrained by model availability and more constrained by the operational risk surrounding agent actions.

A prototype agent can work with a narrow dataset and a few tools. Production agents encounter customer records, internal applications, credentials, approval chains, and compliance requirements. Each added connection expands both the agent’s usefulness and its potential blast radius.

Google Cloud is responding with an identity model designed specifically for agents. Agent Identity is a native identity and access management type, not merely a reused service account. Google says it binds access to the runtime, applies least-privilege permissions, manages the identity lifecycle, and produces non-repudiable audit records.

Least privilege means granting only the access required for a defined task. The idea is familiar, but agents make implementation harder. Their plans can change during execution, and they can call several tools while pursuing one broad objective.

Traditional service accounts often remain active after an application changes or disappears. Permissions can accumulate as teams add integrations. Best Buy described orphaned accounts, unclear ownership, and expanding permissions as recurring problems in Google’s announcement.

A dedicated agent identity creates a clearer unit of accountability. Administrators can ask which agent acted, what it accessed, who owns it, and which runtime authorized the action. That visibility becomes essential when an agent makes decisions without a person approving every step.

Agent Gateway sits at the next boundary. It centralizes interactions between agents, models, and tools. Administrators can apply identity conditions and natural-language rules while Model Armor inspects traffic for prompt injection, tool poisoning, and data leakage.

Prompt injection occurs when hostile or untrusted content manipulates an agent’s instructions. Tool poisoning involves a compromised tool description or response that changes the agent’s behavior. Both attacks become more consequential when the agent can access files, send messages, update records, or modify software.

Agent Registry addresses a different problem: organizational sprawl. It provides a catalog of agents, servers, and connections across a company. Teams can discover existing components, while administrators can identify ownership and monitor deployments.

A registry does not automatically stop duplicate or unsafe agents. Its immediate contribution is visibility. An organization cannot enforce consistent controls over software that its central teams do not know exists.

Google’s timing reflects the widening distance between pilot projects and governed production systems. Many teams can assemble a useful agent with a model, a prompt, and several APIs. Fewer have common systems for identity, memory, evaluation, and incident investigation.

This gap pressures cloud providers because customers prefer operational controls that integrate with existing infrastructure. Identity policies, logging systems, network controls, and data services already reside in the cloud environment. An agent platform becomes more attractive when it can reuse those foundations.

The same dynamic pressures independent agent frameworks. Open frameworks can give developers portability and flexibility, but enterprise teams still need a runtime and governance plane. Google supports open standards and its Agent Development Kit, yet the managed operational layer encourages deeper use of its cloud.

The strategic prize is therefore larger than model consumption. The winning platform can become the default place where companies register agents, grant authority, inspect traces, and judge performance. Once those controls surround a workload, moving it becomes more complicated.

The Mechanism Connecting Memory, Identity, and Evaluation

Google’s central bet is that autonomous agents become manageable when execution, authority, context, and measurement share one control plane.

Agent Runtime provides the execution environment. Memory Bank maintains selected context. Agent Identity determines who the system treats as the actor. Agent Gateway governs access to models and tools, while Registry records what has been deployed.

Evaluation and Observability close the loop. Observability records what the agent did, including reasoning traces, tool use, latency, and execution behavior. Evaluation asks whether the result met an expected standard.

Google combines both functions on one engine. Developers can use the same measurement logic during construction and after deployment. The company says evaluation options include predefined metrics, custom Python functions, model-based judges, and adaptive rubrics developed with Google DeepMind.

That continuity matters because offline benchmarks often fail to represent live conditions. A test dataset cannot anticipate every customer request, changing tool response, or permission state. Online evaluation can identify performance degradation and behavioral drift after release.

Behavioral drift means an agent’s results change over time, even when its stated purpose remains constant. A model update, revised prompt, new data source, or modified tool can cause that shift. Continuous monitoring helps teams locate when the change began.

However, evaluation does not eliminate subjective judgment. A model-based judge can inherit biases or weaknesses from the model performing the assessment. A custom metric can optimize for an easily measured proxy while missing the business outcome that matters.

Production teams still need explicit success criteria. A customer-support agent might be measured on resolution quality, policy compliance, escalation accuracy, and customer effort. Focusing only on response speed could reward confident but incorrect answers.

The integrated architecture becomes more useful when an evaluation can trigger operational action. A declining score might reduce an agent’s permissions, route work to a human, or halt a workflow. Google’s announcement describes monitoring capabilities, but customers must still design appropriate intervention policies.

AT&T offers a concrete memory example. The company says its sales agents use Memory Bank to synthesize facts from earlier customer interactions, allowing conversations to resume after a gap. It is also working toward continuity across app, voice, and web channels.

That case illustrates both the benefit and the risk. Remembered context can prevent customers from repeating information. Incorrect or overly broad memory can also propagate across channels and influence later decisions.

Commerzbank presents the governance side. The bank says it is evaluating Agent Registry and Agent Gateway for discoverability, policy enforcement, access management, observability, and auditing. Its interest shows why a centralized layer appeals to regulated organizations.

WellSky says it uses a centralized registry to catalog, version, and manage agents across their lifecycle. The company links that catalog to compliance policies and production approval. This is closer to software asset management than a consumer-facing AI feature.

CodeMender extends the same mechanism into software security. Google describes it as a managed agent that finds, verifies, and proposes fixes for code vulnerabilities. Core reasoning runs in the cloud, while compilation, tests, and exploit simulations run in customer-managed sandboxes or isolated virtual machines.

The CodeMender design retains a human approval point. Developers receive proposed changes as local diffs, and the agent does not directly commit them to production repositories. Google also says customer code is not used to train its foundation models.

That boundary is instructive. CodeMender automates analysis and patch creation, but it does not remove developer responsibility. The human review step limits autonomy exactly where an incorrect change could create a new vulnerability or disrupt production.

Knowledge-intensive agents need similar boundaries. Teams can use a searchable knowledge base to organize internal evidence, yet retrieval alone does not authorize an agent to act. Context, permission, and verification remain separate design decisions.

AWS and Microsoft Are Building the Same Control Layer

Google’s feature set is differentiated by integration, not by an uncontested category, because its largest cloud rivals now offer comparable agent infrastructure.

Amazon Bedrock AgentCore separates the agent’s logic from its managed infrastructure. Its Runtime provides isolation, scaling, sessions, authentication gates, and observability plumbing. Developers retain control of the orchestration loop and can connect Memory, Gateway, Identity, and other services.

The AgentCore runtime can host code written with different frameworks. That approach appeals to teams that want managed infrastructure without adopting a single agent framework. It also makes Amazon’s competitive response directly comparable to Google’s platform.

AWS offers a specialized identity and credential service for automated workloads. According to its identity documentation, AgentCore Identity supports authentication, authorization, third-party credentials, and audit trails. Its workload identities follow established identity patterns while adding agent-specific attributes.

Microsoft Foundry Agent Service also combines runtime, orchestration, identity, safety, and observability. Its managed runtime can isolate sessions, while Microsoft Entra supplies identity and role-based access control. Application Insights supports traces and production monitoring.

Microsoft has an additional distribution advantage through Microsoft 365 and Copilot. An organization already using Entra, Teams, SharePoint, and Microsoft 365 can view Foundry as an extension of its existing work environment. Google can make a parallel argument through Google Workspace and its cloud data products.

Microsoft also lets customers register some externally hosted agents for observability and evaluation. Its external agent controls use OpenTelemetry traces, allowing Foundry to monitor an agent without hosting or invoking its runtime. Several related capabilities remain in preview, including human evaluation and red-team scans for external agents.

The three platforms therefore reflect different versions of the same thesis. Enterprise agents require managed execution, persistent context, identity, tool governance, and monitoring. The clouds want those services to become the standard foundation beneath every agent.

Google’s advantage is the coherence of its newly available stack. Runtime, Memory Bank, Identity, Gateway, Registry, Evaluation, and Observability share one product umbrella. Gemini Enterprise can also distribute agents to employees through a controlled application.

Its challenge is proving that a unified stack produces better operational outcomes. Similar feature names do not establish superior reliability. Customers will judge integration quality, policy precision, incident response, regional availability, framework support, and the effort required to operate each system.

Portability remains another open issue. Google says Agent Platform supports third-party models and open standards. Yet an agent built around its identity type, memory schemas, registry, evaluation engine, and gateway policies could become expensive to move.

AWS and Microsoft create comparable dependencies. Their managed services reduce engineering work by making platform-specific choices for the customer. That tradeoff is common in cloud computing, but autonomous agents raise the stakes because governance data and behavioral history also become tied to the provider.

Enterprises should therefore distinguish model portability from operational portability. Switching the model behind an agent may require a configuration change. Moving its identity history, persistent memory, evaluation records, gateway policies, and audit trails is a larger migration.

The competition will not be settled by the longest feature list. It will turn on whether a platform reduces the work needed to pass security review and sustain reliable production behavior. Those results require evidence beyond launch announcements.

The Unresolved Risk Is Whether Governance Can Keep Pace

Agent controls reduce known risks, but longer runtimes and broader tool access create failure modes that dashboards cannot automatically resolve.

A seven-day agent has more opportunities to encounter stale data, conflicting instructions, expired credentials, and unexpected tool behavior. It can also compound an early mistake through later decisions. The runtime’s duration is therefore a capability and a risk multiplier.

Persistent memory creates another tension. Personalization improves when an agent remembers preferences and past decisions. Governance becomes harder when teams must decide what the system should extract, how long it should retain that information, and how users can correct it.

Structured schemas offer discipline, but schema design is a policy choice. A sales agent may need an account’s product interests without retaining sensitive personal details. An internal agent may need project decisions without treating every speculative comment as settled fact.

Agent Identity can show which software actor performed an action. That does not necessarily explain why the action occurred. A full investigation may require the agent’s instructions, model version, retrieved context, tool responses, memory state, policy decisions, and evaluation results.

Observability can collect much of that evidence. Logging everything, however, introduces privacy and storage concerns. Detailed reasoning traces can contain customer information, confidential documents, or sensitive tool outputs.

Teams must decide which traces are safe to retain and who can inspect them. They also need retention periods and redaction policies that align with their legal obligations. Centralization helps enforce those choices, but it does not make the choices straightforward.

Natural-language gateway rules deserve similar scrutiny. They make policies easier to express, yet security controls must behave predictably under adversarial conditions. Organizations should test whether equivalent requests receive consistent decisions and whether policy conflicts fail safely.

Google says Model Armor helps defend against prompt injection, tool poisoning, and data leakage. Those protections should be treated as controls within a layered system, not proof that an agent is safe. No filter can anticipate every malicious instruction or compromised integration.

Customer statements in Google’s announcement are encouraging but limited. They describe selected deployments and evaluations rather than independent, comparative measurements. The update does not provide a platform-wide error rate, a security incident rate, or a quantified reduction in operational effort.

That absence is understandable for a newly available product. It also means buyers should avoid treating general availability as evidence of mature performance across every workload. The strongest validation will come from sustained production use under measurable controls.

Human review remains necessary for high-impact actions. CodeMender demonstrates this principle by requiring developers to approve patches. Financial transfers, account closures, production changes, and legally significant communications deserve similarly explicit boundaries.

The appropriate level of autonomy depends on reversibility. An agent can receive more freedom when an action is easy to inspect and undo. Irreversible or externally visible decisions require narrower permissions, stronger evaluation, and dependable escalation.

Companies also need ownership outside the platform team. Security staff can define access rules, while business owners define acceptable outcomes. Legal and privacy teams determine which information can enter memory or logs.

Without shared ownership, Agent Registry risks becoming a catalog of systems nobody actively governs. Evaluation dashboards can produce scores without a response process. Identity records can establish attribution after an incident without preventing the incident.

Google has assembled the components needed for a credible control plane. The remaining question is whether organizations can convert those components into enforceable operating practices. Technology can expose a decision, but accountability still belongs to people.

What to Watch After the Gemini Enterprise Expansion

The next stage will be measured through real adoption, verified governance outcomes, and competitive responses rather than additional agent demonstrations.

The first signal is production evidence for seven-day workflows. Customers should document completion rates, intervention frequency, recovery behavior, and the number of failures that compound across multiple steps. Reliable long-duration performance would strengthen Google’s claim that Agent Runtime moves beyond short chat sessions.

Weak completion rates would point in the opposite direction. They would suggest that persistent execution is arriving faster than planning reliability. The important measure is not whether an agent remains active for seven days, but whether it completes useful work within defined limits.

The second signal is how Agent Identity and Gateway perform during audits and incidents. Enterprises need evidence that permissions remain narrow, credential lifecycles close correctly, and investigators can reconstruct consequential actions. Successful reviews in finance, healthcare, and telecommunications would support Google’s governance argument.

Security teams should also examine prevented events, not only successful deployments. Useful disclosures would include blocked injection attempts, denied tool calls, policy conflicts, and the time required to identify a misbehaving agent. Aggregate reporting could help buyers compare controls without exposing customer details.

The third signal is the response from AWS and Microsoft. Both already offer runtime, identity, memory, gateway, and observability services. Their next releases will show whether Google has established a meaningful lead or merely matched an emerging cloud baseline.

Framework and telemetry portability will be especially important. Microsoft’s support for externally hosted agent traces provides one approach. AWS emphasizes framework flexibility within its managed runtime. Google must show that its unified experience does not require customers to surrender practical choice.

Buyers should test each platform with the same representative workflow. That test should include a long-running task, a permission change, an injected instruction, a failed tool, a memory correction, and an evaluation regression. Feature checklists cannot reveal how the full system behaves under pressure.

Developers should also ask whether the platform makes failures understandable. A trace is useful only when it connects an outcome to the responsible instruction, context, tool, policy, and model. More telemetry can increase confusion if the system does not organize those relationships.

Knowledge workers have a related concern. Persistent agents will increasingly act on notes, documents, meetings, and historical decisions. A personal AI workflow can help organize that context, but enterprise action requires explicit permission and review.

Google Cloud has now placed its main agent controls into general availability. That is a meaningful product transition, not proof that autonomous enterprise work has been solved. The platform’s real test begins when agents operate for days, cross system boundaries, and encounter conditions their builders did not predict.

Ask one practical question before expanding an agent’s authority: can your team reconstruct, stop, and safely reverse its most damaging plausible action? If the answer is uncertain, use the new controls to narrow the workflow first. General availability makes broader deployment possible. Evidence, ownership, and disciplined limits must make it responsible.