How We Built a Self-Evolving Memory System for Qoder

Learn More about Qoder

Explore Qoder for Enterprise

Here's a 30-second test. Ask your AI coding agent three things: what language your project uses, what your team's commit message convention is, and what bug you fixed yesterday that you agreed not to re-introduce. Now run the same test across two or three other AI coding agents you've used. The answers vary wildly.

Almost every major AI coding agent now ships some form of cross-session memory. Having memory is no longer the differentiator. Memory that actually compounds, retrieves at the right moment, and forgets on your behalf is.

On our internal coding-memory benchmark, three systems score 87, 77, and 50 out of 100 on the scenarios every memory system is meant to handle. The 87 is Qoder's. All three ship memory. Only one is designed to compound.

Qoder is an agentic coding platform for developers. What follows is a tour of the memory system sitting underneath all three: what it stores, how it retrieves, and how we measure whether it helps.

What Most Memory Layers Still Miss

Adding memory is table stakes. Building memory that compounds across sessions is the harder problem. Four failure modes show up even with memory turned on:

Knowledge loss. Architectural decisions surface once and then sink. A note got captured somewhere, but six weeks later the agent can't tell you why the team picked Redis over RabbitMQ.
Repeated communication. Stack, conventions, lint rules get re-explained on every fresh chat. The memory didn't extract them, didn't connect them to the current task, or didn't retrieve them at the right moment.
Wasted experience. The "don't do X, it broke production" lesson is either never captured, or captured but never surfaced next time X comes up.
One-size-fits-all behavior. The agent on day one and the agent on day 365 feel the same. Nothing about how you actually work compounds.

Having memory isn't the bottleneck anymore. Having memory that compounds is. The rest of this post is about how we got there.

The Self-evolving Memory Engine

At the core of Qoder's memory system is a loop: generate → organize → retrieve → reflect → generate again. Every turn of the loop makes the next turn better. It's built on three primary capabilities plus one governing layer on top.

The rest of this post walks through each stage, then the meta-memory layer that closes the loop, then how we measure whether any of it works.

Memory Generation: Knowing What to Remember, When, and How

Generation is where the loop begins. Three questions drive it.

What do we remember? Qoder organizes memory around three subjects: the agent (tool experience, MCP experience, skill experience), the project (project info, lessons learned, development conventions), and the user (user preferences, dev preferences, expert knowledge). Those nine subcategories roll up into 5 major categories and 26 subcategories:

user preferences
project info
development conventions
lessons learned
tools & skills

Each subcategory gets its own subgraph (an isolated partition of the memory store) so unrelated memories don't interfere with each other. A note about "prefer tabs over spaces" never contaminates a retrieval about database schema conventions.

A concrete memory entry looks roughly like this (simplified for illustration):

memories:
  - id: mem_b7f2c...
    title: Validate Payment Signature Before State Change
    category: lessons_learned
    content: |
      On payment endpoints, always validate signature
      before touching the order state. A race in the
      old flow caused double refunds in Feb 2026.

The entry is machine-generated, machine-maintained, and retrievable from any of the six recall paths described later. You don't hand-write it, and you don't hand-edit it. The memory agent does.

When do we remember? We place five trigger points along the interaction lifecycle:

On project initialization, capture configuration and structural signals.
When code is adopted, distill the working pattern into experience.
When a conversation ends, extract preferences and durable takeaways.
When a pattern repeats across sessions, abstract it into general knowledge.
When the user issues an explicit memory command, act on it directly.

How do we remember? Every extraction runs through a seven-step pipeline from scene trigger to conflict resolution. The extraction prompt is the load-bearing piece, structured in six segments. One principle runs through the design:

Don't hand to the model what engineering can solve.

We trim input parameters to reduce hallucination risk, let the model handle only the core semantic extraction, and fill in metadata from the engineering side. The model does fewer things, more accurately.

Memory Organization: Keeping Memory Alive and Ordered

More memory is not better memory. Organization keeps the store useful instead of letting it rot into a dumping ground.

Organization runs on two tracks. The user track lets people add, update, delete, or query memories through natural-language commands or a settings page. The system track handles this automatically through seven capabilities:

Forgetting (scored on capacity, recency, retention, and quality)
Cleanup of invalid or stale entries
Memory-network updates (recomputing links between memories)
Anomaly detection
Experience extraction (promoting repeated patterns to general knowledge)
Knowledge sharing (across authorized scopes)
Working-memory cleanup at session boundaries

Both tracks write to the same memory list. The user keeps full control, and the system keeps the store healthy in the background. Neither works alone.

Memory Retrieval: Multi-Stage Hybrid Architecture

Writing memory down is the easy half. The hard half is pulling the right memory back at the right moment, in the right form.

Let's thread a concrete example through this section. A developer opens a chat and says:

"Help me build a payment API."

On the surface, this is a payment-feature request. Underneath, it touches the project's tech stack, the team's API conventions, and, critically, a security issue the same team hit six weeks ago on a different payment feature. All of that should arrive in the model's context before the first line of code gets written.

Here's how Qoder pulls that off.

Stage 1: Intent Recognition

We parse the user's input into three layers:

