Cloud / Gemini Enterprise Agent Platform Interview questions

Gemini Enterprise Agent Platform is Google Cloud's platform for building, scaling, governing and optimizing AI agents. Google announced it on April 22, 2026 at Cloud Next '26 as the evolution of Vertex AI.

It keeps what Vertex AI customers already relied on (model selection, model building and agent building) and adds new capabilities for agent integration, DevOps, orchestration and security. Vertex AI services and roadmap items are now delivered through Agent Platform instead of as a standalone service.

Teams can build with low-code Agent Studio or code-first ADK, run agents on Agent Runtime, and control them with identity, registry, gateway and evaluation tools. Agents built here can also be surfaced in the Gemini Enterprise app.

The platform is organized around four pillars: Build, Scale, Govern and Optimize. Each pillar covers one stage of an agent's life, from first prototype to continuous improvement in production.

In an interview, tie any feature you mention back to its pillar. It shows you understand the lifecycle rather than a list of product names.

The Gemini Enterprise app is the employee-facing front door to AI at work. It offers permissions-aware search across connected systems such as Confluence, Jira, SharePoint and ServiceNow, an AI assistant, and a place to run agents.

It is built on Agent Platform, so identity, security and governance come standard. Any agent a technical team builds on Agent Platform can be surfaced in the app for employees, and partner-built agents from the Agent Marketplace appear in an Agent Gallery. An Inbox gives IT and users one place to manage agents at scale, including long-running ones.

Agent Studio is the low-code, visual workspace in Agent Platform. People use it to discover models, engineer prompts and build agents without writing code, which makes it a good fit for rapid prototyping and business-centric agents.

It is collaborative, so product owners and developers can work on the same agent. When a prototype needs deeper customization, you can export the logic into ADK and continue in a full-code environment instead of rebuilding from scratch.

A typical flow is to describe the agent's goal, try prompts against different models, attach tools and test it in the same workspace. Because the export lands in ADK, the work done in Studio is not throwaway.

ADK is the code-first framework for building agents on Agent Platform. It gives you granular control over logic, tools and environment, and it is the path most teams take for complex, multi-agent systems.

The upgraded ADK adds a graph-based framework for organizing agents into a network of sub-agents, secure sandboxed workspaces where agents can run bash commands and manage files, and multimodal streaming for live audio and video. Deploy the result to Agent Runtime with a single call.

from google.adk.agents import Agent

def get_exchange_rate(base: str, target: str) -> dict:
    """Return the exchange rate between two currencies."""
    return {"base": base, "target": target, "rate": 0.92}  # stub

root_agent = Agent(
    name="currency_agent",
    model="MODEL_ID",  # a model available to your project
    instruction="Answer currency questions using the tool.",
    tools=[get_exchange_rate],
)

The same agent code can be run locally while you iterate and then deployed to Agent Runtime, where Sessions and Memory Bank can be attached through ADK.

Agent Garden is a library of prebuilt agent samples and templates in the Build pillar. Instead of starting with a blank file, you pick a template for a common pattern and adapt it.

Google lists templates such as code modernization, financial analysis, economic research and invoice processing. They work as building blocks for multi-agent systems, so one template can become a sub-agent in a larger design.

Do not confuse it with Model Garden, which is the catalog of foundation models. Agent Garden is about agent logic, Model Garden is about the models underneath.

Model Garden is the library of more than 200 foundation models you can discover, test and use from Agent Platform. It lets teams pick the best model for each job instead of being tied to one vendor.

• First-party Google models: Gemini 3.1 Pro, Gemini 3.1 Flash Image and Lyria 3.
• Open models: for example Gemma 4.
• Third-party models: including Anthropic's Claude Opus, Sonnet and Haiku.

Because the agent logic and the model are separate, you can swap the model later without redesigning the agent.

Agent Runtime is the fully managed environment for hosting, deploying and scaling agents built with ADK or other frameworks. It is the Scale pillar's core service, and earlier documentation often calls the same service Agent Engine.

The re-engineered runtime offers sub-second cold starts, lets you provision new agents in seconds, and supports long-running agents that run autonomously for days. It also supports bidirectional streaming, Private Service Connect interfaces and customer-managed encryption keys.

