Cloud / Google Cloud Agent Studio Interview questions

Agent Studio is a low-code visual designer inside the Google Cloud console for building, configuring and testing AI agents. It sits in the Gemini Enterprise Agent Platform (the platform that used to be called Vertex AI) and is the no-code/low-code entry point to agent development.

You describe the agent in a chat box or lay it out on a canvas, give it instructions, pick a model, attach tools, and chat with it in a Preview tab. When it behaves the way you want, you can deploy it to Agent Runtime or copy the generated code and keep working in a code editor.

One thing to mention in an interview: Google's documentation marks the design-agents feature as Preview, so it is under the Pre-GA terms and details can change.

Google renamed the platform: what used to be Vertex AI is now the Gemini Enterprise Agent Platform, and Agent Studio is its low-code surface. Third-party write-ups describe Agent Studio as the successor of the low-code experience in Vertex AI Agent Builder, so you will still see both names in older blog posts and tutorials.

The docs also use "Studio" for UI-based work with models, such as prompt design and model tuning, not only for agents. So the same console area covers experimenting with a model and designing an agent around it.

Naming has moved quickly in this area. If an interviewer uses the older term, say so briefly and map it to the current one rather than correcting them.

It is Google Cloud's unified platform to build, deploy, govern and optimize enterprise-grade AI agents and model-based solutions. Think of it as the umbrella under which Agent Studio, the Agent Development Kit, Agent Runtime, Agent Registry and the evaluation tooling live.

It supports different skill levels. Low-code users work in Agent Studio. Developers who want code use the Agent Development Kit (ADK) or Colab Enterprise notebooks. Both groups get the same integrated security and governance layer, including agent identity.

The platform is organized around Build, Scale, Govern and Optimize. Each pillar maps to a stage of the agent lifecycle.

Agent Studio belongs to Build, but its deploy button hands the agent to Agent Runtime, which is a Scale component.

There are two main methods, plus a shortcut.

1. Prompts: open the canvas, describe the agent in the chat box, and the flow builder updates to show a live preview. Changes are saved automatically. If the prompt is vague, the assistant asks a clarifying question; if it cannot apply the request, it asks you to rephrase.
2. Flow builder: design the main agent and subagents visually and configure each in a Details panel.
3. Agents mode toggle: on the Studio welcome prompt, switch to Agents mode and submit; the designer canvas opens pre-populated from your prompt.

You can mix them, for example start with a prompt and then fine-tune in the flow builder.

The flow builder is the visual representation of an agent's workflow and control logic on the canvas. The main agent and its subagents appear as nodes, so you can see how work is split before you run anything.

Clicking a node opens its Details panel. For a main agent or local subagent you set a name, description, instructions, model and tools. The Add a subagent (+) button creates child agents.

The main agent is always a local agent, while subagents can be local or taken from Agent Registry.

Preview is the built-in chat pane for testing your agent while you design it, next to the Flow tab. You type test questions and watch how the agent answers with its current instructions, model and tools.

For a saved agent, Studio first checks that the agent's identity has the required IAM roles. If something is missing, a notification appears and Manage opens the permissions dialog.

You can also click an event in the conversation to inspect the author, request and response, tool calls and metadata, which makes Preview the first place to debug behaviour.

The documented requirement is the Agent Platform User role, roles/aiplatform.user, granted on the project. An administrator normally grants it.

A custom role or another predefined role can also work if it carries the same permissions. Keep in mind this role is for you, the person designing the agent. The agent itself runs under its own identity, which needs separate roles for things like Cloud Storage files or MCP tools.

A quick way to verify access is to ask whether you can open Agents under Agent Studio in the console. If the page is blocked, check the project selector first, then the role on that specific project, because a role granted on a different project does not carry over.

A local agent is defined entirely on the Studio canvas. A Registry agent already exists elsewhere and is pulled in as a remote subagent.

The Registry option only appears after you save the agent, because the parent needs an identity first.

In the Agent2Agent (A2A) protocol, an Agent Card is a structured description of an agent: who it is, what it can do and how to reach it. Other agents read it to decide whether to delegate a task.

Agent Studio uses this idea for registry subagents. The parent agent routes tasks to the subagent based on its Agent Card, and the subagent's name and description are imported from the registry.

So a vague card means poor routing. When you register your own agents, write the description like a job ad: what it handles and what it does not.