Primary intent: build a payment API.
Secondary intent: tech-stack and architectural conventions.
Hidden intent: prior security pitfalls, past incidents, team-specific constraints.

What users actually need is often underneath the literal request. Intent recognition is how we make sure the hidden layer doesn't get ignored.

Stage 2: Pre-retrieval (Six Parallel Paths)

We fan the query out into six recall strategies running in parallel. Each path catches a different kind of relevance.

Path	What it catches
Vector recall	Semantic similarity
Full-text search	Exact terms and phrases
Memory graph	Associated memories via graph edges (see below)
Fuzzy keyword	Semantic drift, typos, synonyms
Exact keyword	Disambiguation when the query is terminology-heavy
Fixed query	Always-on "meta" memories, for example, communication style

The last one matters more than it sounds. Fixed query is how we preload user communication style and behavioral conventions before the first token of the actual task is processed. These meta-level memories don't depend on what the user is asking, but they shape every answer.

Stage 3: Tool Retrieval

The agent picks from shallow, deep, exploratory, and direct-fetch modes depending on query complexity. Fast paths for fast questions, slow paths for reasoning-heavy ones.

Stage 4: Reranking

A scenario-appropriate reranker makes the final cut: a lightweight ranker for real-time conversation, a large model for complex reasoning, with RRF as a fallback.

Two Retrieval Structures Doing the Heavy Lifting

Beyond the multi-stage pipeline, two structures carry a lot of the weight.

Memory Graph is a graph of keyword nodes and memory nodes linked by weighted edges. Retrieval runs a two-layer activation:

Semantic activation. Embed the input keywords and walk multiple graph edges outward to nearby nodes (multi-hop expansion).
Graph activation. Starting from the semantically activated nodes, propagate along edges according to weights. This finds memories that are semantically distant but logically connected.

Back to the payment API example. A traversal can light up a path like order flow → inventory reservation → inventory system and another like checkout → discounts → coupons → marketing system. Neither shares keywords with "payment API," but both are logically part of the same feature surface. That's the multi-hop payoff.

Topic Tree is the complement. Where the Memory Graph is good at lateral association, the Topic Tree is good at vertical precision. It organizes memory indices in a category hierarchy. Retrieval descends through "overview → branch → deeper branch → hit," which avoids both information overload and missing a relevant leaf.

The Retrieval Challenges We're Still Working On

Retrieval is where the flywheel either spins or stalls, and it's where we hit the hardest problem:

Large models don't reliably use retrieval tools correctly. They don't always call memory retrieval at the right moment, and they don't always construct the best query when they do.

Prompt finetuning helps, up to a point. Beyond prompt finetuning, we've explored two deeper directions.

Exploration 1: Virtual Files

Some memory systems expose memory as a file system: the main agent reads and writes memory files, users hand-edit them. Simple and intuitive, but it hits a ceiling in real coding scenarios. The main agent won't pause a coding task to scroll through memory files looking for a note it doesn't know exists.

Two judgments came out of that comparison:

Memory needs a dedicated agent. The main agent's job is to finish the coding task. A dedicated memory agent has the cross-session global view to decide what to keep and what to forget.
Memory should maintain itself. Users rarely hand-edit memory files. A system that depends on manual upkeep is a notebook, not a self-evolving system.

An independent memory system gives you stronger generation (global-view extraction instead of "by the way" notes), precise retrieval (six-way parallel recall instead of "open file and search"), and real self-evolution (continuous scoring, decay, and pruning).

We also tried wrapping the memory system behind a virtual file-system interface, because models use files better than tools. Model willingness to interact went up, but hidden-intent retrieval and multi-hop associations were impossible to express through a file interface. The open question is how to build a file-style interface that still exposes strong indexing.

Exploration 2: Proactive Memory

The second exploration flips the direction entirely. Instead of the main agent pulling memory on demand, the meta-memory system pushes memory to the main agent as context evolves.

It watches task progress, reads the conversation, predicts which memories the next step will need, and injects them into the main agent's context between turns. When it works, the agent just "knows things" at the right moment, without having decided to look them up.

Proactive memory also unlocks real-time correction. When the main agent is about to make a decision that contradicts a prior lesson, the meta-memory system can inject the relevant experience before the decision crystallizes. The agent effectively gets an "experience intuition" running in parallel.

The shift from pull-based retrieval to push-based surfacing lets the main agent focus on the task. The right memory shows up at the right time on its own.

This is a direction, not a finished product. But it's where we think retrieval is heading.

Self-evolution: Meta-Memory and Dual Flywheels

Sitting on top of generation, organization, and retrieval is the meta-memory layer. It has two jobs.

Memory monitoring. Set and adjust generation, organization, and retrieval policies based on observed outcomes.
Memory reflection. Evaluate results, close the feedback loop, and optimize strategies.

Meta-memory is what turns the four-stage loop from a mechanical cycle into a system that gets better over time.

Self-evolution operates through two interlocked flywheels:

The memory data flywheel accumulates high-quality memories through reflection, organization, and natural decay, while pruning low-quality ones.