Under the hood a deployed agent is a reasoningEngine resource, and you create it with client.runtimes.create(...) in the Python SDK.

A session stores the history of interactions between one user and an agent during a single conversation. It supplies the context the agent needs to continue a multi-turn exchange and is also the raw material for long-term memory.

With Custom Session IDs you can use your own identifiers, which lets you map a session straight to a record in your internal database or CRM. Access can be restricted with IAM Conditions, and you manage sessions through ADK, the console or API calls.

Memory Bank gives agents long-term memory. It extracts, stores and retrieves personalized information about a user across multiple sessions, so an agent can pick up where it left off days later.

Memories are generated and curated dynamically from conversations. Memory Profiles let agents recall high-accuracy details with low latency. You can also ingest events, fetch memories, review memory revisions and restrict access with IAM Conditions.

Customers such as Gurunavi and Payhawk use it to remember user preferences and habits, for example to propose restaurants or pre-fill expenses.

Agent Identity gives each agent its own cryptographic identity: a unique, SPIFFE-formatted ID. It is a granular alternative to sharing one service account across many workloads.

The identity works directly in IAM, so you can grant a single agent access to a specific Cloud Storage bucket or BigQuery dataset. It also pairs with the Auth Manager for user-delegated tool access, and it leaves a clear audit trail. Identities are protected by default with Context-Aware Access using mTLS and DPoP.

You turn it on at deployment with identity_type=AGENT_IDENTITY.

Agent Registry is the queryable, central directory for your own, Google and third-party agents and MCP servers. It indexes agents, tools and skills so only governed, approved assets are discoverable.

For each entry it captures metadata such as versions, the framework (for example ADK) and capabilities like MCP tool names and annotations. Agents deployed to Agent Platform are registered automatically, and you can link them to an existing AI application or create a new one. Agent Gateway consults the registry to decide whether a destination is approved.

Agent Gateway is the governance and security enforcement layer for agent traffic. It acts as the entry and exit point for interactions between users and agents, agents and MCP tools, and agents and other agents.

It terminates mTLS, translates between protocols (MCP, A2A, REST and gRPC), applies access policies and Model Armor screening, and emits telemetry to Agent Observability. In short, identity says who is calling, the registry says what is approved, and the gateway is where those rules are actually enforced.

Agent Sandbox is a hardened, isolated environment where an agent can safely run model-generated code or perform computer-use tasks such as browser automation, without putting host systems at risk.

It supports code execution, computer use and a shell sandbox. You can manage sandbox templates and snapshots, bring your own container (BYOC), and apply VPC Service Controls and customer-managed encryption keys.

Think of it as a disposable computer for the agent. If the model writes code that deletes files or opens odd network connections, the damage stays inside the sandbox instead of reaching your host systems. VPC Service Controls and CMEK let security teams apply the same perimeter and encryption rules they use elsewhere.

Model Armor provides content security filters you attach to a gateway. It scans user prompts and tool responses in real time and blocks prompt injection, sensitive data leaks and harmful content.

Because it sits on the gateway, one Model Armor policy protects every agent routed through it, and its findings appear in observability as Model Armor spans. Agent Gateway runs it on both prompts going in and tool payloads coming back.

It is the right tool for content risk, not access risk. Model Armor does not decide whether an agent may call a tool; IAM policies do that. Pair them: policy limits where an agent can go, and Model Armor checks what is said on the way there.

Agent Runtime is framework-flexible. You can deploy agents built with ADK, Agent2Agent (A2A), LangChain, LangGraph, AG2, LlamaIndex or a fully custom implementation.

If you deploy an agent object, the framework is detected automatically. If you deploy from source files and omit it, it defaults to custom.

The Managed Agents API is a config-driven, REST-first way to build autonomous agents inside a fully managed sandbox. You describe the agent in configuration instead of writing and hosting your own runtime code.

Two APIs work together. The Agents API creates and manages agent configurations and sandbox environments with mounted sources such as skills and artifacts. The Interactions API is what you call to talk to a deployed agent at runtime. Evaluation is supported too.

Choose it when you want a managed sandbox for actions and prefer to drive everything through REST calls, for example from a backend service, rather than packaging a Python class for Agent Runtime.

