Gemini Enterprise Agent Platform: What Actually Ships in a Bank

I have spent the last few years putting agentic systems into production inside regulated institutions, and the pattern I keep seeing is the same: teams start with the model and end with the perimeter. In a bank, you have to invert that. On Google Cloud, the perimeter story is actually one of the strongest reasons to build there; but only if you understand the pieces and how they compose.

This is a field guide to Gemini Enterprise Agent Platform, the product family Google renamed from Vertex AI in July 2026. Existing bookmarks and several API resource names remain for compatibility, so architecture records should capture both the product label and the resource identifier.

The stack, from the bottom up

Gemini Enterprise Agent Platform is the umbrella for model serving, tuning, evaluation, pipelines and agent infrastructure. The agent stack centres on Gemini on Agent Platform, the Agent Development Kit (ADK) for code-first construction, Agent Runtime for deployment, Agent Platform Sessions for interaction state and Agent Platform Memory Bank for generated long-term memories.

The distinction between consumer and enterprise endpoints belongs in the first architecture review. Regulated workloads should use the Agent Platform endpoint and project controls selected for that journey. IAM, audit logging, location and VPC Service Controls must be verified for every service used; they are not inherited uniformly merely because products share a console family.

Model choice: gemini is the default, not the mandate

Use the currently approved Gemini model families as governed routing options rather than designing around one version label. A higher-capability tier may suit complex planning and synthesis, while lower-latency tiers may suit bounded work such as classification, routing, extraction and tool-argument generation. A measured task router should select the tier. In an illustrative capacity model, roughly four-fifths of calls could use the lower-latency tier because the assumed workload contains many bounded transformations. That mix is a planning hypothesis, not a deployment result or platform benchmark. The institution must derive its own routing table from task-level quality, latency and cost evidence.

Agent Platform also includes Model Garden, including third-party model families. For a bank, this matters less for model shopping and more for procurement leverage and exit strategy. A second family can use the same cloud commercial relationship, although its model-specific controls and terms still need review. Keep the model as a governed configuration choice rather than a hard dependency.

Agent platform and adk: pick your abstraction honestly

Google's managed agent tooling has changed names and capability boundaries quickly. Verify the current service matrix before committing. The parts I rely on are:

• ADK (Agent Development Kit): an open-source, code-first Python framework for defining agents, tools, and multi-agent hierarchies. This is where I build. You get real code, real tests, real version control, and you can run it locally before it goes anywhere near production.
• Agent Runtime: the managed deployment and scaling service, formerly called Agent Engine. Sessions and Memory Bank are associated services with their own locations, controls and billing rather than properties to assume from the runtime.
• Agent-to-agent patterns: Google has pushed the A2A protocol for inter-agent communication. In 2026 I treat it as promising and directionally correct, but I do not make my core transaction path depend on protocol-level interop between vendors. Internal multi-agent systems built on ADK's own sub-agent model are the conservative choice.

The honest trade-off: low-code agent configuration demos well and is fine for internal assistants with narrow scope. For anything customer-facing in a regulated flow, I want ADK, because auditors ask for the diff between what was reviewed and what is running, and code gives you that answer cleanly.

Grounding: agent search is the workhorse

Hallucination is not only a model problem in the enterprise; it is also a grounding problem. Agent Search, formerly Vertex AI Search, is the managed retrieval service used here. It supports ingestion, indexing and retrieval over selected sources, with citations carried into the response path. Access-control behaviour must be tested against the exact datastore and identity path.

Patterns that work in practice:

• Ground the agent's answer step, not its planning step. Retrieval noise in the planner degrades tool selection. Retrieve when you are composing the response the human sees.
• Use data stores per trust domain. Policy documents, product terms, and internal procedures have different owners, refresh cadences, and access rules. Separate data stores map cleanly to separate IAM bindings.
• Check ACL-aware retrieval requirements early. If different users may see different documents, document-level access control in retrieval is a hard requirement, not an enhancement: design for it on day one, and validate the identity propagation path from your app through to the data store.
• Keep citations in the payload. In a bank, "the model said so" is not an answer. "Clause 4.2 of the current product terms, retrieved at this timestamp" is.

