Full-Stack Engineer — GRiDD Technologies / GNet Connect · 2024 — Present
Gmail Support Agent for Internal Operations
A Gmail add-on that assembles account context, checks past resolutions for relevance, diagnoses the real issue, and drafts a grounded response for human review.
The workflow
- Source
- Where input enters
- Process
- Deterministic logic
- Model
- Where the LLM runs
- Memory
- Persistent context
- Output
- Committed booking
The problem
On most support tickets, the work isn't writing the reply — it's figuring out what actually happened. An agent has to read the email, pull up the customer's account, find the relevant reservation, check internal guidance, and remember how similar issues were resolved 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 and diagnosis problem. The system has to gather the right evidence, reject superficially similar precedent, identify the real fix, and only then draft language a human can review.
- 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.
- Past emails are useful only if the agent can tell whether they are genuinely relevant.
- Context has to be current at the moment of drafting, not stale.
- The final draft has to explain the concrete fix, not just summarize similar cases.
The approach
Bring the context and the reasoning path to the support person, inside the tool they already use. The support agent lives as a Gmail add-on: MCP-connected tools pull account and reservation state, a retrieval agent searches internal docs and resolved emails, and a relevance check keeps weak matches from driving the answer.
The draft comes after diagnosis. Similar resolved emails and wiki docs point toward likely fixes, but the agent still has to connect that precedent to the current account state and produce a concrete, grounded recommendation. The human still reviews and sends; the agent removes the gathering, comparison, and first-draft work without replacing judgment.
How it works
An inbound support email starts the workflow in Gmail. MCP tools look up the account and reservation while the retrieval agent searches the wiki and resolved-email store. Retrieved precedent passes through a relevance check; weak matches loop back for another search instead of being used as evidence.
Once the agent has relevant context, a diagnosis step pinpoints the actual issue and the fix. That diagnosis feeds a grounded draft, which the human reviews and sends from the Gmail add-on. If the human edits the response, the system diffs the sent version against the draft and routes useful corrections back into the resolved-email and wiki stores.
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.
- Retrieved emails and docs have to pass a relevance check before they can ground the draft.
- Diagnosis is separate from drafting, so the agent identifies the fix before writing the reply.
- Human edits are treated as feedback for the knowledge stores, not just one-off corrections.
- 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.
- The diagnosis step can still be wrong when the underlying account or reservation state is incomplete.
- 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.
- Learning from edits requires filtering; not every wording change should become new operational knowledge.
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.
- Relevant precedent became easier to reuse without copy-pasting old replies blindly.
- Human corrections became a signal for improving future drafts and internal docs.
- 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 MCP-connected account and reservation lookup pipeline.
- Created the knowledge base and embedding search over resolved support emails.
- Implemented the relevance-check and diagnosis stages that sit between retrieval and drafting.
- Implemented the grounded drafting flow and the human review-and-send experience.
- Built the edit-diff feedback loop for updating resolved-email precedent and wiki guidance.