Agent Observability collects traces, logs and metrics from your agents using OpenTelemetry. It builds on Cloud Trace, Cloud Logging, Cloud Monitoring and Topology, and it is collected by default when you deploy with ADK.

• Traces: the execution path of a request, including reasoning steps and tool calls.
• Logs: events and errors.
• Metrics: latency and token usage.

Telemetry also arrives from Agent Gateway and Model Armor, so you can debug a failure, watch cost, and see the full path of an agent's reasoning in one place.

Pick by who is building and how much control they need. Agent Studio suits fast, visual prototyping, Managed Agents API suits teams that want a REST-first, config-driven agent without hosting runtime code, and ADK suits custom logic and multi-agent orchestration.

A common path is to prototype in Studio, export to ADK once requirements harden, and deploy to Agent Runtime.

A session remembers one conversation. Memory Bank remembers a user across conversations. Sessions hold the raw interaction history, while Memory Bank extracts and curates the facts worth keeping.

flowchart LR
  A["User conversation"] --> B["Session history"]
  B --> C["Memory generation"]
  C --> D["Memory Bank"]
  D --> E["Retrieved in a later session"]

Sessions feed memory generation, so the two are used together rather than as alternatives.

A practical rule: if losing the information when the chat ends is acceptable, a session is enough. If the agent should still know it next week, it belongs in Memory Bank. Memory revisions and IAM Conditions also let you review and restrict who can read stored memories, which matters for personal data.

A shared service account is one principal reused by many workloads, so IAM and audit logs cannot say which agent did what. Agent Identity gives every agent its own SPIFFE-based principal, so permissions and audit entries map to a single agent.

Custom service accounts are still allowed: set service_account when you create or update the runtime instance. Agent Identity is simply the better default for least privilege.

The registry is a directory that records what is approved. The gateway is the enforcement point that checks traffic against that directory and against policy. One without the other leaves a gap: a list nobody enforces, or an enforcer with nothing to enforce.

Google describes the pieces in exactly this way: identity, registry, policies and gateway work together as one governance architecture.

A quick review test is to remove one piece mentally. Without the registry, the gateway has no trusted list to compare against. Without the gateway, a registry entry is only documentation, because nothing blocks a call to an unlisted tool.

There are five deployment methods, and you pick one based on your workflow. All of them end in a client.runtimes.create(...) call that returns a remote agent object.

remote_agent = client.runtimes.create(
    agent=local_agent,
    config={
        "requirements": ["google-cloud-aiplatform[agent_engines,adk]"],
        "display_name": "currency-agent",
        "identity_type": "AGENT_IDENTITY",
    },
)
print(remote_agent.api_resource.name)

Deployment takes a few minutes, and its latency depends mostly on how long it takes to install your packages.

Choose source files when you work in Python and want a simple, declarative deployment for CI/CD or Terraform. Choose a container image when you need any language, control over the build, or lower deployment latency.

If you need to own the API server but still want Agent Runtime to build it, a Dockerfile sits in the middle.

You pass resource controls in the deployment config: min_instances, max_instances, resource_limits and container_concurrency. These were in Preview in the docs I reviewed, so check the current launch stage.

• min_instances: instances kept warm, range 0 to 75, default 1.
• max_instances: ceiling for traffic spikes, range 1 to 1000, default 100 (1 to 100 if VPC-SC or PSC-I is enabled).
• resource_limits: only cpu and memory, default 4 CPU and 4Gi.
• container_concurrency: default 9, recommended 2 x cpu + 1.

config={
    "min_instances": 1,
    "max_instances": 10,
    "resource_limits": {"cpu": "4", "memory": "8Gi"},
    "container_concurrency": 9,
}

A higher min_instances keeps capacity warm for latency-sensitive agents, while a lower value saves cost for rarely used ones. Raise max_instances only if downstream systems can take the load, since scaling out agents also multiplies tool and model calls. The docs say idle-time billing behavior during Preview is subject to change.

Reference a Secret Manager secret in env_vars by giving a secret ID and version. The value then appears as a normal environment variable inside the agent.

env_vars = {
    "CLOUD_SQL_CREDENTIALS_SECRET": {"secret": "SECRET_ID", "version": "SECRET_VERSION_ID"},
}

