Why Previously

Previously rethinks AI interaction from the ground up: fix the memory model, and the interaction model fixes itself.

Two Problems, One Root

Current AI assistants share a pair of linked failures that most people experience as one frustration.

Problem 1: memory is siloed per conversation. Every new chat starts from zero. The agent cannot see what you discussed yesterday, last week, or in a different thread about an adjacent topic. Cross-conversation recall requires stitching together vector databases, RAG pipelines, and prompt engineering — and even then the result feels like talking to someone with amnesia.

Problem 2: the conversation list is the wrong cognitive container. Humans do not organize memories into "Chat #47 with Mom." You remember by when something happened and what it was about. The flat list of chat threads is a UI artifact inherited from messaging apps, not a model of how people actually think and recall.

These are two faces of the same mistake: building the product around the conversation UI instead of around memory.

Memory Model Fixes Interaction Model

If an agent genuinely remembers you — across time, across topics, across gaps of days or weeks — then conversation management becomes unnecessary. You do not need to choose or create the right thread. You do not need to remind the agent who you are and what you were doing. You just show up and talk.

Previously replaces the chat-thread list with a timeline: a vertical, top-to-bottom view of time slices. Each slice is one uninterrupted conversation burst — opened when you start talking, closed automatically after a stretch of silence. The path tells you exactly when it happened:

memory/episodic/slices/YYYY/MM/DD/HHMM/
├── previously.md      ← the user card as of that moment
└── timeline/
    ├── core.md        ← the conversation itself
    └── agent.md       ← what the agent was thinking

There are no conversations to name, organize, or search through — just one continuous relationship, scrolled up to revisit the past or down to continue.

Context stays bounded per request because the prompt is assembled from relevant slices on the timeline, not from an ever-growing conversation window. The agent does not forget the start of a long history because the start was never stuffed into a window — only the pieces that matter, assembled fresh each time.

The conversation is a UI artifact. The timeline is a cognitive model.

The name "Previously" comes from television: "Previously on..." — a brief recap of last time, just enough context to pick up where you left off.

Design Principles

Memory is the hard problem

Storing conversations is trivial. Retrieving the right memory at the right moment with the right depth is the genuinely hard part — and that is where the effort goes. The architecture reflects this priority: recall is not a database query but a dedicated colleague. Since v1.0, recall is performed by a recall sub-agent — it runs on the main model you picked (thinking at low effort) and explores the memory itself, the way a colleague who was there would: first the timeline catalog to locate when, then the strands to find what, then full reads of a few slices. It answers in natural language with every claim anchored to a verbatim reference ({slice_id, quote, note}). "We don't remember discussing this" is a valid answer. The main agent never rummages through memory itself — it keeps only a verification channel, readSlice, to spot-check that the references the recall colleague cites are real.

And the memory itself is no longer static: a Darwinian self-evolution loop — a learned user portrait with falsifiable hypotheses, evidence-anchored fitness scoring, deterministic generation-based triggers — keeps the agent's behavior improving across slices. The complexity budget goes to the core store-index-recall loop, not to configuration knobs or edge cases.

Simplicity over sophistication

One slicing rule, not three. Every configurable knob, every edge-case handler, every stored flag is a tax on future reasoning. Previously pays that tax only where it earns out — in the core loop. The richer continuity heuristics of earlier iterations were removed, not tuned.

Human memory is the right metaphor

The architecture maps directly to cognitive science. Endel Tulving's 1972 distinction between episodic memory (events tied to a time and place) and semantic memory (abstract knowledge, facts, concepts) is the blueprint:

• Slices are episodic — "what happened" organized by when.
• Strands are semantic — "what it was about." A strand is a keyword woven across slices; memory/episodic/strands.json maps each strand to its slice paths, and the recall colleague follows strands at query time to trace a topic across months.

Context-dependent memory research (Godden & Baddeley, 1975; Smith & Vela, 2001) shows that recall improves when retrieval context matches encoding context — divers who memorized words underwater recalled them best underwater. The timeline preserves temporal context, and recall exploits it: locate when first, then retrieve what.

In the Recall doc you can ask it a few questions right on the page — answered from real memory, with verbatim quotes.

Your memory belongs to you

Memory is plain Markdown with YAML frontmatter, lying in your own private GitHub repository (Vercel deployment) or in an ordinary folder on your own machine (local npm) — the same files, the same git ledger, in both forms. Every file is readable by any tool and portable to any system. There is no server of ours, no cloud database, no vector store, no proprietary format. This is an architectural constraint, not a sentence in a privacy policy — see Local First.

Status

Previously is in active early development: expect rough edges and breaking changes, but the core disciplines — memory as files, an auditable write path, your data owned by you — have been architectural constraints since day one. The recommended form is deploying on Vercel; the local npm client shipped stable in v0.9. It's a personal project, not a SaaS.

Related

• Colleagues, Not Tools — how the recall colleague and the main agent divide the work
• Recall — evidence-anchored recall you can try right on the page
• Local First — why the kernel runs on your machine