When my team sat down for our hackathon, we had one goal: build something that solves a real problem. Not a toy. Not a demo that only works when you hold it exactly right. A real tool that engineers would actually want to use at 2am when their servers are on fire.
That's how RecallOps was born.
The Problem We Were Solving
Every engineering team has been there. An alert fires at 2am. The on-call engineer scrambles to figure out what's wrong. They dig through old Slack messages, search through runbooks that haven't been updated in months, and try to remember if this exact error happened before. By the time they find the answer, 45 minutes have passed and the damage is done.
The knowledge exists. It's just scattered everywhere and impossible to find under pressure.
RecallOps fixes this by giving your AI agent a memory. Every incident gets stored. Every fix gets remembered. The next time something similar happens, the agent recalls what worked before and tells you in seconds.
My Role: Building the Face of RecallOps
I was responsible for the React frontend — the thing users actually see and interact with. In a hackathon, the UI is everything. You can have the most powerful backend in the world but if the interface is confusing or ugly, judges and users will dismiss it in seconds.
My goals for the frontend were simple:
- Make it feel like a professional product, not a student project
- Make the memory feature visible and obvious
- Tell the story of what's happening in real time
The Tech Stack
We built the frontend using React with Vite as our build tool. For styling I used pure CSS with CSS variables — no heavy UI library. The dark color scheme was intentional. Incident response always happens at night, so the interface should feel at home in the dark.
The three-panel layout was the core design decision:
- Left panel: Chat interface where engineers paste errors
- Middle panel: AI response with fix recommendations
- Right panel: Context panel showing past similar incidents from memory
This layout made the memory feature impossible to miss. When you paste an error, you immediately see the related past incidents appear on the right. The connection between "what happened now" and "what happened before" is visual and instant.
Building the Chat Interface
The chat component was the most important piece. I wanted it to feel familiar — like Slack or any modern chat app — but with incident-specific features baked in.
Each message bubble shows the timestamp and the role (user vs agent). When the agent is thinking, a typing indicator shows with a status message like "Searching incident history..." followed by "Match found — drafting fix." This gives the user real-time feedback that something meaningful is happening, not just a spinner.
The suggested prompts on the empty state were a nice touch. Instead of staring at a blank input box, engineers see pre-filled examples like "ConnectionPoolTimeoutError on auth-service" with a match label showing "94% match." This immediately communicates what the tool does and how good it is at finding past incidents.
The Context Panel: Making Memory Visible
The right panel was the hardest part to get right. This is where Hindsight's memory layer becomes visible to the user.
After the agent responds, the context panel updates with:
- Memory Summary: How many total incidents are remembered and how many are relevant to the current query
- Related Previous Conversation: The most similar past incident, with the match score, date, and a summary of how it was resolved
- Personalized Recommendation: A specific suggested fix with confidence level and estimated resolution time
The "Memory active" badge in the header was a small but important detail. It tells the user that the agent isn't just a generic chatbot — it has context, history, and institutional knowledge.
Connecting to the Real Backend
Initially the frontend used mock data. This was the right call for Day 1 — it let us build and style the UI without waiting for the backend to be ready. But on Day 2, we swapped the mock data for real API calls to our FastAPI backend.
The key change was in AppContext.jsx — the central state management file. Instead of returning hardcoded responses after a timeout, the sendMessage function now makes a real fetch call to http://localhost:8000/api/query. The response comes back with the agent's fix recommendation, the similar past incidents, the model used, and the cost. All of that data flows into the UI automatically.
What I Learned
This hackathon taught me more about building real products than any tutorial ever could. A few things that stuck with me:
Design for the story, not the features. Every UI decision should help tell the story of what the product does. The three-panel layout doesn't just look nice — it makes the before and after of memory-powered AI immediately obvious.
State management is the hard part. React components are easy. Managing shared state across a complex multi-panel interface with real-time updates is where things get tricky. Using React Context properly made this manageable.
Mock data first, real data second. Building the UI against mock data first meant we could iterate on design without being blocked by backend development. When the backend was ready, swapping in real data took less than an hour.
Dark mode is a feature, not a preference. For incident response tools, dark mode isn't optional. Engineers working at 2am with high stress don't need a blinding white screen.
The Result
RecallOps works. You paste an error. The agent searches 30 past incidents stored in Hindsight memory. It finds the most similar ones, uses cascadeflow to pick the right AI model, calls Groq for a fast response, and returns a specific fix recommendation with the model used and cost. The whole thing takes about 3 seconds.
The context panel updates with real data from the backend — the actual incident ID, the actual fix that worked before, the actual resolution time. Not mock data. Real memory.
That's what makes RecallOps different from every other chatbot demo. It remembers. And the UI makes sure you can see that it remembers.
What's Next
RecallOps started as a hackathon project but the problem it solves is real and the market is huge. Every engineering team deals with incident response. Every on-call engineer has wasted hours searching for answers that already exist somewhere in their history.
The next version would add automatic incident ingestion from PagerDuty and Slack, a postmortem generator that writes itself from past incident data, and team-level analytics showing which systems fail most often and which fixes have the best success rate.
But for now — we shipped it. In two days. And it works.
That's the best feeling in software development.
Top comments (0)