1. Create the secret in the same project as the deployed agent.
2. Grant secretmanager.versions.access (for example via roles/secretmanager.secretAccessor) to the agent's runtime identity.
3. If the agent uses Agent Identity, also grant that permission to the Agent Platform Service Agent, because it fetches secrets during deployment.

Secrets are strings, so parse JSON payloads yourself. Do not set reserved variables such as GOOGLE_CLOUD_PROJECT or PORT.

Never hard-code credentials in agent source or in the deployment config. A secret reference keeps the value in Secret Manager, where rotation and access are controlled. If you pass a plain list of variable names instead of a dictionary, Secret Manager integration is not available.

The call is blocked. Agent Gateway uses the registry to check whether a destination is approved, and IAM Unified Access Policies are default deny: a connection is blocked unless an explicit policy grants access.

To fix it, register the MCP server or tool in Agent Registry, then create an IAM Unified Access Policy that links the agent's identity to that registry entry. Only then will the gateway let the call through, and Model Armor can still screen what passes.

This is why unapproved or shadow tools cannot quietly appear in production.

A common surprise is a tool that works from a laptop but fails from the deployed agent. That is expected: the gateway evaluates the call against registry and policy, not against whether the server is reachable.

Agent Gateway governs two paths: Client-to-Agent (ingress) and Agent-to-Anywhere (egress).

Think of ingress as protecting the agent from the outside and egress as protecting the outside from the agent.

An example: a customer-facing web app calling your support agent is ingress, and the support agent calling a SaaS CRM API or another agent is egress. You usually need both, because ingress stops hostile prompts reaching the agent and egress stops a compromised agent reaching unapproved systems. Both directions export telemetry for auditing.

Agent Gateway can combine several policy types. Some are deterministic, some content-based, and one is written in plain language.

In the docs I reviewed, token management policies and extension bindings were marked as coming soon, so confirm their status before promising them.

IAM Unified Access Policies answer a precise question: may this agent identity reach this registered destination? They are deterministic, use CEL attributes, and deny by default.

Semantic Governance policies are written in plain language and enforce business rules at runtime on how tools are used. They can stop a risky combination of tool calls even when each call is individually allowed, for example reading from an untrusted source and then triggering a payment.

Use Agent Simulation and offline evaluation. Simulation tests the agent against human-like synthetic users and virtualized tools in a controlled environment, then scores it on task success and safety across multi-step conversations.

1. Define the scenarios and success criteria you care about.
2. Run simulated conversations with synthetic users and virtualized tools, so no real backend is touched.
3. Review scores for task success and safety, and open failing conversations in traces.
4. Fix instructions, tools or routing, then run the same evaluation again to confirm the change helped.

This gives you a repeatable gate before production, where online monitors take over.

Keep the scenario set in version control so each release is tested against the same cases plus any regressions you discover later.

Offline evaluation checks an agent against prepared test cases before release. Online Monitors continuously score a live agent on real traffic after release. One protects the launch, the other protects the product over time.

Use them together. A failing online monitor alert should become a new offline test case, so the same regression cannot return unnoticed. Quality alerts tell the team when scores drop, and failure clusters group the cause instead of forcing you to read conversations one at a time.

Agent Optimizer automates the tedious part of tuning. Instead of reading logs by hand, it clusters real-world failures and suggests refined system instructions to improve accuracy.

It fits into the evaluation loop: evaluation shows which conversations failed, failure clusters group them by cause, and the optimizer proposes better instructions for those groups. You then apply the change and evaluate again to verify the fix.

Treat suggestions as proposals, not automatic changes. Review the revised instructions, check they do not break scenarios that already passed, and roll them out through your normal revision and traffic controls on Agent Runtime. Because the optimizer works from real failure clusters, the largest groups of failures are the first candidates to fix.

Mostly names, packaging and new governance features. The core agent resource is still a reasoningEngine, and many package extras (for example google-cloud-aiplatform[agent_engines,adk]) still appear in the docs.

• The product is Gemini Enterprise Agent Platform, and Vertex AI services are delivered through it.
• The managed runtime is Agent Runtime, created with client.runtimes.create(...); earlier material calls it Agent Engine.
• Vector Search 2.0 is now Agent Retrieval.
• New governance pieces exist: Agent Identity, Registry, Gateway and Anomaly Detection.