The documented tool options are:

• Google Search: lets the agent run web searches; on by default.
• URL context: lets the model analyze URLs found in prompts sent to the agent; on by default.
• MCP Server from Agent Registry: attaches a registered MCP server as a node-level tool. It only appears after the agent is saved, and Auth Config None means access is resolved through IAM bindings.

Direct MCP endpoints and Vertex AI Search data store tools are deprecated; existing ones are read-only.

URL context lets the model read the pages behind URLs that appear in the prompts sent to the agent. If a user pastes a link and asks for a summary, the agent can analyze that page instead of guessing.

It is switched on by default, as is Google Search. For a closed-domain agent, such as an internal HR assistant, think about turning both off so answers come only from the instructions, knowledge files and approved MCP tools.

That is a design judgement, not a rule from the docs, but it is a good point to raise when asked about grounding and control.

Knowledge files are static reference documents you upload so the agent grounds its answers in your content instead of only model memory.

You attach them in the Knowledge section of the parent agent's Details panel. That section appears only after the first save. On save, the files go into a dedicated Cloud Storage bucket under a path prefix matching the agent's AGENT_ID.

After uploading, use the Preview tab to ask a question whose answer is in the file and confirm the agent uses it without making things up.

Per the docs, each agent can have up to 10 files, each no larger than 2 MB, and the supported types are PDF and plain text.

Two more constraints matter in design: files attach only to the parent agent node, not to subagents, and you cannot add knowledge when you build the agent through prompts alone; use the flow builder.

If your corpus is larger or changes often, these limits are the signal to move to a search-based tool rather than uploading files.

Agent Registry is the central hub for governance, discovery and search of your AI ecosystem on the platform. It is a unified catalog where you store and find MCP servers, tools, agents, endpoints and standalone skills (Preview).

It targets the usual scaling problems: fragmented tool access, isolated data and duplicated work. You can search by keyword, prefix or semantic query.

For Agent Studio, it matters because registered A2A agents become selectable subagents and registered MCP servers become tools, which is how Studio standardizes and secures tool access.

Get code shows the code for the agent you designed, so you can copy it into an editor and keep developing outside the canvas. It is the bridge from low-code to code-first.

The generated Python is based on the ADK model; the docs mention an agent.py that also shows the knowledge-file grounding configuration. If your agent uses a remote Registry subagent, the code calls AgentRegistry.get_remote_a2a_agent to resolve that subagent at runtime.

Treat the exported code as a snapshot. Changes you make later on the canvas do not flow into code you already copied, so decide early which side is the source of truth.

ADK is an open-source, modular, model-agnostic framework for building agents and multi-agent systems in code, while keeping precise control over how the agents behave.

It is the code-first counterpart to Agent Studio. Studio's generated code and its "standard ADK application" deployment option show that the two are designed to hand work to each other.

Choose ADK when you need custom orchestration, tests in your repo, or logic the canvas cannot express.

In practice you define an agent with a name, a model, instructions and tools, then compose several agents into a hierarchy. Because it is model-agnostic, the same structure is not tied to one model family.

Agent Runtime is the managed service that hosts deployed agents so they can run and scale in production. Earlier documentation called it Vertex AI Agent Engine, and you will still find that name in older material.

It runs agents built with ADK, Agent2Agent, LangChain, LangGraph, AG2, LlamaIndex or a custom framework, and it connects to platform services such as Sessions and Memory Bank. It also supports tracing, logging and monitoring for deployed agents.

When you press Deploy in Agent Studio, a new Agent Runtime instance is created for that agent.

Each agent in Agent Studio gets its own unique identity that acts as an IAM principal. That identity, not your personal account, is what touches other Google Cloud resources when the agent runs.

The principal string looks like principal://agents.global.org-ORG_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/REASONING_ENGINE_ID. You can copy it from the drop-down next to the agent name in the canvas header and search for it in IAM.

An unsaved agent has no identity yet, which is why saving comes first.

Other agents can also be identified this way. When a parent calls a remote subagent over A2A, IAM decides whether the parent's identity is allowed to discover and invoke it.

Agent Garden is a library of prebuilt agents and templates that you can discover, customize and deploy. Instead of starting from a blank canvas, you begin from an agent already built for a common use case.