The strategy data flywheel sits on top. Meta-memory watches how current strategies perform, then optimizes them. Better strategies deposit higher-quality memories, which give the next round of optimization better data. The two flywheels lock teeth: the system gets smarter about what it remembers, not just accumulates more of it.

Evaluation: Does It Actually Work?

A self-evolving system has to be measurable, or nobody should trust it. We run two evaluation tracks: an offline benchmark and an online monitoring setup.

Offline Benchmark

We built an in-house evaluation suite covering the same five generation triggers described above, across 26 memory categories. Each run scores three dimensions: generation quality, retrieval quality, and memory effectiveness (whether the recalled memory changed the output).

Scenarios 1-2 (project initialization, code adoption) only Qoder supports out of the box. To keep the comparison honest, we report a core head-to-head on scenarios 3-5, the three scenarios every memory system is meant to handle.

In the core head-to-head, we observed two patterns:

Claude Code is weaker on automatic extraction and multi-hop retrieval. It delegates memory management to the main agent. When intent is unambiguous, generation is accurate and edits are precise.
OpenClaw is tuned for general scenarios. It doesn't pay much attention to coding-specific categories and doesn't auto-extract them.

On the apples-to-apples scenarios (0-100 scale):

The gap here reflects quality on shared ground. On the full five-scenario benchmark, which adds Qoder-specific project initialization and code adoption, the spread widens to 85 / 40 / 28. That's a coverage effect layered on top of the quality gap.

Online Metrics

Online, the methodology is same-scenario A/B between memory-on and memory-off. For each recalled memory, a model judges whether the memory was used or not. We then compare outcomes across the used vs not-used splits, grouped by scenario type. The data below covers three days, top 5 scenarios.

We report per-scenario because memory's impact flips direction: in Q&A scenarios it reduces tokens (context reuse), in complex task scenarios it increases them (the agent does more work to meet actual expectations). A global "tokens saved" metric would average those out and lie.

Across the top 5 scenarios, the rounded A/B deltas line up like this:

-22% dissatisfaction on convention-adherence scenarios. The agent follows project conventions more reliably when it remembers them.
+11% retention on personalization scenarios. Users come back more often when the agent gets them.
-40% input tokens in Q&A scenarios, driven by context reuse. The agent stops re-reading code it already understands.
-33% conversation rounds in complex tasks, via first-time hit rate. Fewer back-and-forths to converge on the right output.

Two aggregate numbers for the memory-on cohort: 85% session engagement (share of sessions where memory gets exercised) and 60% memory effectiveness (share of recalled memories that actually changed the output).

The consistent finding across scenarios:

Memory gives the agent a sharper model of the user. Through convention adherence, personalization, first-time accuracy, context reuse, and precise output, it raises quality across scenarios and reduces resource use where the task allows it.

Using Memory in Qoder Today

A few practical notes:

You can inspect, edit, or clear memories from the settings panel under Memory.
You can also talk to the agent naturally: "remember that we use PostgreSQL," "forget the React preference," "what do you remember about this project?" The memory agent picks up the intent.
Project-specific memories are captured when you run Qoder against a new codebase for the first time.

What's Next

Three directions are live on our roadmap right now:

Experts Mode. One memory store feeding Lead, Frontend, Backend, and QA agents. Memory becomes the shared substrate for multi-agent collaboration instead of living inside each agent.
Cloud Sync. Unified identity and synced preferences across Qoder IDE, Web, and mobile. The same agent recognizes you regardless of where you're working from.
Knowledge Assets. From individual experience to team-level distillation to organizational knowledge. Memory scales beyond the single developer and becomes an org-level asset.

Takeaways for Agent Builders

Most of what's in this blog applies beyond Qoder. If you're building or evaluating memory for your own agent, these are the design choices that carried the most weight for us:

Separate the memory agent from the main agent. The main agent is doing a task. A dedicated memory agent has the cross-session view and the right to forget. Don't bolt memory onto the coding loop.
Don't ask users to hand-edit memory files. Most won't. Systems that depend on manual upkeep degrade into read-only notebooks. Design for "the AI gets smarter on its own."
Fan out retrieval, don't pick one strategy. Vector, full-text, graph, fuzzy, exact, fixed. Each catches a different kind of relevance. A single-strategy retriever will always have blind spots.
Put multi-hop in the retriever, not in prompts. "Refactor -> test standards" and "payment -> prior security incident" are associations the model won't reach by query rewriting alone. Build the association into the store.
Score memory quality continuously. If you're only adding memory, you're accumulating noise. Rot, conflict detection, and reinforcement are what keep the store useful over months.

If you run the same teardown on your own agent's memory layer, the bottleneck is almost always retrieval. Get the index right first.

Closing

The original question was: what does it take for an AI agent to know you? The answer is memory that compounds, not just a bigger model or another storage layer.

Qoder's memory system uses the generate > organize > retrieve > reflect loop to deliver a simple, long-horizon promise to developers:

The longer you use it, the better it gets.

When your AI agent stops needing you to reintroduce your project, proactively avoids the trap you fell into last time, and writes suggestions that track your style more closely with each week, it stops feeling like a tool. It starts feeling like a partner growing alongside you. That's the system we're building.

Community