There is a dedicated Agent Runtime SDK migration page, so read it before changing production code.

Plan the move in phases: inventory what you run today, update names in scripts and docs, adopt Agent Identity for new deployments, then add the registry and gateway.

It supports it at three levels: ADK for designing the network of agents, Agent Runtime for agent-to-agent orchestration, and Agent Gateway for governing the traffic between them.

ADK's graph-based framework lets you define clear logic for how sub-agents cooperate. Agent-to-agent orchestration lets agents delegate to one another using generative or deterministic patterns. For critical flows such as compliance, deterministic paths make sure the agents follow a well-specified route every time. Between agents, A2A traffic is governed by the gateway and agents are discovered through Agent Registry.

flowchart TD
  U["User request"] --> R["Root agent"]
  R --> A["Research sub-agent"]
  R --> B["Billing sub-agent"]
  R --> C["Compliance check - deterministic path"]
  A --> T1["Approved MCP tool"]
  B --> T2["Approved MCP tool"]

In an interview, mention the trade-off. Fully generative delegation is flexible but harder to predict, while deterministic flows are predictable but rigid. Mixing both inside one graph is the usual answer: let a generative router pick the specialist, and force fixed steps for regulated actions such as consent checks or payment approval.

Agent Runtime lets you deploy agents that run autonomously for days at a time and keep state while they do. A typical example is a sales prospecting sequence that waits, follows up and adapts over many days.

Because instances can scale and be replaced, keep durable state in Sessions and Memory Bank instead of in process memory. Custom Session IDs let you tie the work to your own records. Sub-second cold starts keep resumed work responsive.

For oversight, long-running agents can be tracked in the Inbox in Gemini Enterprise, and Agent Gateway and Observability still record every call along the way.

A practical design question is how the agent wakes up. Plan a trigger, such as an event or a schedule, and store the current step in the session so a restart resumes at the right point. The docs also describe autonomous agent scheduling for this kind of work, so check them for current options.

It uses bidirectional streaming over the WebSocket protocol, so audio and video can flow in both directions without waiting for a full request to finish. ADK adds multimodal streaming support for live audio and video cues.

On Agent Runtime you declare this in the agent's exposed methods through the api_mode field. The documented options are an empty string for a plain call, async, async_stream, stream and bidi_stream.

class_methods = [
    {"name": "live_session", "api_mode": "bidi_stream"},
    {"name": "ask", "api_mode": ""},
]

Use this for live customer or employee conversations where lag would break the experience.

Latency also depends on how you design the agent. Keep tool calls fast during a live audio turn, and if a tool must be slow, have the agent say so while it waits rather than going silent. Memory Bank can supply user context quickly without replaying a whole transcript.

A simplified egress flow has five stages: authenticate the agent, check the destination, apply policy, screen the payload, then record telemetry. Google does not publish a strict step order, so treat this as a mental model.

sequenceDiagram
  participant A as Agent
  participant G as Agent Gateway
  participant R as Agent Registry
  participant M as Model Armor
  participant T as MCP tool
  participant O as Observability
  A->>G: Call with SPIFFE identity over mTLS
  G->>R: Is the destination approved?
  G->>G: Evaluate IAM and semantic policies
  G->>M: Screen prompt or tool payload
  G->>T: Forward allowed request
  T-->>G: Response
  G->>M: Screen response
  G-->>A: Return response
  G->>O: Export traces and access logs

1. Identity: the gateway terminates mTLS and learns which agent is calling.
2. Registry: it confirms the destination is an approved entry.
3. Policy: IAM Unified Access and Semantic Governance rules decide whether the call is allowed; default is deny.
4. Content: Model Armor scans payloads in both directions.
5. Telemetry: traces and access logs go to Agent Observability.

The key interview point is that none of these checks live in agent code. The developer writes the tool call, and the platform wraps it with identity, approval, policy and inspection, so a change in security policy usually needs no change to the agent. A response that Model Armor flags is stopped before the agent acts on it.

Auth Manager handles the hard parts of OAuth for agents: the handshake, token storage and refresh. Agents can call tools on behalf of a user without developers writing credential code or storing secrets.

