From Circuits to Conversations: Deploying My First AI Agent on Cloud Run

Sundar Raj — Thu, 20 Aug 2026 06:22:34 +0000

I spend most of my working days a few layers below software — designing GaN MOSFET power stages, sensing circuits, and auxiliary supplies for automotive and data center hardware. So when I joined Google's Accelerate AI with Cloud Run (Gen AI Academy APAC, Cohort 3), I wasn't sure how much of it would click. Turns out, building an AI agent isn't so different from designing a well-behaved circuit: you define clear inputs, constrain the outputs, and make sure nothing misbehaves under edge cases.

The Build: An AI Barista That Doesn't Hallucinate

The project was a "Coffee Shop Journey" — Track 1 tasked me with building a customer-facing AI Barista agent. The requirements were simple to state, but the details mattered:

The agent should recommend drinks and pastries only from an actual menu — no invented items.
It should ask exactly one clarifying question when a request is vague ("something sweet" → hot or cold?).
It should respect dietary constraints like dairy-free tags and allergens.

I used Google's Agent Development Kit (ADK) to define the agent logic with LlmAgent, backed by Gemini. The interesting design choice was grounding: instead of pasting the entire menu into the system prompt, I gave the agent a get_menu() tool that reads a local menu.json file at runtime. It's the same instinct I'd apply in hardware — don't hardcode what can be looked up dynamically. It keeps the prompt lean and means the menu can change without redeploying anything (in production, you'd swap this for Firestore).

Wrapping It in Streamlit, Deploying to Cloud Run

The agent got a Streamlit front end — a chat interface with a sidebar showing the live menu, tags, and allergens. Deployment was where Cloud Run's source-based deploy genuinely surprised me: no Dockerfile, no manual container config.

bash
gcloud run deploy coffee-barista --source . --region asia-south1 ...

Cloud Run's Buildpacks inspected the directory, found requirements.txt and the Python files, and built a production container automatically. As someone used to bring-up involving actual hardware validation, watching a full build-and-deploy pipeline finish in under five minutes was satisfying in a different way.

Security Wasn't an Afterthought

One detail I appreciated: the codelab pushed least-privilege IAM from the start. Instead of running the service under the default Compute Engine service account (which carries broad Editor permissions), I created a dedicated barista-agent-sa scoped to exactly one role — roles/aiplatform.user. If the app is ever compromised, the blast radius is contained to "can call Gemini," not "can touch the whole project." It's the same defense-in-depth thinking I apply to protection circuits — isolate the fault, don't let it propagate.

What's Live

The agent is deployed and answering questions in real time:

coffee-barista-445013685264.asia-south1.run.app

Ask it for something dairy-free, something vague, or something that isn't on the menu — it holds its ground.

Why This Matters to Me

I work on hardware that increasingly exists to serve AI workloads — power delivery for AI servers, sensing for safety-critical systems. Understanding the software layer that actually runs on top of that hardware, even at a beginner level, makes me a better engineer at the board level too. Knowing how an agent grounds itself, what a token-cost tradeoff looks like, or why an IAM role matters isn't just software trivia — it's context that shapes better system-level design decisions.

On to Track 2 next: using Gemma 4 and BigQuery to help this coffee shop pick its next physical location.

DEV Community: Sundar Raj

From Circuits to Conversations: Deploying My First AI Agent on Cloud Run