Inspiration
Working in technical support, I've seen how frustrating troubleshooting can become when customers have to repeat their problems, explain what they've already tried, or start over whenever a case is revisited.
I wanted to explore a different approach: what if an AI assistant could remember the entire troubleshooting process and help someone move toward a resolution without losing that context?
That idea became AfterCare, a conversational support assistant designed around continuity. Instead of treating every interaction as a new question, it treats troubleshooting as an ongoing process.
The Amazon App Dev Challenge gave me an opportunity to explore how an Alexa+-style assistant could go beyond answering questions and actually help manage a support workflow.
What it does
AfterCare is a simulated Alexa+-style AI assistant that helps users describe product problems, work through troubleshooting instructions, and maintain a persistent support history.
Users can interact through natural-language messages instead of relying entirely on traditional forms.
For example, someone can say:
"My lamp keeps flickering. I checked the power, but it's still happening."
AfterCare can interpret that report, associate it with the current troubleshooting step, record the reported outcome through its validated backend, and guide the user toward the next available check.
The application can:
- Understand conversational input: Interpret symptoms, troubleshooting results, and follow-up responses using a locally running AI model.
- Remember previous interactions: Store conversations and support-case information in SQLite so users can return without starting over.
- Track troubleshooting progress: Record user-reported outcomes and maintain an activity history.
- Correct mistakes: Support conversational undo while preserving an audit trail.
- Prepare support requests: Generate reviewable drafts containing reported symptoms and recorded troubleshooting results.
- Keep users in control: Never automatically send support requests or submit warranty claims.
The current prototype uses a fictional desk lamp and sample troubleshooting instructions. It demonstrates the workflow without claiming to diagnose real hardware or verify actual warranty coverage.
How we built it
I built AfterCare primarily in Go, using SQLite for persistence, Go's html/template package for server-rendered pages, and vanilla JavaScript and CSS for the browser interface.
For conversational AI, I integrated Qwen3 4B through Ollama, running locally on my ThinkPad P15 Gen 2i with an NVIDIA RTX A2000 GPU.
One of the most important architectural decisions was separating language interpretation from application actions.
The AI interprets what a user says, but the Go backend determines whether a proposed action is valid. For example, the model cannot simply decide that a troubleshooting check was completed. The application verifies the reported information against the current case and workflow before recording a result.
SQLite stores support cases, conversation history, troubleshooting events, and related workflow context. Database transactions and version checks help keep those records consistent.
I also added a rule-based fallback for situations where the local model is unavailable or its interpretation cannot be accepted safely.
Everything runs locally, without requiring paid cloud APIs. AfterCare is an independent simulation of an Alexa+-style experience, not an integration with the official Alexa+ platform.
Challenges we ran into
The biggest challenge was making the AI genuinely conversational while keeping its actions accurate.
Early versions of AfterCare behaved too much like a troubleshooting form. The assistant could understand messages, but users still had to click buttons or repeatedly confirm information to advance the case.
Moving toward a conversation-first design introduced another challenge: understanding what the user actually reported versus what the AI inferred.
For example, "The brightness is turned all the way up" establishes that the user checked a setting, but it doesn't necessarily establish whether the problem was resolved.
We also encountered conversation loops where the assistant repeatedly asked questions that had already been answered. Ollama occasionally misclassified messages or associated observations with the wrong troubleshooting step.
Addressing these problems required more than changing the model prompt. I worked on improving contextual interpretation, validating extracted information in Go, and making fallback responses more relevant to the active case.
Running AI locally presented its own challenges, particularly GPU memory limitations and response latency. I experimented with bounded context, shorter responses, and disabling unnecessary model reasoning to make interactions more responsive.
These issues reinforced how much work goes into building a reliable AI application beyond simply connecting to a language model.
Accomplishments that we're proud of
My biggest accomplishment is building an application that connects natural-language conversation to persistent, validated actions.
AfterCare can maintain a support case across server restarts, remember recorded troubleshooting outcomes, and produce a useful summary of what happened.
I'm particularly proud of the separation between AI interpretation and backend execution. The language model helps understand the conversation, but Go controls the actual workflow and database updates.
Another feature I'm proud of is conversational undo. Users can correct a recorded result without simply erasing the original history.
I also built and tested the application using my own local hardware, without relying on paid inference services.
While AfterCare is still a prototype, it demonstrates how conversational AI can support an actual process rather than functioning only as a question-and-answer interface.
What we learned
This project taught me that building an AI assistant is not just about generating good responses. It's about maintaining reliable context and turning language into trustworthy actions.
A model might produce a convincing answer while misunderstanding the user's intent. That means important operations need validation outside the model.
I also learned how valuable structured state is for conversational applications. A conversation transcript alone isn't always enough; the application needs to know which troubleshooting step is active, which outcomes have been recorded, and what information is still missing.
Working with local inference also gave me practical experience managing context limits, latency, structured outputs, fallback behavior, and hardware constraints.
Most importantly, the project reinforced the importance of designing around the user's actual experience. A technically correct system can still feel frustrating if it repeatedly asks questions or forces unnecessary interactions.
What's next for AfterCare
The current prototype focuses on proving that persistent conversational support can work.
The next step would be expanding beyond the fictional desk lamp to support real products using verified manufacturer documentation and clearly sourced troubleshooting instructions.
I'd also like to improve conversational memory, handle more complex and non-linear troubleshooting situations, and make the assistant better at understanding corrections and incomplete responses.
Other future improvements include optional voice interaction, stronger privacy controls, additional product-support workflows, and verified warranty-information retrieval.
Longer term, I envision AfterCare as an assistant that could help bridge the gap between customers and support teams by organizing useful troubleshooting information before a case reaches a human agent.
The goal isn't to replace customer support. It's to make the process less repetitive, more organized, and easier for everyone involved.
Log in or sign up for Devpost to join the conversation.