You configure managed OAuth 2.0 connections through the registry. Agent Gateway integrates with Auth Manager and transparently handles OAuth 2.0 handshakes and Workload Identity Federation, so credentials stay out of agent code.

The benefit shows in audits: the tool sees a request tied to a particular user's consent, and the platform records which agent made it. If a user's consent is revoked at the provider, the agent can no longer act for that user.

For MCP traffic the gateway inspects the JSON-RPC request and extracts the tool name and method attributes. Those values become inputs to policy, so access can be decided per tool instead of per server.

This matters because one MCP server often exposes both harmless and dangerous tools. With tool-level attributes you can let an agent call a read tool, such as fetching a ticket, while denying a destructive one, such as deleting it. The registry stores tool names and annotations, which gives policies something stable to refer to.

The gateway handles MCP over Server-Sent Events or HTTP POST.

In practice, write allow rules around the tool names listed in the registry, and review annotations when a server adds new tools. A server that gains a destructive tool should not automatically become callable by every agent that already uses it.

IAM decides who may use Google Cloud resources. It cannot see what is inside an agent's prompt or a tool's response, and agents often call third-party MCP servers or run outside Google Cloud. The gateway fills that gap at the network layer.

The two are complementary: Unified Access Policies are IAM-based, and the gateway is where they are enforced.

A one-line answer: IAM controls access to the door, and the gateway also inspects what is carried through it.

The gateway's control plane is the same everywhere, but who runs the proxy changes with the host environment. This reflects the docs as of late October 2026, so check availability before planning.

In every model you manage identities, registry entries and policies centrally. In the cross-cloud case agent traffic stays in your environment, and only configured checks such as Model Armor call out to Google Cloud.

Pick by where your agents already run. On Agent Runtime or Gemini Enterprise you get the managed gateway with mTLS termination, IAP access policies, Model Armor and Semantic Governance, with no proxy to operate.

No single control is enough, so layer them. The goal is to limit what an agent can reach and to inspect what moves in and out.

1. Screen content: attach Model Armor to the gateway for prompts and tool responses.
2. Deny by default: use IAM Unified Access Policies so the agent reaches only registered destinations.
3. Constrain tool combinations: add Semantic Governance rules for risky sequences.
4. Keep traffic inside a perimeter: route through private network attachments and VPC Service Controls.
5. Isolate generated code: run it in Agent Sandbox.
6. Use least privilege: give each agent its own identity and minimal IAM roles.
7. Watch for drift: enable Agent Anomaly Detection and Threat Detection.

The order matters operationally: identity and default deny shrink the blast radius, while content screening and anomaly detection catch what policy cannot predict. Test the controls with adversarial simulations before launch.

Agent Anomaly Detection looks for unusual reasoning, while Agent Threat Detection looks for known malicious activity. One asks 'is this odd?', the other asks 'is this an attack?'.

Results surface in the Agent Security dashboard, which is powered by Security Command Center. It also maps relationships between agents and models, automates asset discovery and scans for vulnerabilities in the operating system and language packages.

Use both in operations: an anomaly finding says the agent's behavior changed and needs investigation, while a threat finding calls for incident response. Both feed the same security view, so analysts do not need separate tools.

Work from the deployment config outward. Most failures come from a small set of causes.

1. Dependencies: pin package versions, especially google-cloud-aiplatform, cloudpickle and pydantic, so the deployed environment matches the one that built the agent.
2. Environment variables: do not set reserved names such as GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION, PORT or K_SERVICE.
3. Entry point: for source or Developer Connect deploys, check entrypoint_module and entrypoint_object.
4. Size: keep source_packages under 8 MB.
5. Containers: make sure a Dockerfile or image follows the runtime contract.
6. Permissions: if secrets are used, check secretmanager.versions.access for the Agent Platform Service Agent.

Then read Cloud Logging for the build and startup errors.

When behavior differs after a clean deploy, compare pinned versions locally and remotely, and confirm the agent identity has the IAM roles the code needs. A missing role often shows up as a permission error at runtime rather than a deployment failure.

Because the gateway is default deny, a blocked call usually means a missing grant rather than a bug. Check in this order:

