Your Gmail should have an AI assistant — AI agent for Gmail
Details
# Building and Deploying a Real AI Agent
Join us for the next Building and Marketing AI Applications/Agents Meetup, where we’ll go beyond prompts and prototypes and look at what it takes to build an AI agent that can actually do useful work — while staying inside clearly defined boundaries.
For this session, we’ll demonstrate a working Gmail AI Agent designed to help handle customer email while keeping a human in control.
We are looking for beta testers and if you are interested, please fill the short form and we will be in touch. You will be shaping our Gmail Agent the way you see it!
## Talk: Building and Deploying a Real AI Agent
Calling an LLM and asking it to write an email is easy.
Building an agent you are comfortable connecting to customer email, business systems, databases, or infrastructure is a different engineering problem.
In this live demo, we’ll follow a Gmail AI Agent as it processes real-world-style customer messages and decides:
Can Gmail ai agent understand this request?
Does Gmail ai agent have the information and tools needed to handle it?
Is Gmail ai agent authorized to act?
The workflow is intentionally simple:
Email arrives → Gmail ai Agent understands the request and sentiment → Agent evaluates available tools, information, and policies → AI drafts a response → Human reviews → Human decides whether to send
There is also an equally important exception path:
Email arrives → Agent cannot safely or confidently handle it → Gmail moves it to “Need Attention” label → Human takes over
The goal is not to make the AI respond to every email.
The goal is to make the agent useful when a request falls within its capabilities — and predictable when it does not.
## What makes this an agent?
The interesting part isn’t simply generating an email.
We built an agent harness that surrounds the model that controls how it operates:
- What tools the agent can use ?
- What data and policies it can access ?
- How incoming requests are classified ?
- How customer sentiment influences the response ?
- How structured outputs are validated ?
- What actions the agent is authorized to take ?
- What happens when information is missing or ambiguous ?
- How unsupported requests are routed ?
- Where human approval is required ?
- How every run can be inspected afterward ?
During the demo, we’ll walk through the architecture behind the Gmail agent, including:
Pydantic AI, Gmail API integration, structured model outputs, tool and permission boundaries, sentiment-aware responses, human-in-the-loop approval, run history, failure handling, and isolated agent execution.
We’ll also explore using Firecracker microVMs as an execution boundary, giving agent workloads their own lightweight virtualized environment instead of allowing agent-controlled execution to run directly on the host.
We power it by Open wt Model:
Qwen
## Human-in-the-loop by design
Even when the agent successfully handles a request, it does not send the email.
It creates a Gmail draft.
A human reviews the proposed response and decides whether to send, modify, or reject it.
That gives us two human-review paths:
Normal path:
Agent drafts → Human reviews → Human sends
Exception path:
Agent cannot safely handle the request → Need Attention → Human takes over
Human review is not an afterthought. It is part of the agent’s authority model.
## Live Demo: Five Emails
We’ll test the agent against five different customer-email scenarios and see how it responds.
### Email 1 — Positive / appreciative
Subject: Thank you — the onboarding session was great
A customer thanks the team for an onboarding session and asks about arranging a follow-up.
Expected behavior:
The agent drafts a warm response and asks which day works, without selecting a meeting time or confirming a booking it does not have authority to make.
### Email 2 — Frustrated / angry
Subject: Still no response — order #4471
A customer says they were charged twice and demands a refund.
Expected behavior:
The agent acknowledges the frustration, preserves the order reference, and prepares an empathetic response — without inventing a refund date or promising a refund it has not been authorized to issue.
### Email 3 — Confused / uncertain
Subject: Not sure which invoice this is for?
A customer receives an invoice whose reference does not match their records.
Expected behavior:
The agent asks for the relevant reference or offers to investigate using available tools, without inventing invoice or project details.
### Email 4 — Urgent / anxious
Subject: URGENT — can't log in before our board meeting
A customer cannot access their account shortly before an important meeting.
Expected behavior:
The agent acknowledges the urgency and asks for the information needed to investigate, without inventing a cause, fix, or resolution timeframe.
### Email 5 — Neutral / no reply needed
Subject: FYI — payment sent
A customer simply confirms that payment was sent and explicitly says no action is required.
Expected behavior:
The agent recognizes that no response is needed and does not create a draft.
This is just as important as generating a good reply: sometimes the correct agent action is to do nothing.
## Knowing when not to respond
One of the most important parts of the demo is seeing what happens when the agent reaches the edge of its capabilities.
If the agent needs information it cannot access, encounters an unsupported request, cannot reconcile the request with available policies, detects ambiguity, or otherwise cannot safely produce a response, it should not improvise.
The message moves to:
Need Attention
That gives the system a predictable landing zone for requests the agent is not prepared to handle.
Instead of trying to make the model smart enough to answer everything, we design the system so uncertainty fails safely into human review.
## The bigger question
Building an AI agent demo is relatively easy.
Building one you are comfortable connecting to Gmail, customer systems, databases, infrastructure, or other business applications is much harder.
A production agent needs to know not only:
“Can I answer this?”
but also:
“Do I have the tools, information, and authority to handle this correctly?”
And when the answer is no, the system needs a predictable and safe place to land.
That is what this meetup is about:
How do we move from “the model can do this” to “this is a system I can safely deploy”?
Builders, founders, engineers, product teams, and anyone experimenting with AI agents are welcome.
Come see the Gmail agent run, examine the architecture, challenge the boundaries, and help us explore what production AI agents should look like.