ERRBASE

Inspiration

Honestly this came from pure frustration. You fix a weird error, move on with your day, and then two months later the exact same thing happens again and you're sitting there thinking "wait, didn't I already deal with this?" You dig through old terminal scrollback, half-remember a Stack Overflow answer, maybe find it in your browser history if you're lucky. Your shell history just has the command you ran, not why it worked.

Then we started leaning more on AI coding agents like Claude Code, and noticed something kind of funny — they're actually really good at debugging while you're working with them, but the second that session ends, it's like it never happened. Ask it about the same bug next week and it's starting from zero again. That felt like a weirdly obvious gap for something as "smart" as an AI agent to have. So we built Errbase to fix that.

What it does

Errbase basically remembers your bugs for you. Every time you or an AI agent hits an error and fixes it, Errbase stores it — not as some flat log, but as an actual knowledge graph connecting the error, what system it happened in, what class of problem it is, and what fix worked. Next time something similar shows up, even if it's worded totally differently, Errbase pulls up the right fix and tells you why it thinks that's the one.

Three things it does: remembers a fix, recalls one when you need it (based on meaning, not needing the exact same wording), and gets better over time as fixes get confirmed working. You can use it as a regular CLI tool, or hook it up as an MCP server so an AI agent can use it on its own mid-session.

How we built it

For cleaning up messy input — logs, random text, whatever — we used IBM's Data Prep Kit to normalize everything into consistent chunks before it goes anywhere near the graph. Otherwise you just end up with a graph full of noise.

The actual brain of it is IBM Granite through watsonx.ai — it handles generating embeddings so similar errors match up even with different wording, pulls out the entities and relationships automatically to build the graph, and writes the plain-English explanation for why a fix got recommended.

Instead of doing typical vector search, we went with Graph-RAG — so retrieval actually walks through the graph's real relationships instead of just grabbing the "closest" match by distance. That's what lets it explain itself instead of just spitting out an answer.

Then we wrapped the whole thing as an MCP server so agents like Claude Code can call it directly mid-task — recall a fix, remember a new one, confirm one worked — but we specifically kept anything destructive, like wiping memory, off-limits to the agent. That part felt important to get right.

Challenges we ran into

Getting the graph itself right took way longer than expected. At first it either split everything into a hundred tiny disconnected nodes, or lumped genuinely different errors together just because the text looked similar on the surface. Took a lot of tweaking to get it actually reflecting real cause-and-effect instead of just surface-level similarity.

Figuring out what an agent should and shouldn't be allowed to do on its own was another one — we wanted it to feel genuinely useful and autonomous, but not in a way where it could accidentally wipe out someone's memory graph without a human okaying it.

And explainability turned out to matter more than we expected going in. Just getting the right answer isn't enough if you can't show your work — nobody's going to trust a black box, especially not for something an autonomous agent is going to act on.

Accomplishments that we're proud of

We didn't just wrap a chatbot around a vector database and call it memory — we actually built a real graph with real relationships in it, and it gets smarter the more it's used instead of just sitting there static.

We're also pretty happy that it works natively as something an agent can use on its own. Most tools like this are built for a human typing commands into a terminal, full stop. Building it agent-first from day one is still pretty rare, and it opens up a lot of what this thing can actually do.

What we learned

Mainly — "memory" doesn't mean much without structure behind it. Just storing a bunch of embeddings tells you what's similar, but not why something actually worked. Once we started building the graph piece properly, we saw how much better the retrieval got when it could actually follow real relationships instead of just measuring how close two things are.

We also learned a lot about where AI agents genuinely fall short right now. Cross-session memory is a problem a lot of people talk about but few actually solve — and building toward it made it pretty clear that a lot of what gets called "agent intelligence" today is really just a big context window, not actual persistent understanding.

What's next for Errbase

• Team-level memory, so one person's fix becomes something the whole team can pull from instantly
• Support for more agents beyond Claude Code, since MCP is meant to work with more than one
• Some kind of analytics layer on top of the graph itself — showing which errors are actually costing teams the most time, since right now nobody's tracking that at all
• Eventually, maybe some opt-in way for teams across different companies to share fixes for common library/framework errors, without ever touching anyone's actual private code

Built With

• agentic
• ai
• claude
• cli
• code
• data
• database
• embeddings
• explainable
• freshworksdeveloperplatform
• graph
• graph-rag
• kit
• knowledge
• llm
• mcp
• natural-language-processing
• prep
• python
• search
• semantic
• server
• vector