Vertex AI Agent Builder now lives under Gemini Enterprise Agent Platform, with Vertex AI Studio renamed Agent Studio. This guide builds a warranty-claims triage agent there: it grounds answers in your policy documents through a data store tool, checks claim history through a custom tool, and only recommends approve or deny, a human rep decides in your claims system. No code, a low-code flow builder on Google Cloud, budget 30-45 minutes.
| Fact | Value |
|---|---|
| Tool | Gemini Enterprise Agent Platform |
| Difficulty | Intermediate |
| Time required | 30-45 min |
| Compatibility | Google Cloud project with billing enabled, Agent Platform User IAM role, browser only |
| Last updated | November 2026 |
What you'll build
You'll build a warranty-claims triage agent for a retailer's support team. A rep pastes in a claim description, and the agent grounds its answer in the company's warranty policy documents, checks the customer's claim history through a custom tool, and recommends approve, deny, or escalate with its reasoning. It never updates the claims system itself; that stays a rep's decision, made in the real system after reading the recommendation.
The product you're looking for used to be called Vertex AI Agent Builder, built on Vertex AI Studio. Both are now Agent Studio, part of Gemini Enterprise Agent Platform, Google's renamed and consolidated agent platform. In the console, you create an agent, then either describe it in a chat prompt or use the flow builder to set its name, description, instructions, and model, and click Add tools to attach a data store for grounding or a custom tool for an external API call. A Preview tab lets you test it and inspect exactly which tools fired on each turn before you save or deploy it.
Choose Agent Studio when your team is already on Google Cloud and you want grounding against your own documents plus a real API call, without writing an ADK agent by hand. If you want full code control over the same agent, or need to deploy it outside Google Cloud, the Google ADK guide builds an equivalent agent as a Python script instead.
Prerequisites
- A Google Cloud project with billing enabled
- The Agent Platform User IAM role (roles/aiplatform.user) granted to your account
- Your warranty policy documents as PDFs or text files for the data store
- A claims-lookup API (or a mock endpoint) and its OpenAPI schema for the custom tool
Step-by-step guide
Get access and open Agent Studio
Ask your Google Cloud admin to grant your account the Agent Platform User role (roles/aiplatform.user) on the project, then open the Agents page in the console. If you land on an older Vertex AI Agent Builder bookmark, follow it through; Google redirects the old URLs to the renamed product.
1IAM role needed: roles/aiplatform.user ("Agent Platform User")2Console: Agents page -> Create agentExpected result: The Agents page loads with a Create agent button, confirming your role is active.
Create the agent and write its instructions
Click Create agent to open the Agent Studio canvas. You can describe the agent in a chat prompt and let it draft a starting configuration, or go straight to the flow builder and fill in Name, Description, Instructions, and Model yourself. Either way, end up with explicit instructions that state the one rule that matters: recommend, never execute.
1Name: Warranty Claims Triage2Instructions:3"You triage warranty claims for our retail support team. For every claim, check the policy documents and the customer's claim history, then recommend approve, deny, or escalate with your reasoning. You never update the claims system; a human rep makes that decision after reading your recommendation."Expected result: A new agent named Warranty Claims Triage appears on the Agents page with its instructions saved.
Ground it with a data store tool
Click Add tools (the + icon) and attach a data store built from your warranty policy documents. This grounds the agent's answers in the actual policy text instead of general knowledge about warranties, and lets it cite the specific clause behind a recommendation.
1Add tools -> Data store2Source: warranty-policy-docs (your uploaded PDFs)3Grounding: enabledExpected result: A test question like "what's covered under the 1-year warranty" returns an answer citing a specific uploaded document.
Add the claims-lookup custom tool
Add a second tool, this time a custom tool backed by your claims API's OpenAPI schema, the same mechanism a GPT Action or an n8n HTTP Request Tool uses under a different name. Scope it to a read-only endpoint; this tool checks history, it doesn't change anything.
1Add tools -> Custom tool -> Import OpenAPI schema2Endpoint: GET /customers/{customer_id}/claims3Authentication: API key (stored with the tool, not in instructions)Expected result: Asking the agent about a test customer's claim history triggers a visible tool call and returns real past-claims data.
Test in Preview and inspect the run events
Use the Preview tab to run a few realistic claims through the agent and check two things: that it actually calls both tools rather than guessing, and that its final recommendation stays in the approve, deny, escalate vocabulary you asked for instead of drifting into something like 'I've approved this,' which would misrepresent what the agent can actually do.
1Preview tab:2Input: "Customer says their blender motor failed after 8 months, has 2 prior claims."3Inspect: run events panel shows data-store lookup + claims-lookup tool call before the final response.Expected result: The run events panel shows both tools firing in order, and the response ends with a clear recommend-only statement.
Save, then decide between Get code and Deploy
Save the agent from the canvas header. From here you have two paths: Get code exports the agent's configuration if you want to move it into an ADK-based codebase for tighter version control, and Deploy ships it directly to Agent Runtime, Google's managed hosting for Agent Studio agents, with no code export needed.
1Canvas header -> Save2Then either:3Get code (export to ADK-based project), or4Deploy (ship to Agent Runtime directly)Expected result: The agent shows status Active in Agent Runtime, or a code export ready to drop into an ADK project, depending on which path you chose.
Harden the data store and tool scope before go-live
Narrow the data store to only the warranty policy documents, not your whole company's document library, and confirm the claims-lookup tool's API key is read-only. Note that agent configurations in Agent Studio are currently stored in the us-west1 region; confirm that fits your data-residency requirements before deploying with real customer data.
1Checklist before go-live:2- Data store scoped to warranty-policy-docs only3- Claims-lookup API key is read-only4- Region (us-west1) confirmed against data-residency requirementsExpected result: A final test run touches only the intended documents and the intended read-only endpoint, with no broader data exposure.
Complete working example
1# Agent Studio configuration for the Warranty Claims Triage agent.2# Exported via "Get code"; shown here so you can see exactly what the3# flow-builder steps above produce. Edit through the canvas or this file,4# not both at once, so they don't drift.5name: warranty-claims-triage6displayName: Warranty Claims Triage7instructions: |8 You triage warranty claims for our retail support team. For every claim,9 check the policy documents and the customer's claim history, then10 recommend approve, deny, or escalate with your reasoning. You never11 update the claims system; a human rep makes that decision after reading12 your recommendation.13model: gemini-3.8-flash14tools:15 - type: data_store16 name: warranty_policy_docs17 description: Company warranty policy documents, grounded for citation.18 source: projects/my-project/locations/us-west1/dataStores/warranty-policy-docs19 - type: custom_tool20 name: get_claim_history21 description: Look up a customer's prior warranty claims by customer ID. Read-only.22 openapi:23 path: GET /customers/{customer_id}/claims24 server: https://claims.example-retailer.com/api25 authentication:26 type: api_key27 location: header28 name: X-Api-Key29outputConstraints:30 allowedRecommendations: [approve, deny, escalate]31 mustCiteTool: true32Common mistakes
Why it's a problem: Looking for 'Vertex AI Agent Builder' in the console navigation and assuming it's gone because the name doesn't appear
How to avoid: It's been renamed to Agent Studio under Gemini Enterprise Agent Platform. Old bookmarks and documentation links to Vertex AI Agent Builder redirect there.
Why it's a problem: Grounding the agent against your entire shared document library instead of a scoped data store
How to avoid: Build a data store from only the documents this agent needs. A broadly scoped data store both dilutes answer quality and exposes documents that have nothing to do with warranty claims.
Why it's a problem: Letting the instructions allow phrases like 'I've approved this claim'
How to avoid: State the exact vocabulary the agent is allowed to use (recommend, not execute) so a rep reading its output can't mistake a recommendation for a completed action.
Why it's a problem: Skipping the Preview tab's run events panel and only reading the final chat response
How to avoid: The run events panel is what actually shows whether the data store and the custom tool fired. A plausible-sounding answer can still be wrong if it skipped the tools entirely.
Why it's a problem: Deploying with real customer data before confirming the us-west1 storage region fits your data-residency requirements
How to avoid: Check this before go-live, not after a compliance review flags it. It's a fixed property of where Agent Studio stores agent configurations today, not a per-agent setting you can change later.
Best practices
- Scope every data store to exactly the documents the agent's task needs, not your whole organization's shared drive.
- Keep custom tools read-only wherever the downstream action has real consequences; let a human execute the write in the real system.
- Constrain the agent's allowed output vocabulary explicitly (approve, deny, escalate) instead of letting it phrase conclusions freely.
- Use the Preview tab's run events panel on every meaningful change, not just the chat response, to confirm tools actually fired.
- Export with Get code once the agent is stable, so its configuration lives in version control instead of only in the canvas.
- Re-check IAM roles and data store scope before every production deploy; both are easy to over-grant early and forget to narrow later.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a Google Agent Studio agent configuration (YAML below) with a data_store tool for warranty policy docs and a custom_tool for claim history lookups, constrained to recommend approve/deny/escalate only. Design a third tool for checking whether a product is still within its registered serial-number warranty window. [paste complete_code]
In Agent Studio's chat-based creation flow, prompt: 'Add a rule that if get_claim_history returns more than 3 prior claims for a customer, the agent should always recommend escalate instead of approve or deny on its own.'
Frequently asked questions
Where did Vertex AI Agent Builder go?
It's been renamed Agent Studio, part of Gemini Enterprise Agent Platform, Google's consolidated name for what used to be Vertex AI Studio and Vertex AI Agent Builder together. Old links and documentation redirect to the new name.
What happened to Vertex AI Agent Engine?
It's now called Agent Runtime, still the managed hosting layer you deploy an Agent Studio agent to, or an ADK-based agent you built in code.
Do I need to write any code to build this agent?
No. Every step in this guide happens on the Agent Studio canvas: describing the agent, adding tools, and testing in Preview. The YAML in complete_code is what Get code exports if you later want to move the same agent into a code-based ADK project.
What's the difference between a data store tool and a custom tool?
A data store grounds the agent's answers in documents you upload, like the warranty policy PDFs here. A custom tool calls a real API through an OpenAPI schema, like the claims-lookup endpoint, so the agent can check live data instead of only referencing static files.
Can this agent also add subagents for more complex workflows?
Yes. Agent Studio's flow builder supports adding subagents, either built locally in the same project or pulled from an Agent Registry, so a more complex version of this triage agent could hand off escalated claims to a dedicated escalation subagent.
What does this cost to run?
You pay standard Gemini model token pricing per agent turn, plus data store and Agent Runtime compute while it's deployed. A single triage conversation with a data store lookup and one custom tool call typically costs a fraction of a cent on Gemini 3.8 Flash.
Can someone build this for me instead of configuring it myself?
Yes. RapidDev builds production agents on Agent Studio, Google ADK, and the Claude Agent SDK, including the grounding and approval-boundary work most tutorials skip. A free 30-minute consultation is the fastest way to scope your version.
Talk to an Expert
Our team has built 1,000+ apps. Get personalized help with your project.
Book a free consultation