1. Registry: is the MCP server or tool registered in Agent Registry?
2. Policy: does an IAM Unified Access Policy link this agent's identity to that registry entry?
3. Content: did Model Armor block the prompt or payload? Look at the Model Armor spans.
4. Network: if you use VPC connectivity, is the route configured and reachable?
5. Capacity: a gateway can govern up to 5,000 registered resources.

Use gateway monitoring and traces to see which stage rejected the request, then fix that stage specifically.

A useful habit is to reproduce the denial with the same agent identity, because an administrator's own permissions can hide the problem. Fix one layer at a time and retest, since registry and policy changes may each be needed before the call works.

Cost comes from model tokens and from compute, so tune both.

• Token budgets: token management policies attribute token usage and enforce shared budgets. The docs listed them as coming soon.
• Model choice: pick a smaller model from Model Garden for simple steps.
• Fewer wasted turns: run Agent Optimizer on clustered failures to tighten system instructions.
• Compute settings: tune min_instances, max_instances and container_concurrency to the real load.
• Background work: use batch and event-driven agents for asynchronous tasks.
• Measure: watch token and latency metrics in Observability.

Avoid cutting the wrong thing. Lowering concurrency or instance counts to save money can raise latency, and a cheaper model may need stricter instructions to hold quality. Validate every cost change against evaluation scores so savings do not hide a quality drop, and review token metrics per agent so you know which workload is actually expensive before optimizing it.

Use a sandbox whenever the code is untrusted or model-generated, or when the agent needs a full environment, such as a shell, files or a browser. Keep trusted, deterministic function tools in the agent process.

Sandboxes also support templates, snapshots, custom containers, VPC Service Controls and CMEK, so they can meet enterprise network and encryption rules.

Also consider data movement. Code that needs sensitive files should get them placed into the sandbox deliberately instead of being given broad network access, and VPC Service Controls can restrict where it can connect.

Three layers combine: application telemetry, network telemetry and identity-based audit. Together they answer what the agent did, what crossed the wire and who is accountable.

flowchart LR
  A["Agent on Runtime"] --> O["Agent Observability"]
  G["Agent Gateway"] --> O
  M["Model Armor"] --> O
  O --> T["Cloud Trace"]
  O --> L["Cloud Logging"]
  O --> C["Cloud Monitoring"]
  O --> P["Topology graphs"]

• Application: OpenTelemetry traces, logs and metrics from the agent.
• Network: the gateway adds Layer 7 traces and access logs for every interaction.
• Identity: Agent Identity maps each action to one agent, and audit logging tracks agent activity.

Topology graphs then show agent dependencies and traffic between agents and tools.

For incident review, start from a trace: it shows the agent's reasoning path and tool calls. Then pivot to gateway logs to see what crossed the network, and to the identity to see which principal acted. This three-way view is faster than reading raw application logs alone. Use Model Armor spans to see content-security decisions, and Agent Security findings in Security Command Center to complete the picture.

Start from the lifecycle: build with ADK, run on Agent Runtime, govern at the gateway, and keep improving with evaluation. Here is one reasonable design.

flowchart TD
  U[Customer] --> GW["Agent Gateway ingress"]
  GW --> R["Router agent on Agent Runtime"]
  R --> B["Billing agent"]
  R --> S["Troubleshooting agent"]
  B --> MCP1["Registered billing MCP tool"]
  S --> MCP2["Registered diagnostics MCP tool"]
  R --> SS["Sessions with CRM IDs"]
  R --> MB["Memory Bank"]
  GW --> MA["Model Armor"]

1. Build: a router agent with billing and troubleshooting sub-agents in ADK.
2. Scale: deploy to Agent Runtime; use Sessions with Custom Session IDs mapped to CRM records, and Memory Bank for preferences.
3. Govern: give each agent its own Agent Identity, register tools, allow access with Unified Access Policies, and attach Model Armor.
4. Optimize: run Agent Simulation and offline evaluation before launch, then Online Monitors and Agent Optimizer in production.

Finish by exposing the router in the Gemini Enterprise app if employees also need it.

Trade-offs to mention: a router adds one more hop but keeps specialists small, and strict policies add review work but make the system safe to scale. Start with the smallest tool set, then widen it through the registry.