Debug Memory Agent
Inspiration
I started with a simple question:* What is a must-have AI product—not a nice-to-have—that cannot be replaced by a generic LLM wrapper?*
After speaking with 20+ founders, product leaders, and engineers through SuperME, one pattern kept emerging: the durable advantage is not more intelligence. It is structured extraction plus compounding memory.
AI coding agents have amnesia. You fix a difficult bug, the session ends, and the reasoning disappears. When a similar failure returns, the agent investigates cache TTLs, checks clock skew, and repeats the same dead ends. It is the “50 First Dates” problem for debugging.
The contrarian insight behind this project is that the valuable primitive is not generic memory—it is the ruled_out list. If an agent knows that a cause was eliminated and why, it can start with structured decisions instead of a blank slate.
Debug Memory Agent is therefore not just a memory tool. It is a decision layer for debugging.
How I Built It
I built Debug Memory Agent as a global MCP integration for Codex.
After a bug is resolved, Codex can save a structured debugging trace containing the module, symptom, hypotheses tried, ruled-out causes with evidence, root cause, fix, and constraints that mattered. The system validates every trace before storage and grounds ruled-out reasoning against the source session, so unsupported conclusions are never presented as fact.
The stack includes FastMCP, Pydantic validation, SQLite persistence, local semantic retrieval, and GPT-5.6 as the configured live extraction model when an API key is available. I also built Windows and macOS installers so judges can test the tool in their own repositories.
How I Used Codex and GPT-5.6
I used Codex as an engineering environment—not merely a code generator.
Codex helped me turn product rules into durable AGENTS.md guidance, implement the MCP and storage pipeline, create global installers, reproduce integration failures, and add regression tests. I also configured reusable Codex slash-command skills modeled after my Claude Code plugin workflow: project setup, instruction management, review, simplification, documentation lookup, frontend work, and disciplined implementation.
GPT-5.6 produces structured extraction candidates from resolved debugging sessions. The system then applies deterministic schema validation and evidence grounding before storage. That separation was intentional: the model can help extract meaning, but it does not get to silently invent memory.
Challenges and What I Learned
The hardest part was not generating a summary—it was making memory trustworthy. I hit two important integration failures.
First, trace extraction had a stricter schema than its tool description exposed, and a valid request could hang in the stdio path. I fixed that by exposing the public schema directly and removing a blocking Git subprocess from the MCP request path.
Second, semantic retrieval could take too long on a fresh task because the embedding model had to warm up again. I changed the design so the local embedding worker persists beyond the short-lived MCP process. The first request can honestly report that memory is warming; later Codex tasks reuse the warmed worker. The biggest lesson was that “memory” is only useful when it is selective, grounded, and honest. A weak match is worse than no match. A remembered conclusion without evidence is a liability. The real value is preserving decisions: what was tried, what was eliminated, why it was eliminated, and what constraints still apply.
I also had to fight the temptation to keep this as a scripted demo. My original plan was a polished replay with hardcoded bugs and precomputed terminal commands. It would have explained the concept, but it would not have proved the system worked beyond the happy path.
Codex changed that calculation. A four-day implementation plan moved forward in one night: from a precomputed demo concept to a real global MCP server, persistent storage, grounded retrieval, installers, and tests. The challenge became deciding what complexity earned its place.
The result is a simple principle: agents should not merely remember more. They should preserve the decisions that matter—what was tried, what was ruled out, why it was ruled out, and what constraints still apply.
The future is not simply more agents generating more output. It is systems that decide selectively what is worth carrying forward.
Log in or sign up for Devpost to join the conversation.