It sits in the Build pillar next to Agent Studio and ADK. A sensible workflow is to start from a Garden template, adjust it, and then deploy it like any other agent.

Templates are a starting point, not a finished product. Review the instructions, tools and permissions of anything you pull in before it handles real data.

Because an unsaved agent has no identity, and Preview, Deploy, knowledge uploads and Registry features all depend on that identity.

Specifically, you must save before you can preview, deploy, upload knowledge files, add Agent Registry MCP servers as node-level tools, or use Registry subagents. Until then, Preview and Deploy are disabled and the permissions dialog does not appear.

The first save asks for an agent name. After that, autosave applies your changes, and Studio prompts you if you try to leave an unsaved new agent.

Deployment is a few clicks once the agent is saved and tested.

1. Open the agent from the Agents list page.
2. Click Deploy to open the "Deploy to an Agent Runtime instance" dialog. If permissions are missing, the permissions dialog appears first.
3. Edit the display name, optionally add a description, and decide whether to tick Deploy as A2A.
4. Select a deployment region and click OK, then Deploy.

Creating the runtime instance can take up to five minutes. A success message then appears on the Flow tab.

It is a checkbox in the deployment dialog. When ticked, the agent is deployed as an Agent-to-Agent (A2A) asset that other agents can reuse as a remote subagent.

Leave it unticked for a standalone application: Studio then packages the agent as a standard ADK application.

A practical rule: if more than one team or agent needs the same capability, such as a shared compliance checker, deploy it as A2A and register it. If only one app calls it, the standard package is simpler.

On the Agent Studio welcome workspace, the main prompt box has a mode toggle. Switching it to Agents mode and sending a prompt launches the agent builder in the designer canvas instead of a plain model chat.

Studio pre-populates the flow and configuration from your prompt; you then keep editing instructions, models, tools and subagents.

It is a faster route than clicking Create agent first, handy when you already know the agent's purpose and want a draft to refine.

The difference from a plain model chat is the destination. Without the toggle, your prompt goes to the model for prompt design and experimentation; with it, the result is an agent definition you can save, preview and deploy.

In the Preview tab, selecting an event in the conversation opens its details. What you see depends on the event type, but it can include four things.

If the run fails, the error is displayed in Preview too.

A typical debugging move: a user says the agent gave a wrong answer, you open that event, see the exact request sent to the model, and notice a tool was never called. That points to unclear instructions, not a model fault.

The docs list this as a current limitation of prompt-based creation: the assistant is unable to add knowledge to an agent. The docs do not give a reason, so treat it as a product limit rather than a design principle.

The workaround is simple. Create the agent with prompts, save it, then open the flow builder and add files in the Knowledge section. Both methods edit the same agent, so nothing is lost by switching.

Remember also that the Knowledge section only shows up after the first save, so even in the flow builder the order is: create, save, then attach files. Skipping the save is the usual reason people cannot find the option.

Agent Studio is visual and low-code; ADK is code-first. They target the same kind of agent but give you different amounts of control.

They are not rivals. A common path is prototype in Studio, then export and continue in ADK.

For an interview answer, frame it as a maturity ladder: explore in Agent Studio, harden in ADK, run on Agent Runtime. Studio's own deploy option still produces a standard ADK application, so the two share a packaging model.

Agent Studio is a visual designer. The Managed Agents API is a config-driven, REST-first API for building autonomous agents inside a fully managed sandbox where the agent can take actions.

Use Studio when a person designs and tests the agent by hand. Use the Managed Agents API when you want to create and drive agents programmatically from your own systems and let them act in the managed sandbox.

Both are Build-pillar options, alongside ADK for custom code.

A useful test: if the person who builds the agent is a non-developer iterating on wording, pick Studio. If an application provisions agents on demand for many tenants, pick the API.

The docs note that all configuration files for created agents are stored in the us-west1 region. If an organization policy restricts resource locations and does not allow that region, you might not be able to create an agent.

The fix is administrative: review the Restrict resource locations organization policy and have an admin allow the needed location for the project.

This is easy to miss, because deployment regions are chosen separately at deploy time, while the design-time configuration location is fixed.

Check the policy before a workshop or demo. A new project that inherits a strict location constraint will fail at the first Create agent attempt, which is a bad moment to discover it.

When you click Deploy or open Preview for a saved agent, Studio checks whether the agent's identity has the IAM roles it needs.

