EverMind

• 

  terminal screenshot showing you state a preference

• 

  terminal screenshot showing you a question where the agent visibly recalls

Inspiration Most chatbots reset every session you re-explain your preferences every single time. I wanted an agent closer to how a good assistant actually works: it remembers what matters, quietly forgets what doesn't, and gets better at helping you the longer you talk to it. The MemoryAgent track's three pillars efficient retrieval, timely forgetting, and recall under limited context map almost exactly onto human memory, so I leaned into that analogy on purpose. What it does EverMind is a CLI agent on Qwen Cloud (qwen3.7-plus for reasoning, text-embedding-v4 for retrieval) with persistent, on-disk vector memory (ChromaDB) that survives restarts. Every turn:

Relevant memories are retrieved and ranked New facts are extracted and written automatically. If the user contradicts a memory that was just recalled, the correction is detected automatically and that memory is fast-tracked toward forgetting. A background pass applies exponential, importance-weighted decay Users can also intervene directly: (remember) pins a permanent memory, (memories) lists everything stored, (forget) archives a specific one. How I built it Designed and scaffolded the architecture with Claude, then implemented and debugged it in Cursor against the live Qwen Cloud API. The core design choice separating retrieval scoring from decay scoring, and treating forgetting as consolidation rather than deletion came from thinking about what would actually be demonstrable live, not just describable in a writeup. Challenges I ran into The memory architecture wasn't the hard part the plumbing was. Qwen Cloud turned out to be a distinct platform from classic Alibaba DashScope, with its own key format, model names, and an OpenAI-compatible endpoint with undocumented quirks: extra parameters like dimensions/encoding_format silently broke embedding requests, and different ChromaDB versions called the embedding interface with different argument shapes (string vs. list, single vector vs. batch). I resolved each by testing the raw HTTP request directly against the endpoint to isolate exactly what payload shape it accepted, rather than guessing from documentation.

Accomplishments that I'm proud of Cross-session recall actually works end-to-end: state a preference, restart the process entirely, and the agent still knows it no fudging. Correction detection runs automatically, live, with no extra command contradict the agent and watch it fix itself mid-conversation. Forgetting doesn't just delete: consolidation genuinely merges related fading memories into a summary, so the gist survives even when specifics don't. Every one of the API quirks that broke the build got root-caused with an isolated test rather than patched over with guesswork.

What I learned That "forgetting" is a design decision, not an afterthought deciding what survives consolidation versus what's dropped outright taught me more about memory system design than the retrieval side did. And: always verify assumptions about a third-party API against a raw request before building abstractions on top of it the bugs that took longest were the ones I tried to reason about instead of just testing directly. What's next for EverMind

Similarity-based (embedding) grouping for consolidation, instead of the current tag-based grouping, so unrelated-but-similar memories still get merged. A lightweight web UI with thumbs-up/down per recalled memory, wired directly into the existing record_confirmation/record_correction hooks. Multi-user support is already architected in (isolated Chroma collection per user_id) next step is exposing it behind real auth.

Built With

• chromadb
• cosine-similarity
• cross-session-memory
• json-mode
• openai-sdk
• persistent-memory
• prompt-engineering
• python
• qwen-cloud
• qwen3.7-plus
• rag
• semantic-search
• text-embedding-v4
• vector-database