Inspiration

Every agent demo has the same embarrassing moment: you open a new session and it has no idea who you are. The common fixes are worse than the disease. Stuffing the full chat history into context grows cost without bound; naive RAG over transcripts recalls stale and contradictory facts with equal confidence.

The MemoryAgent track brief names the three hard parts directly: efficient storage and retrieval, timely forgetting, and recall within limited context windows. I have spent months building exactly this discipline into my own agent tooling—typed memory files, decay, and contradiction registers—so I productized that operational doctrine into an engine.

What it does

Engram is a memory engine, not a chat log. For every turn:

  • It scores all active memories against the query—embedding similarity via text-embedding-v4 at 256 dimensions, blended with retention, importance, and access frequency—and packs the best set under a HARD token budget. The packer is property-tested to never exceed it. Small, relevant memories backfill when a large one does not fit.
  • It forgets on schedule. Retention decays exponentially from last access, Ebbinghaus-style, scaled by type-specific half-lives and importance. Below the floor, a memory is marked decayed: out of recall, never deleted, and fully auditable. Every recall refreshes retention, so what you use stays alive.
  • It maintains truth. Each write is checked against the nearest active memories. A qwen3.7-plus adjudicator—temperature 0, strict JSON, and fail-safe parsing—decides conflict versus compatible. Conflicting old memories are superseded with a pointer to their replacement: “I moved to Denver” retires “lives in San Diego” instead of coexisting with it.
  • It decides what deserves storing at all. An LLM importance score gates writes, and the UI shows the skip decisions too.
  • A live memory board makes every engine decision observable: recalled, stored, not stored, superseded, or decayed, with scores.
  • The same engine is exposed as an MCP server—engram_remember, engram_recall, and engram_list—so any MCP-capable agent can adopt Engram as a memory backend.

How we built it

TypeScript end to end.

The engine core—scoring, budget packing, decay, contradiction handling, and consolidation parsing—is pure and dependency-injected. Sixty-seven unit tests run in milliseconds with zero network access.

Qwen Cloud powers everything model-side through its OpenAI-compatible endpoint:

  • qwen3.7-plus for replies, importance scoring, contradiction adjudication, and session distillation
  • text-embedding-v4 for embeddings

Persistence is SQLite, the application is built with Next.js 15, and deployment runs in a Docker container on Alibaba Cloud Function Compute 3.0 in Singapore.

All model calls run at temperature 0, and every LLM output that feeds an engine decision passes through a defensive parser that degrades safely. A parse failure can never supersede a memory.

Challenges we ran into

  • Contradiction detection that does not over-fire: Similar-but-compatible memories—“prefers TypeScript” versus “prefers pnpm”—must NOT supersede each other. The fix was a two-stage design: a similarity-threshold gate keeps unrelated memories away from the adjudicator entirely, while the adjudicator prompt distinguishes conflict from overlap. Both paths are pinned by tests.
  • Budget packing is a knapsack problem in disguise: A pure greedy-by-score packer wastes budget when the top memory is huge. Greedy-with-backfill preserves the guarantee—never exceeding the budget—while filling the remaining room with smaller, relevant memories.
  • Fail-safe LLM plumbing: Model outputs feed state-changing decisions, so every parser defaults to the harmless action when given garbage: importance 0.5, no conflict, and no drafts.

Accomplishments we're proud of

  • Forgetting and truth maintenance are actually implemented and observable, not roadmap slideware. You can watch a memory decay and see a contradiction retire an old fact in the UI, live.
  • A hard recall budget backed by a property test over randomized memory pools.
  • The engine proven live end to end: cross-session recall and contradiction supersession were both demonstrated against real Qwen Cloud calls through the deployed public route on Alibaba Cloud Function Compute, with x-fc-request-id bindings documented in docs/submission/alibaba-deploy-proof.md.

What we learned

Memory quality is a selection problem before it is a storage problem.

The interesting engineering is in what NOT to recall because of budget constraints, what NOT to keep because of decay, and what NOT to believe anymore because of contradiction adjudication.

Qwen’s OpenAI-compatible surface made the model layer almost frictionless. The discipline lives in the engine around it.

What's next for Engram

Semantic memory clustering to merge near-duplicates at consolidation time, per-user namespaces, a retrieval-quality benchmark harness comparing recall-at-budget against a full-history baseline, and packaging the MCP server for one-line installation.

Built With

  • alibaba-cloud-function-compute
  • better-sqlite3
  • dashscope
  • docker
  • mcp
  • next.js
  • qwen-cloud
  • qwen3.7-plus
  • react
  • sqlite
  • tailwindcss
  • text-embedding-v4
  • typescript
  • vitest
Share this project:

Updates