Inspiration

Every conversation with modern AI feels like starting from zero. It doesn’t remember what I mentioned yesterday, can’t connect facts across sessions, and treats a casual “good morning” exactly the same as a critical lab result. For a long time I thought the fix was to store more data—until I realized the real problem is that AI has no sense of what matters.

I wanted to build a system where information earns its place, just like human memory: useful things stick around, trivial things fade away. The name Àtúnbí, meaning “reborn” in Yoruba, captures this perfectly: raw memory is transient, but the knowledge distilled from it persists.

What it does

Àtúnbí is a cognitive memory system that balances fast, real-time responses with slow, deliberate learning, with intentional forgetting built into its core.

It has two complementary execution paths:

  • Serving Path (Real-Time): Responds to user queries in under a second. It ingests any input (audio, PDFs, images, text), processes it into embeddings/entities/scores, stores raw data in Working Memory, then runs an agentic retrieval loop to generate accurate, context-aware responses.
  • Learning Path (Nightly Dream Phase): Runs once every 24 hours. It consolidates old Working Memory entries into structured conversation summaries and standalone verified facts, updates an entity relationship graph, and prunes low-value, unused entries.

At its heart are five specialized memory tiers, each with a dynamic lifespan governed by this retention rule: $$ \text{Lifespan} = \text{clamp}\left(I \times 24\text{h} + A \times 6\text{h} + |E| \times 4\text{h},\ 1\text{h},\ 168\text{h}\right) $$ Where $I$ = importance score (0–1), $A$ = access count, and $E$ = emotional valence (-1 to +1).

I tested it with a medical scenario tracking two diabetic patients across visits, medication changes, and lab results—but it works just as well for codebases, legal cases, research papers, or personal notes.

How I built it

I built it around specialized model routing and reliable, low-complexity infrastructure:

  1. Architecture: Split cleanly into the Serving and Learning paths, with five memory tiers (Working, Episodic, Semantic, Entity + Procedural) that share data across both paths.
  2. Model stack: Used seven specialized Qwen models instead of one general LLM:
    • Serving path: qwen3-asr-flash (transcription), qwen3.5-omni-flash (vision), text-embedding-v4 (semantic vectors), qwen-flash (scoring), qwen-plus-latest (extraction/response generation), qwen-turbo (relevance filtering)
    • Learning path: qwen-max (heavy summarization/fact extraction)
  3. Deployment: Hosted on Alibaba Cloud, kept simple and maintainable:
    • ECS: Single Docker container (FastAPI + Nginx) for the Serving Path, deployed via GitHub Actions
    • ApsaraDB RDS: PostgreSQL + pgvector to store all memory tiers
    • OSS: Raw file storage for uploads
    • EventBridge: Cron trigger for the nightly Dream Phase, which scales to zero when complete

Challenges I ran into

Most of my debugging time went to a single insidious issue: three silent failures, each masking the next.

In a demo, a doctor uploaded a blood work PDF showing a patient’s HbA1c was 8.2%, but the system confidently replied “7.1%” and doubled down when questioned:

  1. Vision hallucination: I initially sent rendered PDF images to the vision model, which invented plausible-sounding but wrong numbers. Fix: Extract raw text with pymupdf first, then send to a text-only model.
  2. Poisoned cache: That first wrong answer got stored in Working Memory, and every subsequent query pulled the cached mistake instead of re-reading the file. Fix: Manually clear the bad entry, and rely on Working Memory’s short expiration to flush future errors automatically.
  3. Silent truncation: Even after fixing the above, the system still gave wrong values. I finally checked the database and found my ingestion pipeline cut every chunk at 500 characters—the HbA1c row sat at position 600, so it never made it to disk. Fix: Store full documents whole; only chunk short chat messages.

A smaller but frustrating challenge: pymupdf was once missing from requirements.txt, crashing the container on deploy and taking an hour to track down.

Accomplishments I'm proud of

  • The two-path design works seamlessly: real-time responses stay snappy, while nightly consolidation builds durable, useful long-term memory without cluttering the user experience.
  • The dynamic retention system actually behaves like intended: frequently accessed, high-importance memories stick around, while trivial entries fade away automatically.
  • Specialized model routing eliminated most hallucinations for structured data tasks, far more reliably than using a single large model for everything.
  • The deployment stayed intentionally simple—no over-engineering, just reliable services that work together with minimal maintenance.

What I learned

  1. Routing beats raw model size: Specialized tools for specific tasks prevent errors and improve reliability far more than upgrading to a bigger general-purpose model.
  2. Always check the source of truth: Never trust just the chat response—verify model output, then verify the database. I saved days of debugging once I stopped guessing and started querying PostgreSQL directly.
  3. Background jobs are just as critical as real-time paths: I polished the Serving Path thoroughly but barely tested the Dream Phase cron at first—always verify the parts that run when you’re asleep.
  4. Forgetting is a feature, not a bug: Intentional pruning keeps memory relevant, reduces noise, and even helps flush bad entries automatically.

What's next for Àtúnbí

  • Expand the Entity + Procedural Memory tier to learn user preferences and workflows over time, so responses adapt more naturally to individual needs.
  • Add support for more input types, like handwritten notes and live meeting transcripts, to make the system useful in more scenarios.
  • Improve the Dream Phase with clustering and topic modeling to build richer, more connected summaries and facts.
  • Test the system across more use cases—legal case tracking, research paper management, and personal knowledge bases—to refine the retention formula for different domains.
  • Open source the core memory engine so other developers can build their own “forgetful” AI systems.

Built With

Share this project:

Updates