MemoryWeave

Home Page/chat
Metrics tab
Memories tab
Accuracy Tab
Timeline tab
After ask a Question and Used the memory and answered

Inspiration

Every conversation with an AI assistant starts from zero. You explain your preferences, your context, your history — and the next day, it's all gone. This is the fundamental problem with stateless LLMs: they're brilliant in the moment but amnesiac across time.

I wanted to fix that. Not with a database bolted on top, but with something that mirrors how human memory actually works — where recent experiences fade naturally, important facts persist, and meaning is stored as understanding, not just text.

That vision became MemoryWeave.

What It Does

MemoryWeave gives Qwen-powered AI agents a three-tier persistent memory system:

Tier	Store	Lifespan	Purpose
1 — Working	In-context (6k tokens)	Session	Active reasoning window
2 — Episodic	Upstash Redis (TTL)	7–30 days	Recent interactions, cross-session
3 — Semantic	ChromaDB + Qwen embeddings	Permanent	Long-term facts, preferences, skills

The agent retrieves memories by semantic similarity, not keyword lookup. It consolidates episodic experiences into semantic facts using qwen-long, detects contradictions, and prunes low-value memories automatically — so the context window stays useful, not cluttered.

Result: recall accuracy jumps from ~7% (stateless baseline) to ~93% with MemoryWeave active.

How We Built It

Memory Scoring

Each memory carries a health score computed as:

$$H = 0.4 \cdot R + 0.3 \cdot F + 0.3 \cdot I$$

Where:

$R$ = recency (exponential decay from last access)
$F$ = retrieval frequency (normalized)
$I$ = importance score (set at store time, updated on use)

Memories with $H < 0.2$ are pruned during consolidation.

Consolidation Pipeline

Every 10 conversation turns, qwen-long processes episodic memories and extracts structured facts. Contradictions are detected by embedding both the new and existing fact and checking cosine similarity — if two facts about the same entity conflict, the higher-scored one wins.

Stack

Backend: FastAPI + Python 3.11 on Render
Qwen APIs: qwen-max (chat), qwen-long (consolidation), qwen-turbo (scoring), text-embedding-v3 (semantic search)
Tier 2: Upstash Redis (serverless, TTL-native)
Tier 3: ChromaDB with cosine similarity space
Frontend: React + TypeScript + TailwindCSS on Vercel
Containerized: Docker Compose for local development

Challenges

1. Context packing under a token budget Fitting the right memories into 6,000 tokens without cutting off important context required a custom packing algorithm — ranked by combined semantic similarity + recency score, greedily packed until the budget is hit.

2. Contradiction detection without ground truth There's no labelled dataset for "these two memories contradict each other." The solution was cosine similarity between embeddings: facts about the same entity with similarity

0.85 but opposing sentiment are flagged. It's imperfect but surprisingly effective.

3. ChromaDB + Qwen embeddings in production ChromaDB's default embeddings aren't compatible with DashScope's text-embedding-v3 dimensions. We had to explicitly pass pre-computed Qwen embeddings on every store/query call, bypassing ChromaDB's embedding function entirely.

4. Stateless vs. stateful deployment Render deploys are ephemeral — ChromaDB's on-disk storage resets on redeploy. The workaround was persisting the vector store to a Docker volume locally, and accepting that the hosted demo resets on deploy (a known limitation noted in the README).

What We Learned

Hierarchical memory is architecturally more powerful than a single vector store — different tiers serve fundamentally different retrieval patterns
qwen-long's extended context window is perfectly suited for consolidation tasks that would overflow a standard model
The gap between "works locally" and "works in production" in AI systems is mostly about state management, not model quality