For structured data, skip the temptation to vectorise everything. Gemini generating SQL against governed BigQuery views (with the agent's service account holding read access to exactly those views) beats embedding your data warehouse.

IAM and VPC-sc: the patterns banks actually approve

This is where GCP earns its place. The controls that get designs through risk review:

Service account per agent, per environment. Each agent runs as its own service account. Tools are IAM-scoped: the KYC-summary agent's identity can read the document store and nothing else. When an agent misbehaves, the blast radius is the IAM policy you wrote, not the platform's goodwill. Never let agents share a broad "AI platform" service account: that is the anti-pattern I unwind most often.

VPC Service Controls around supported services. Add the Agent Platform project and every supported data service to the perimeter before deploying Agent Runtime. The perimeter reduces exfiltration paths for protected Google-managed services. It is not a general firewall for unsupported products or arbitrary third-party traffic. Use explicit ingress and egress policy for documented exceptions.

Private connectivity. Use Private Google Access or the appropriate Private Service Connect pattern for the selected service. Private routing and VPC Service Controls solve related but different problems. Test DNS, endpoint and ingress behaviour from every calling environment.

CMEK where the service and location support it. Agent Runtime supports CMEK, VPC Service Controls and data residency for data at rest. Regional and multi-regional Sessions and Memory Bank support those controls, but their global endpoints cannot use CMEK. Example Store lacks VPC Service Controls, CMEK and at-rest data-residency support in Google's current matrix.

Audit logging as a first-class output. Cloud Audit Logs capture the API surface; your orchestration layer must capture the semantic layer: which tools were called, with what arguments, grounded on which documents. I ship every agent with a structured decision log to BigQuery from day one. Retrofitting observability into an agent system is miserable; do not.

Draw the deployment boundary at a business capability

A bank rarely needs one universal agent. It needs bounded capabilities such as policy interpretation, servicing preparation, case triage and payment investigation. Each capability should have its own runtime identity, tool set, evidence contract and release decision. A shared platform may provide libraries and controls, but it should not create a shared authority domain.

Start with a capability map. Mark which functions only retrieve information, which recommend, and which can change a record. Then mark the systems and data classes each function needs. This map reveals where one agent would acquire incompatible privileges. A policy assistant that reads all procedures should not inherit the servicing agent's ability to amend a case.

The model can still coordinate those capabilities through typed interfaces. It does not need their standing permissions. For an action, the policy service issues a narrow grant bound to the user, business object, action, amount or other material parameters, and a short expiry. The tool verifies the grant independently before it touches the system of record.

This separation supports change. A retrieval-only capability can adopt a new model after grounding evaluation without forcing a payment-control review. A tool adapter can change its API integration without reopening the model choice. Release scope should follow the authority that can change, not the repository that happens to contain the code.

Google's ADK documentation describes the code-first agent and tool abstractions. Those abstractions organise software. The institution's capability map supplies the business boundary that the framework cannot decide.

Resolve identity before the prompt is assembled

The user's identity should enter through an authenticated channel and remain outside model-editable text. Ingress resolves the person, device and journey context. An entitlement broker converts those facts into a signed scope. The runtime may show a human-readable summary to the model, but tools trust only the signed scope and their own policy decision.

Never ask the model to infer entitlement from conversational claims. A prompt such as “I am the relationship manager” is input, not identity evidence. Likewise, do not place broad cloud credentials in a tool and rely on instructions to limit their use. The tool's workload identity, the signed user scope and the policy grant should all be necessary.

Use separate service accounts by capability and environment. IAM Conditions can further restrict time, resource or request attributes where the service supports them. Google's IAM Conditions overview documents the mechanism. Conditions should make a permission narrower. They should not encode business policy that belongs in a versioned decision service.

Identity propagation needs negative tests. Change the claimed client identifier while retaining the same user token. Replay an expired action grant. Invoke the tool from another runtime identity. Attempt to use a production grant in a test environment. Retain the denials with policy and principal identifiers as release evidence.

Select location and optional services as one control decision

The platform name does not imply one security envelope. Runtime, Sessions, Memory Bank and Example Store have different feature support. The location choice also changes control availability. Architecture review must therefore approve a feature-location combination, not an abstract “Agent Platform” box.

Use an explicit decision record for every stateful feature. Record the data classes stored, retention, region, encryption control, perimeter status and fallback. Regional and multi-regional Sessions and Memory Bank can support VPC Service Controls, CMEK and at-rest residency. Their global endpoints cannot use CMEK. Example Store lacks those three controls in the current platform matrix.

The fallback should be designed before deployment. If Memory Bank does not fit the data classification, retain only short-lived session state and put governed long-term facts in an approved store. If Example Store cannot enter the required perimeter, use an evaluation dataset under BigQuery controls. Optional convenience should not silently determine the security architecture.

Recheck the matrix during upgrades. The official supported agent locations and Agent Runtime security matrix are living sources. Capture the reviewed date in the architecture decision and automate configuration checks where an organisation policy can express the rule.

Treat tools as products with evidence contracts

A tool schema is a control surface. It should expose the smallest business action, require typed parameters, validate them independently and return a structured result. A generic SQL, shell or HTTP tool transfers too much interpretation into the model. A get_case_status(case_id) tool makes the permitted operation inspectable.

Each tool should define five outcomes: success, business rejection, policy denial, dependency failure and indeterminate result. The model should not convert one into another. A timeout is not evidence that an action failed; it may have succeeded after the response was lost. Use idempotency keys and reconcile before retrying a material action.

Tool telemetry belongs in the decision ledger alongside model and retrieval events. Cloud Audit Logs show the call to a Google API. Application evidence should show the business operation, approved parameters and system-of-record outcome. Together they allow a reviewer to reconstruct both technical access and business effect.

Build release evidence by risk slice

An average pass rate hides the cases that matter. Define slices by journey, action, customer condition, language, document class, tool, model tier and failure type. Set hard gates for critical slices such as entitlement leakage, duplicate transactions and unsupported advice. A broader quality score cannot compensate for one breach.

The release set should combine deterministic tests, labelled scenarios, adversarial cases and shadow traffic. Deterministic tests cover schemas, policy and retries. Labelled scenarios test grounding and business judgement. Adversarial cases probe injection and authority. Shadow traffic measures latency and distribution shift without changing the user outcome.

Every promoted configuration should identify model, prompt, ADK package, tool schemas, policy bundle, retrieval index and feature locations. Those versions form one release manifest. If an incident occurs, the team can reconstruct the full system rather than asking which console setting was active.

Progressive traffic needs automatic stop conditions and a named operator. Useful signals include policy-denial shifts, tool error, evidence coverage, p95 latency, client correction and human override. A traffic ramp is not safe when a team watches an aggregate dashboard without predefined action.

Production readiness is an evidence state, not a date on a delivery plan. The architecture is ready when its controls have owners, its critical slices meet thresholds and its failure paths have been exercised. Gemini Enterprise Agent Platform supplies capable components. The bank still owns the system assembled from them.

Route models by task evidence, not prestige

Model routing should be a versioned decision table. Each orchestration step has a quality threshold, latency budget, context shape and consequence. Classification, extraction and schema-bound argument generation often suit a faster tier. Ambiguous planning or final synthesis may need a stronger tier. The boundary should come from evaluation rather than a general belief that one model is “good enough.”

Create a labelled set for each task family and compare candidate models on the same rubric. Include invalid inputs, long contexts, multilingual cases and abstention. Measure tool-argument validity separately from natural-language quality. A model can write an elegant explanation while repeatedly producing unusable dates or enum values.

Routing itself can fail. If a lightweight classifier sends a high-impact case to the wrong tier, the downstream quality gate may never run. Use deterministic rules for obvious high-impact actions and uncertain cases. The router should have an abstain outcome that selects the safer path. Retain the route reason and model version in the trace.

Cost models need complete journeys. Count routing, planning, retrieval enrichment, tool repair, final answer and evaluation calls. Add the human time created by exceptions and corrections. A cheaper call can raise total cost if it produces more retries. A stronger model can also waste money when a deterministic transform would suffice.

Review the route after model, prompt, tool or traffic changes. A task mix derived from one channel may not survive rollout to another. The unit of optimisation is a completed, acceptable business outcome, not a token or an isolated inference.

Design operational failure before scaling traffic

Agent systems fail as distributed systems. Model endpoints throttle, retrieval indexes lag, identity tokens expire and tools time out. Each dependency needs a timeout, retry rule, circuit breaker, fallback and ownership path. The model should not invent a workaround when infrastructure returns an indeterminate state.

Read-only queries can often retry with bounded exponential backoff. Material actions need idempotency and reconciliation first. If a payment instruction times out, query the source system with the idempotency key before resubmitting. If the state cannot be established, route to a human. “Try again” is not a safe default.

Grounded answers should fail according to evidence. If Agent Search is unavailable, the journey may offer a clearly labelled ungrounded draft to internal staff where policy permits. It should not present the draft as sourced advice. For a client channel, the safer response may be temporary unavailability or a deterministic link to the approved document.

Session and long-term memory failure also need separate responses. A lost session checkpoint may require the user to restate context. An unavailable Memory Bank should not block a transaction if long-term personalisation is optional. Classifying dependencies as essential, degradable or optional keeps a convenience feature from taking down the journey.

Run failure injection before production and during controlled resilience exercises. Expire credentials, deny perimeter access, corrupt a retrieval metadata field, delay a tool response and remove a model tier. Verify both user behaviour and evidence. A graceful response without a trace is not an acceptable test result.

Operate the platform as a control service

A platform team should provide paved roads rather than one central super-agent. The road includes approved ADK libraries, identity patterns, tool adapters, evidence schemas, policy integration, deployment templates and evaluation harnesses. Journey teams own business behaviour and outcomes. Central risk functions set minimum evidence and challenge the implementation.

The platform service catalogue should state what each component guarantees and what the journey must supply. Agent Runtime can host and scale code, but it does not decide business authority. Agent Search can return grounded candidates, but the team must validate corpus, access control and citation use. Sessions can retain interaction state, but the journey must set retention and location.

Shared libraries need versioning and compatibility policy. A security fix may require rapid adoption. A behavioural change should pass journey regression sets. Publish a support window and identify which runtime deployments use each version. This avoids an estate of frozen forks that no central team can secure.

Operations should review leading indicators, not only incidents. Track unsupported tool proposals, policy denials, indeterminate outcomes, evidence gaps, stale corpus items, human overrides and drift by slice. A rising denial rate may indicate an attack, a prompt regression or a legitimate change in demand. The metric triggers investigation; it does not decide the cause.

An executive view should connect these indicators to business outcomes. Report successful completion, safe abstention, correction, human effort, policy breach and unit cost by journey. Avoid a single “agent accuracy” number. It hides whether the system is useful, safe and economical for the cases that matter.

The mature platform therefore has two products. One is the technical runtime and toolchain. The other is the assurance system that makes every deployed capability inspectable, reversible and accountable. The second product is what allows the first to scale across a regulated institution.

What i would tell a cto in one paragraph

Build code-first on ADK and deploy on Agent Runtime. Use the Agent Platform endpoint and route model tiers from measured task evidence. Ground customer-facing answers with Agent Search only after validating identity propagation. Apply VPC Service Controls, service accounts, location policy and CMEK at the feature level rather than assuming one platform-wide setting.

The GCP agent stack is genuinely production-grade in 2026. The organisations struggling with it are not fighting the technology: they are discovering, late, that an agent is an identity, a network path, and an audit trail before it is a model. Design in that order and the rest follows.

A reference control plane

The runtime proposes; deterministic services authorise and execute. This boundary lets a team change models without reopening every business permission.

Current implementation details belong in the official Agent Runtime documentation, Agent Platform release notes, supported agent locations and VPC Service Controls guidance. A product feature is not a control until its configuration, owner and evidence are specified.