If roles are missing, a dialog lists them. Grant All grants every listed role to the identity in one action. Proceed anyway lets you preview or deploy without granting, at the risk of runtime failures. If everything is already granted, the dialog does not show.

It handles the standard roles only. Roles for downstream resources, such as BigQuery Data Viewer for a tool that queries BigQuery, must be granted manually.

Choosing Proceed anyway is fine for a quick experiment, but a missing role then shows up as a failing tool call or a failed knowledge lookup. Production deployments should have every role granted deliberately.

It depends on what the agent uses. The permissions dialog grants these automatically.

The dialog covers the common roles above. Your own tools may need more, and those grants are your responsibility. Prefer granting discoveryengine.viewer on the specific data store rather than the whole project. If you only grant roles at project level during testing, tighten them before production.

You attach the files to the parent agent only. Studio does not let you attach knowledge files to subagents.

So when a subagent needs reference material, you have two options. Keep the facts on the parent and have the parent pass the relevant context into its request, or give the subagent a search-based tool, such as the Agent Search MCP server from Agent Registry, so it can fetch grounding itself.

Keep the 10-file and 2 MB limits in mind when deciding what goes on the parent.

For example, a root agent can hold the return-policy PDF and pass the relevant rule to a refunds subagent in its request, while a product specialist searches the catalog itself through a search tool.

Uploaded knowledge files are stored in a Cloud Storage bucket in your own project, and the docs warn that anyone with access to the project or that bucket can view them.

That means project-level access, not agent access, decides who can read the documents. If a file contains salary data or customer records that should not be visible to every project principal, do not upload it as knowledge.

The permissions dialog grants the agent's identity only roles/storage.objectViewer on that bucket, which is the right scope for the agent itself.

Practical advice: review each file before upload, strip anything that is not needed for answers, and prefer a governed search tool when content is sensitive and access should follow existing data permissions.

A per-agent identity lets you apply least privilege: grant each agent only the roles its tools need, and see in IAM and audit logs which agent did what.

If agents shared one account, giving one of them BigQuery access would give all of them BigQuery access. With separate principals, the support agent can read a knowledge bucket while the reporting agent gets a BigQuery role and nothing else.

It also supports A2A delegation, since the parent's identity needs permission to discover and invoke remote subagents.

It also makes cleanup safer. When an agent is retired, removing its single principal from IAM revokes everything it could do, without touching other agents.

Google's stated reason is to enforce security and standardize tool management through Agent Registry. A direct endpoint URL pasted into an agent is hard to govern; a registered MCP server is catalogued, discoverable and tied to IAM.

Direct Vertex AI Search data store tools were deprecated for the same reason. Existing agents that use either keep working in a read-only state, but you cannot edit those tools. To keep full functionality you migrate to an MCP server from Agent Registry.

The interview takeaway: tool access is moving from per-agent wiring to a governed catalog.

Practically, a team with many direct connections should inventory them, register each MCP server, and swap the tool on every agent. Until then those agents keep running, but you lose the ability to adjust their legacy tools.

The replacement is the Agent Search MCP server from Agent Registry, which appears as discoveryengine.googleapis.com.

1. Note the old tool's project ID, location and data store ID.
2. Create a new agent and save it.
3. Grant the agent identity roles/discoveryengine.viewer, ideally on the target data store or app. The dialog grants roles/mcp.toolUser.
4. Add the MCP server from Agent Registry with Auth Config None.
5. Tell the agent which serving configuration to use in its instructions.

Use the search tool to answer questions about YOUR_TOPIC.
When using the search tool, use this servingConfig:
projects/PROJECT_ID/locations/LOCATION/collections/default_collection/dataStores/DATA_STORE_ID/servingConfigs/default_search

For a search app, replace dataStores/DATA_STORE_ID with engines/APP_ID.

The key prerequisite is that your MCP server must be registered in Agent Registry first. A raw endpoint URL cannot be carried over.

1. Register the MCP server in Agent Registry.
2. Open the agent in the Studio canvas and remove the legacy direct connection.
3. Click Add (+) next to MCP Server from Agent Registry and pick the registered server.
4. Click Add, and save if it is the agent's first save.

If the tool reaches other Google Cloud resources, check that the agent identity has the roles for those too.

