AutoResolve
A customer-side email agent that watches a support thread, tracks the case, sends guarded follow-ups, and hands back to a human when a reply needs judgment.
Hackathon build2026BuilderAI Agent Innovation Hackathon · 3rd placewith Huaicheng Su
TL;DR
- A week spent chasing OpenAI support showed the problem was not difficulty, it was follow-through: companies run agents on their queue, customers still work theirs by hand.
- AutoResolve gives the customer an agent inside the existing Gmail thread, so neither side has to adopt a new tool.
- The loop: connect Gmail and state the objective, a worker tracks the case, routine turns get drafted and sent, and anything sensitive is handed back.
- The hard parts were knowing when not to send — refunds, account access, money, policy — and keeping a structured case record so a long thread is not read as a new conversation each time.
- Next.js front end, Node workers on a Redis queue, PostgreSQL for case state, the Gmail API for the thread, all in Docker.
- Third place in 48 hours at the AI Agent Innovation Hackathon, built with Huaicheng Su. Never run on a real inbox.
Where it started
A simple support issue took a week because nobody owned the follow-through.
I spent a week going back and forth with OpenAI support over something that was not difficult to resolve. The work was checking for replies, repeating context, sending another follow-up, and making sure the thread did not quietly die. The company had a system for its queue. I was still managing the case by hand from my inbox.
AutoResolve gives the customer their own agent on the other side of the support queue.
The product
It stays with the case so the customer does not have to.
The user connects Gmail, explains the dispute once, and defines the result they are trying to reach. From there the agent watches the existing support thread. It remembers what has already happened, sends routine replies and follow-ups, and brings the user back only when the next move requires an actual decision.
It is not a chatbot window and it does not ask the support company to use a new tool. It works inside the email conversation that already exists, which lets it carry the repetitive operational part without changing how either side communicates.
How a case moves
One loop, with a clear boundary between persistence and judgment.
01
Give it the case
The user connects Gmail and explains what happened, what outcome they want, and what the agent is never allowed to agree to.
02
Let it watch the thread
A worker follows new replies and maintains a case record: what has been said, what was promised, what remains unresolved, and when a follow-up is due.
03
Respond when the answer is safe
For routine turns the agent writes from the full thread and the user's objective, sends the reply, and schedules the next check.
04
Stop when judgment matters
Refund terms, account access, money, and policy decisions are handed back to the user. Their decision becomes part of the case and the agent continues from there.
What was difficult
The useful agent is the one that knows when not to send.
An ordinary autoresponder is dangerous here. A support thread can involve refunds, access to an account, policy language, or an offer the user should read before accepting. The agent therefore works from an explicit case objective and checks every action against a sensitivity boundary. When a reply crosses it, doing nothing is the correct automated action.
The second problem was memory. A long support thread contains repeated templates, partial answers, and promises made days earlier. Keeping a structured case record next to the raw email thread is what stops the agent from treating every new message as a fresh conversation.
How it was built
A small event-driven system behind an ordinary inbox.
Case setup
Next.js
Connect Gmail, define the objective, and review anything the agent pauses
Case loop
Node.js workers
Read the thread, decide what happens next, draft, and send
Redis
Schedule inbox checks and follow-ups without holding a request open
Case memory
PostgreSQL
Keep the objective, thread state, decisions, and alerts together
Gmail API
Read and reply inside the existing support conversation
Everything ran locally in Docker for the hackathon. Redis handled the delayed work, PostgreSQL held the case, and Gmail remained the source of truth for the conversation.
Stack
Interface
Workers & data
Integration
Local infrastructure
Where it stands
Third place in 48 hours, and a useful product direction.
I built AutoResolve with Huaicheng Su at the AI Agent Innovation Hackathon. It was a working demo, not a deployed service, and it has not been run on anyone else's inbox. What stayed with me was the inversion: companies already use agents to manage customers, but customers still do the work of managing companies.
