DEV Community: Brinn

The Mistakes We Made While Designing Long-Term AI Memory

Brinn — Sat, 10 Oct 2026 10:43:48 +0000

We started building what is now Brinn in August 2025, under the earlier name Memolink. The first version was a fairly conventional app: entries, people and categories, with a web client and an API. Since then the product has been renamed, restructured and extended across several surfaces.

Looking back at that arc, a few of our early assumptions about long-term memory didn't hold up. This post is an honest list of the lessons, not a postmortem of any single failure.

1. We framed memory as a journal

For a while, the place where captured information lived was called a "Journal". It sounded natural, but it quietly told users what the product was for: writing diary-like entries on purpose.

That's not how people use memory. They fire off a voice note while walking, forward an email, jot a half-sentence. In 2026 we renamed Journal to Memories across the product, and the framing change mattered more than we expected. Names set expectations about effort.

Lesson: the vocabulary of your product decides how much work users think they're signing up for.

2. We thought of "the app" as the product

The earliest versions were centred on a web client. But the moments when people need to remember something rarely happen inside a web app. They happen in a chat thread, an inbox, a browser tab.

That pushed us toward being present where people already are: messaging, email, web, desktop and a browser extension, all backed by the same memory. We wrote about the practical side in which Brinn surface suits which job.

Lesson: memory should follow the person, not the interface.

3. We treated storage as the hard part

It's easy to assume the difficulty in AI memory is capacity. It isn't. The hard parts turned out to be capture with no friction, understanding dates and entities, retrieving the right thing, and following through with reminders. See why AI reminders misread relative dates for one example of how small errors undermine trust.

Lesson: a memory system is judged by what it surfaces at the right moment, not by what it holds.

4. We underestimated how much "forgetting" matters

More stored data isn't better data. Stale facts, duplicates and noise degrade retrieval. Good memory needs ways for newer information to supersede older, and for users to see and delete what's stored. We cover the user-side controls in how to delete your data from AI services.

Lesson: design the forgetting at the same time as the remembering.

5. We kept renaming things

Memolink became Brinn. Journal became Memories. Pieces of the stack were reorganised into a monorepo with shared API contracts. Each change was reasonable on its own, but the cumulative churn has a cost for users, docs and ourselves.

Lesson: get naming and structure as right as you can early, and treat renames as expensive.

Where this leaves us

None of these were catastrophic, and we're still learning. But if you're building a personal AI, we'd suggest asking early: what does our wording imply, where do users actually need us, and what does the system do when information changes?

We're applying these lessons in Brinn, a personal AI for reminders, lists and memory across WhatsApp, email, web and desktop. What would you add to the list?

The Hardest Problem in Personal AI Isn't the LLM

Brinn — Sat, 10 Oct 2026 10:38:01 +0000

When people picture the hard part of building a personal AI assistant, they usually picture the model: which LLM, which prompt, which fine-tune. In our experience, the model is the part that's easiest to swap and the part users notice least. The hard problems are everywhere around it.

This is a practical list of where the real work tends to hide. It's opinion drawn from building in this space, not a benchmark.

1. Getting information in with no friction

An assistant is only as good as what it has captured. And people capture things in the middle of other things: while walking, in a chat thread, forwarding an email. If saving something takes more effort than remembering it, it won't happen.

That means supporting messy, multimodal input (text, voice notes, forwarded messages, web pages) and turning it into something usable without asking the user to fill in forms. We covered the user side of this in the capture inbox method.

2. Understanding time

"Next Friday", "in two weeks", "the day after the meeting". Relative dates are ambiguous, depend on the user's time zone, and depend on when the message was sent. Misparse one and you get a reminder at the wrong time, which destroys trust quickly. We wrote about the failure modes in why AI reminders misread relative dates.

3. Identity and entities

Is "Sam" the same Sam as last month? Is "the dentist" a person, a place, or a calendar entry? Resolving references across notes is a data-modelling problem that no prompt solves on its own. See how AI extracts people, places and dates from notes.

4. Retrieval that knows what "relevant" means

Semantic similarity is necessary but not sufficient: you also need recency, supersession and exact lookups. We discussed this in retrieval-augmented generation for personal notes.

5. Being present on many surfaces

Users live in chat apps, email, browsers and calendars. Supporting several surfaces means consistent behaviour, shared state and different constraints on each. A feature that works in a web UI may be impossible in a messaging thread.

6. Scheduling and follow-through

An assistant that only reacts is a chatbot. Following through means background jobs, retries, notification delivery and respecting quiet hours, all of which are classic distributed-systems problems wearing a friendly interface.

7. Trust, privacy and control

Personal data is sensitive. Export, deletion and clear permissions are product features, not legal footnotes. See reviewing connected apps and AI permissions.

What this means for builders

Treat the LLM as a replaceable component behind clean interfaces.
Invest early in capture, time parsing and entity resolution.
Design retrieval as a pipeline, not a single vector query.
Build for multiple surfaces from day one.
Make scheduling reliable before making it clever.

None of this is glamorous, and none of it moves on a leaderboard. But it's where the difference between a demo and a daily-use product tends to come from.

This is the work we're doing at Brinn, a personal AI for reminders, lists and memory across WhatsApp, email, web and desktop. If you're building something similar, what did you find was the unexpectedly hard part?

Building AI That Knows What to Remember and What to Forget

Brinn — Sat, 10 Oct 2026 10:37:18 +0000

Most discussions about AI memory are about how to store more: longer context windows, bigger vector stores, more history. For a personal assistant, the harder and more interesting question is the opposite one: what should it not keep, and what should it let fade?