Registering first also gives you a bonus: the same registered server can be reused by other agents, and its access can be controlled in one place instead of per agent.

The path runs from design to a running runtime instance, with a permission check in the middle.

flowchart LR
  A["Design with prompts or flow builder"] --> B["Save the agent and get an identity"]
  B --> C["Preview and inspect events"]
  C --> D{Identity has required roles?}
  D -- No --> E["Permissions dialog: Grant All"]
  E --> F[Deploy]
  D -- Yes --> F
  F --> G["Agent Runtime instance created"]
  G --> H["Deployments page: Metrics and Playground"]

Saving gives the agent an identity. Preview exercises it, and Deploy creates a runtime instance in the region you pick, which can take up to five minutes. Afterwards you test and watch it from the Deployments page. At any point, Get code lets you leave the canvas and continue in ADK.

Use the platform's Deployments page rather than the Studio canvas.

1. Open Deployments in the Agent Platform console.
2. Filter by Region so your agent shows up.
3. Click the agent's name to open its Metrics page.
4. Switch to the Playground tab, type a test query, and confirm it runs successfully.

Preview tests the saved design; Playground tests the actual runtime instance, so a pass in one does not guarantee a pass in the other, especially if roles differ.

A good habit is to run the same three or four test prompts in Preview before deployment and in Playground after it. Differences between the two usually come from roles, region or network settings on the runtime instance.

Metrics on the same page show how the deployed agent is behaving over time, which is where you look when users report slowness or errors.

Move when the canvas stops being the fastest way to express what the agent must do.

Typical triggers are custom orchestration logic, tests and code review in a repository, a framework such as LangGraph, or behaviour you need to simulate and control tightly. ADK gives granular control over logic, tools and environment simulation, which a visual designer cannot match.

The move is cheap because Get code hands you the generated agent code. Prototype in Studio to settle instructions, tools and subagent structure, then continue in code once you need versioning and CI.

A caution: moving is a one-way habit. Once logic lives in code and tests, editing the canvas copy creates drift, so announce the cut-over to the team and archive or label the Studio version as the prototype.

Work from the cheapest check to the most specific.

1. Permissions: look for the notification in Preview. Click Manage and use Grant All, or add roles manually.
2. Events: click the failing event and read the author, request and response, tool calls and metadata.
3. Tool access: for a Registry MCP tool, confirm roles/mcp.toolUser and roles/agentregistry.viewer; for downstream resources such as BigQuery, add those roles yourself.
4. Grounding: if answers ignore a file, confirm the agent was saved and the file is on the parent agent.

The preview error text is shown directly in the tab, so read it before changing anything.

If the same prompt works in Preview but fails after deployment, compare the roles on the deployed instance and the region. Preview runs under the saved agent's identity checks, while the runtime has its own configuration.

Both give agents state, but over different time spans. Sessions manage stateful data and context within a single agent interaction. Memory Bank gives agents persistent memory so they can recall information across multiple sessions.

Example: a user's current question and earlier turns sit in the session; a remembered preference such as "always reply in French" belongs in Memory Bank.

Design tip: keep sensitive or short-lived details in the session, and write to long-term memory only what is worth remembering. Memory Bank also has its own controls, including IAM Conditions, so what is remembered can be restricted. Deciding what to store is a product decision as much as a technical one.

The parent agent finds a remote subagent through Agent Registry, reads its Agent Card, and sends it work over the Agent2Agent protocol. In generated code, AgentRegistry.get_remote_a2a_agent resolves the subagent at runtime.

sequenceDiagram
  participant U as User
  participant P as Parent agent
  participant R as Agent Registry
  participant S as Remote A2A subagent
  U->>P: Request
  P->>R: Resolve subagent and Agent Card
  R-->>P: Card and endpoint
  P->>S: Delegate task
  S-->>P: Result
  P-->>U: Final answer

It only works if the parent's identity may discover and invoke the subagent. Studio's permissions dialog grants roles/agentregistry.viewer and roles/aiplatform.viewer for this; you can also grant them manually.

If delegation fails, check three things in order: the subagent is registered and published, the parent identity has the Registry and AI Platform viewer roles, and the subagent was deployed as an A2A asset.

Start by hand in Preview, then use the platform's Optimize tooling once the agent matters.

