Gmail Support Agent for Internal Operations
A Gmail add-on that retrieves account context, reservation data, internal knowledge, and similar resolved support emails before drafting a response for human review.
Product / Full-Stack Engineer — GRiDD Technologies / GNet Connect · 2024 — Present
System boundary
The agent does not auto-send replies. It prepares a grounded draft with retrieved context for the support team to review and send.
The problem
On most support tickets, the work isn't writing the reply — it's gathering what you need to write it. An agent has to pull up the customer's account, find the relevant reservation, and recall how a similar issue was handled before. That context lives across several systems and in people's heads.
The result was slow first responses, constant context-switching, and answers that varied depending on who picked up the email.
Why this needed a workflow, not a single call
A good support reply isn't a generation problem — it's a context-assembly problem. Answering well means pulling account context, reservation data, internal knowledge, and past resolutions, then grounding the response in them.
- Relevant context is spread across multiple systems, not in the email.
- The right context is scoped to a specific account and reservation.
- Answers should be grounded in how the team actually resolved similar issues.
- Context has to be current at the moment of drafting, not stale.
- Issue type drives what to look up and what to retrieve.
The approach
Bring the context to the agent, inside the tool they already use. The support agent lives as a Gmail add-on: it classifies the incoming issue, assembles account and reservation context through MCP-connected tools, retrieves similar previously resolved emails, and drafts a reply grounded in that precedent.
The human still sends. The agent's job is to remove the gathering and drafting work — not to replace the support person's judgment.
How it works
An incoming support email is classified by issue type. In parallel, MCP tools look up account and reservation context while an embedding search finds similar resolved emails in the knowledge base. Both feed a grounded draft that the agent reviews and sends — without leaving Gmail.
Key design decisions
- The agent never auto-sends — every reply is reviewed by a human.
- Context is assembled through composable MCP tools, not hard-coded lookups.
- Replies are grounded in resolved precedent, so answers stay consistent with the team.
- Issue classification drives what context to fetch and what to retrieve.
- It lives inside Gmail, the tool support already works in, instead of a new surface.
Limitations & failure modes
- Drafts are reviewed and sent by a human — the agent replies to no one on its own.
- Answer quality is bounded by knowledge-base coverage; novel issues have less precedent.
- Retrieval has to stay relevant, or drafts get grounded in superficially-similar cases.
- Handling account data responsibly (PII, access scope) constrains what it can surface.
- Context must be fresh at draft time; stale account or reservation data misleads the reply.
What it solved
- Agents open a ticket with context and a grounded draft already in front of them.
- First responses got faster by removing the manual gathering step.
- Answers became more consistent across the team.
- Cut the constant context-switching between separate systems.
What I built & owned
- Designed and built the Gmail add-on support agent end to end.
- Built the issue-classification and MCP-connected context-retrieval pipeline.
- Created the knowledge base and embedding search over resolved support emails.
- Implemented the grounded drafting flow and the human review-and-send experience.