This is a design note about the trade-offs. We're not presenting benchmarks, just the reasoning we find useful when thinking about personal memory.

Why "remember everything" is a trap

Retaining every message forever sounds safe. In practice it creates problems:

Noise grows with volume. The more you store at equal weight, the more irrelevant material competes with what matters at retrieval time.
Stale facts linger. Old addresses, cancelled plans and superseded preferences keep matching queries.
Sensitive data accumulates. Everything retained is something that has to be protected, exported and deletable.

A simple taxonomy of what to keep

It helps to sort incoming information by how it will be used later:

Type	Example	Handling
Commitments	"Remind me to send the invoice Friday"	Keep until done, then archive
Durable facts	Someone's birthday, a preference	Keep, but allow updates to supersede
Reference material	A saved article, a receipt	Keep retrievable, low priority in recall
Ephemeral chatter	"ok thanks", small talk	Don't store as memory
Context for now	What we were just discussing	Short-term only, expire quickly

The short-term vs long-term split is the most important line. We cover it in more detail in how AI assistants remember across short-term and long-term memory.

Supersession beats deletion

Facts change. Rather than only appending, a memory system should be able to say "this replaces that". If the user says their dentist appointment moved, the old time shouldn't just sit alongside the new one. A pragmatic approach is to keep the old record but mark it superseded, so it stops competing in retrieval while remaining auditable.

Let importance be earned

Instead of guessing importance at write time, signals can accumulate:

Was it mentioned again?
Was it retrieved and used?
Did the user correct or confirm it?
Is it attached to a date or a person that recurs?

Things that never get touched can decay in priority. Things that keep coming up can be promoted.

Forgetting must be user-controlled

For personal data, "the system decided to forget" is not enough. Users should be able to see what is stored, edit it, and delete it for real. Two practical guides on the user side: how to delete your data from AI services and an AI data portability checklist.

Entity extraction as a filter

Structured extraction (people, places, dates) doubles as a relevance filter: a message with a date and a person is probably worth keeping; a greeting isn't. We described that side in how AI extracts people, places and dates from notes.

Takeaway

Good personal memory is curated, not hoarded: keep commitments and durable facts, expire context quickly, let updates supersede old values, and always leave the user in control. If you're building in this space, design the forgetting alongside the remembering.

We're applying these ideas in Brinn, a personal AI for reminders, lists and memory across WhatsApp, email, web and desktop. How do you handle forgetting in your own systems? We'd love to hear in the comments.

Why Vector Databases Alone Cannot Solve AI Memory

Brinn — Sat, 10 Oct 2026 10:18:12 +0000

Every "AI with memory" demo starts the same way: embed the user's notes, store the vectors, retrieve the top-k nearest chunks, paste them into the prompt. It works well enough in a demo. Then real use arrives and the cracks show.

This post is about where vector search stops being enough for personal memory, and what has to sit next to it. It's a design note, not a benchmark: we're not claiming numbers, just describing failure modes that show up when the thing you're remembering is a person's life.

What vectors are good at

Embeddings capture semantic similarity. If someone saved "dentist said to book a cleaning in March" and later asks "what did I need to do about my teeth?", nearest-neighbour search finds it without any shared keywords. That's genuinely useful, and for fuzzy recall it's hard to beat.

Where it breaks for personal memory

1. Similarity is not relevance. "What's Sara's number?" and a note that says "Sara's birthday dinner went great" are semantically close. The one you need is a structured fact (a phone number), not the nearest paragraph.

2. Time doesn't exist in embedding space. "I moved to a new flat" saved in January and "I'm moving next month" saved in September both match a query about where you live. Which one is current? Vectors can't tell you; you need timestamps, supersession rules, or both.

3. Facts get updated, not just added. A dentist appointment moves from Tuesday to Thursday. A vector store happily returns both. Personal memory needs the concept of "this replaces that".

4. Entities are not chunks. People, places and dates recur across many notes. If "Sara" is only ever a token inside chunks, you can't ask "everything connected to Sara" without hoping the retriever gets lucky. Extracting entities into their own records makes that a lookup, not a gamble. (We wrote about the extraction side here: how AI extracts people, places and dates from notes.)

5. Forgetting is a feature. If everything is retained forever with equal weight, retrieval gets noisier as the store grows. Deciding what to keep, summarise or let go is a design problem, not a storage problem.

What to put beside the vector index

A pragmatic stack for personal memory tends to look like this:

Raw capture — keep the original note, message or voice transcript as the source of truth.
Structured layer — extracted entities, dates and relationships stored as real fields, so exact questions get exact answers.
Vector index — for fuzzy, "what was that thing about..." recall.
Recency and supersession logic — so updated facts beat stale ones.
A retrieval step that routes — exact lookup first when the question is exact, semantic search when it's vague, and a combination when it's both.

Whether the structured layer is a plain relational table or a graph is a separate decision, and the answer depends on how connected your data actually is. We compare the two in knowledge graph vs plain notes: when structure helps, and the retrieval basics in retrieval-augmented generation for personal notes, explained.

Short-term vs long-term memory

One more distinction that gets lost: what the assistant needs right now in a conversation (short-term) is different from what it should durably know about you (long-term). Treating both as "stuff in a vector DB" hides that. See how AI assistants remember across short-term and long-term memory for the longer version.

Takeaway

Vector search is a retrieval tool, not a memory system. For personal AI, the hard parts are knowing what's current, what's connected, and what to drop. If you're building in this space, start with the structure and add embeddings where fuzziness actually helps.

We're working on exactly this problem at Brinn, a personal AI that handles reminders, lists and memory across WhatsApp, email, web and desktop. If you're building something similar, we'd like to hear what's worked for you in the comments.