The evaluation section of the platform covers offline evaluations, simulated agent behaviour, online monitors for continuous evaluation, evaluation metrics, analysis of failure clusters, quality alerts and prompt optimization. Together they take you from "it worked in my test chat" to measurable quality over time.

The exact setup steps vary by release, so check the current evaluation docs before promising specifics in an interview.

For a Studio agent, a sensible loop is: build a small set of representative questions, run them offline, read the failure clusters, adjust instructions in the canvas, and rerun. After deployment, online monitors catch regressions you did not anticipate.

Agent Gateway sits in the Govern pillar and controls the traffic going to and from agents. The docs describe routing Agent Runtime traffic and Gemini Enterprise traffic through a gateway, applying extensible policies, monitoring traffic, and configuring Model Armor on a gateway for content security.

Compare roles: Agent Identity decides who the agent is, Agent Registry decides what exists and is discoverable, and Agent Gateway inspects and governs the calls in between.

I am describing it from the documented structure; read the current gateway overview for exact capabilities.

A concrete picture: an agent on Agent Runtime calls an external MCP server. Instead of going directly, the call passes through the gateway, where policy can allow, block or inspect it, and the traffic is visible in monitoring.

The names are close, so clarify which one is meant. Agent Studio in the Gemini Enterprise Agent Platform is the low-code designer for general enterprise agents. CX Agent Studio is a separate low-code, Gemini-powered platform aimed at conversational customer-experience agents; community resources describe it as building on Dialogflow CX lineage and supporting root agents with sub-agents.

Product packaging evolves, so confirm against current Google documentation.

The practical difference shows in the console and docs you open. Agent Studio agents live under the Agent Platform's Agents page and deploy to Agent Runtime, while CX Agent Studio has its own documentation and console path.

It depends on size, freshness and who needs access. Knowledge files are the quick option for a small, static set; Agent Search through MCP suits larger or changing enterprise content.

Pick files for a pilot, then switch to search when limits or freshness start to hurt.

A hybrid also works: a small, stable policy file on the parent as knowledge, plus a search tool for the large catalog. Test both in Preview with questions whose answers exist only in one source, to see which one the agent actually used.

Use a root agent that triages and hands work to specialists.

flowchart TD
  U["Customer question"] --> R["Root triage agent"]
  R -->|billing| B["Local billing subagent"]
  R -->|technical| T["Registry A2A technical subagent"]
  R --> K["Knowledge files: policy FAQ"]
  B --> M["Registry MCP tool: orders"]
  T --> S["Agent Search MCP: product docs"]

Keep the policy FAQ as knowledge files on the root, since subagents cannot hold files. Write the root's instructions as clear routing rules. Make billing a local subagent, and reuse an existing technical specialist from Agent Registry. Grant each identity only what it needs, test with realistic chats in Preview, and read the event author to confirm routing before you deploy.

Test the routing with ambiguous messages too, such as a billing complaint that mentions a bug. If the root sends it to the wrong specialist, sharpen the routing rules in its instructions and the descriptions of the subagents.

Studio auto-saves changes but the docs do not describe a built-in release process, so treat the canvas as the prototype and put the release in code.

1. Use Get code to export the agent and commit it to a repository.
2. Continue in ADK, with the Agents CLI to scaffold, test and deploy.
3. Provision runtime agents with Terraform, which the platform documents for Agent Runtime.
4. Gate releases on offline evaluations, then deploy to Agent Runtime.

After the move, the repo is the source of truth. Editing the canvas copy afterwards would let the two drift apart.

Also keep a record of which Studio agent version produced the exported code, for example in the commit message, so reviewers can trace the repo back to the prototype that was tested.

Layer the controls, because no single setting covers everything.

1. Identity: rely on the per-agent identity and grant least-privilege roles, adding downstream roles manually and only where needed.
2. Tools: use MCP servers from Agent Registry, not direct endpoints, and turn off Google Search and URL context if the agent should stay closed-domain.
3. Data: keep sensitive files out of knowledge uploads, since anyone with project access can read the bucket.
4. Traffic: route calls through Agent Gateway and add Model Armor for content checks.
5. Quality and audit: run evaluations, set up monitoring and quality alerts, and watch traces and logs after launch.

Finish with a pre-launch review: confirm the roles on the agent principal match the tools list, no deprecated tools remain, the deployed region is approved, and an owner is named for alerts. That review catches most gaps that individual controls leave.