Inspiration
AI support agents become useful coworkers only when operations managers can see their tools, cost, evidence, and approval boundaries before a customer-facing action.
Gemini Operations Navigator was built around that idea: do not hide the operational controls. Make the agent's workflow understandable before it drafts, escalates, or sends.
What it does
Gemini Operations Navigator is for support operations managers handling refund and escalation queues.
A customer asks for a renewal refund. The workflow retrieves refund policy through MCP-style tools, checks recent usage, drafts a grounded response with Gemini, records projected cost, exports an Arize/OpenInference-compatible trace, verifies the Arize Phoenix MCP server interface, and blocks the customer-facing send until a manager approves it.
The public demo includes:
- terminal transcript
- MCP tool trace
- Arize/OpenInference-compatible span trace
- cost ledger
- approval checkpoint
- Phoenix MCP runtime proof
- Vertex AI rerun status report
- Agent Builder-ready runtime manifest
- workflow UI
- architecture diagram
- narrated demo video
How we built it
The project is a Python + HTML/CSS workflow package with JSON/JSONL evidence artifacts. The agent run writes a replayable tool trace, OpenInference-compatible spans, a cost ledger, an approval checkpoint, and browser-viewable proof pages.
For the partner track, the submission now launches the actual Arize Phoenix MCP server over stdio, completes JSON-RPC initialize and tools/list, and records the observed Phoenix tool surface in rapid-agent/reports/phoenix-mcp-runtime-proof.json.
For Google Cloud, the repo includes an Agent Builder-ready runtime manifest covering model, MCP, tools, budget policy, and human approval. The current Vertex rerun report is also committed. It records the real Google Cloud account state instead of claiming a live generation when the project consumer is suspended.
Challenges
The main challenge was keeping the submission honest while still making it useful for judges. Google Cloud credit/account state changed during the hackathon, so the project now records the current Vertex rerun status as evidence and stays inside a no-out-of-pocket guardrail. That avoids pretending a production deployment exists while still proving the agent workflow, observability path, and approval boundary.
Accomplishments
- Made the target user and problem explicit: support operations managers need auditable AI before refund replies are sent.
- Added Phoenix MCP runtime proof with 27 exposed tools, including list-projects, list-traces, get-spans, and phoenix-support.
- Added an Agent Builder-ready runtime manifest for model, MCP, tools, budget, and approval policy.
- Strengthened the public demo page so judges can open proof artifacts directly.
- Kept customer-facing financial action blocked until human approval.
What we learned
A useful AI agent is not just a model response. It needs evidence, traceability, cost visibility, and a clear human-control point. That operational layer is what makes an agent safe enough for support workflows.
What's next
Next steps are to attach a healthy Google Cloud project for a production Vertex/Agent Builder deployment, import the OpenInference spans into Phoenix, and connect the approval checkpoint to a real support queue after manager review.
Built With
- agent-builder
- agent-development-kit
- arize
- cost-guardrails
- css
- edge-tts
- ffmpeg
- gemini
- github
- google-cloud
- html
- human-approval
- imagemagick
- json
- jsonl
- mcp
- openinference
- phoenix-mcp
- python
- vertex-ai

Log in or sign up for Devpost to join the conversation.