AutoResolve
A customer side dispute agent for unresolved support cases.
Support friction often looks like a hard problem on paper, but in practice it is often slow follow-through and scattered context. AutoResolve is built to carry the operational load of dispute threads so persistence, timing, and alignment with the user’s objective do not depend on manual inbox babysitting.
Operating mode
Watch the thread continuously. Draft and send within guardrails. Pause and hand back when the case crosses sensitivity or policy judgment. Track state so the agent cannot drift into generic noise.
AI Agent Innovation Hackathon · 3rd place · built with Huaicheng Su in 48 hours
The product bet is not “more AI.” It is persistent case ownership on the customer side.
Origin
The friction came from delay and follow-through, not complexity.
AutoResolve started from a real frustration, not a theoretical problem. I had to spend a full week dealing with OpenAI support just to get a relatively simple issue fixed. The process was slow, repetitive, and unnecessarily exhausting. Every update required another email, more waiting, more checking, and more uncertainty about whether anything was actually moving forward. That experience made one thing obvious. A huge amount of support friction does not come from complexity. It comes from delay, inconsistency, and the lack of persistent follow through.
Intent
An email agent that stays on the case so the customer does not have to.
AutoResolve was built to attack that exact gap. Instead of leaving a customer stuck manually following up, checking inboxes, and rewriting the same context again and again, the system acts as an email agent that stays on the case continuously. It keeps track of the conversation, monitors for replies, sends follow ups when needed, and responds instantly within defined boundaries. The goal is not to replace the human user. The goal is to make sure the user is no longer carrying the full operational burden of getting a dispute resolved.
Pattern
Most dispute handling repeats the same shapes.
At its core, AutoResolve is designed around the idea that a large percentage of support and dispute handling follows repeated patterns. Customers ask similar questions, support teams respond with similar templates, cases get delayed in similar ways, and escalation points often follow recognizable structures. Once that pattern is clear, there is no reason the customer should have to manually manage every step of the process. The system can track the case, understand where it stands, and decide whether to respond automatically, escalate, or wait for human input.
Mechanism
Continuous monitoring, instant drafts, hard stops when judgment matters.
The way AutoResolve works is simple in concept but powerful in execution. A user connects their email and gives the system the dispute context. From that point onward, the agent watches the conversation continuously, keeps track of what has already been said, and reacts in real time when a new reply arrives. If a response is required, it drafts and sends it instantly based on the existing thread, the customer’s objective, and the rules defined for that case. If a situation crosses a safety threshold or becomes too sensitive, the system does not act blindly. It pauses, alerts the user, and routes the decision back to a human.
Control
Human in the loop is what makes it credible instead of reckless.
That human in the loop design is a core part of the system. AutoResolve is not trying to automate recklessly. Disputes can involve money, policy interpretation, refunds, account access, and sensitive personal context. In those cases, speed matters, but control matters more. The system is designed to automate obvious, repetitive follow through while preserving human oversight when judgment is needed. That balance is what makes the product credible instead of dangerous.
Safety
Built to behave safely on the customer side.
A major part of the build was making the system behave safely on the customer side. That meant introducing verification layers, guardrails around sending behavior, and alerting systems that prevent the agent from operating like an uncontrolled autoresponder. It continuously tracks the state of a case, watches for important changes, and ensures that actions stay aligned with the original objective instead of drifting into generic reply behavior. The result is an agent that feels less like a chatbot and more like a persistent operator working on behalf of the user.
Inversion
Automation built for the customer, not the queue.
From a product perspective, AutoResolve explores a shift that is likely to become increasingly important. Most support automation today is built for companies, not customers. Businesses use AI to reduce load, shorten queues, and deflect repetitive issues. The customer is still left doing the manual labor of chasing responses, keeping records, and managing escalation. AutoResolve flips that. It gives the customer their own system, one that operates with persistence and speed even when the support organization on the other side does not.
Hackathon
Built in two days around a use case people actually feel.
The project was built in collaboration with Huaicheng Su in just two days and went on to win 3rd place at the AI Agent Innovation Hackathon. What made it compelling was not just the use of an agent, but the clarity of the use case. This was not an abstract demo about AI handling tasks. It was a direct response to a frustrating, familiar workflow that millions of people deal with and almost nobody has meaningfully fixed.
Engineering
Orchestration, inbox truth, and local infrastructure for a serious prototype.
Technically, AutoResolve was built as a modern full stack system focused on orchestration, inbox monitoring, state tracking, and controlled automated response generation. The product layer was built with the standard web stack around Next.js, React, and TypeScript, while the backend logic handled email processing, queue based task execution, and persistent case management. Since the project was not deployed, the infrastructure was handled locally through Docker, with Redis used for coordination and stateful background processing. Gmail API integration formed a critical layer of the system because the product depended on continuous thread monitoring, real time context awareness, and safe outbound replies. The architecture was built around reliability and control rather than flashy demos.
Proof
Customer-side agents are overdue.
What AutoResolve proves is that customer side agents are not just possible, they are overdue. There is no reason dispute handling should still depend on a person manually checking their inbox every few hours, rewriting the same context, and hoping the next reply moves things forward. A persistent, well designed agent can do that work faster, more consistently, and with far less friction, while still keeping the human in control when it actually matters.
AutoResolve is not being presented as a finished company or a deployed product. It was a hackathon build. But it surfaced a very real insight. There is a large category of painful, repetitive support workflows where the customer is doing far too much manual work, and that is exactly the kind of problem an agent should be handling.
Stack
Web surface, durable state, and email-native orchestration.
Application
Runtime & data
Infrastructure
Integrations & orchestration
Closing
What happens when the customer gets the agent instead of the company.
AutoResolve was built fast, under pressure, and around a problem that came from lived frustration rather than abstract ideation.
It explored a simple but important shift. What happens when the customer gets the agent instead of the company.