Show IH: I lost three weeks of AI context in one mistake. So I spent over a year building a local memory forest. (Mac only)
Every AI conversation I've had since GPT-3.5 felt disposable.
I once recorded three full weeks of AI work — architecture decisions, debugging sessions, trade-offs — into PostgreSQL through MCP. Then the Docker container was accidentally wiped. No Time Machine recovery. Three weeks of context, gone forever.
That was the moment I stopped treating AI conversations as disposable.
I'm Iz_JP — I've been building things for clients (music, video, web) for over 30 years in Japan. About a year and a half ago, I started building something strictly for myself. I've rebuilt it more than ten times since.
If you're deep into Claude Code, Codex, Cursor, or local LLMs, you probably know this feeling. You spend hours in a deep conversation. Then: "Context limit reached." Or worse — auto-compacted into a summary. They save the conclusion. They destroy the journey.
What Organiee does
You just talk to your AI. Say "Record it," and the conversation becomes a tree — searchable, connected, yours to keep.
- Records your AI conversations locally — plain Markdown files on disk, plus a SQLite search index
- Connects to MCP-compatible clients — tested with Claude Code, Claude Desktop, OpenAI Codex, Cursor, and local LLM apps
- Searches your entire conversation history, including months-old discussions
- Everything stays on your Mac. Optional sync uses your own iCloud — never our servers. No lock-in.
- Now a native Mac app — signed, notarized, no terminal maze, no fragile setup.
With thousands of records in the forest, the next AI can answer from more than the current session — with the weight of the history you've built. The difference between a handful of trees and a forest is the difference between knowing and understanding.
This app was finished inside itself
This post was developed across multiple AI models and sessions. Auto-compacting happened repeatedly — but every decision was recorded in Organiee, so each new session could search the full history and continue where the last one left off.
In the final week before launch, the Mac app itself was finished inside Organiee Rooms. The implementing AI lost its working memory twice to context compaction, and recovered both times by searching the forest it was helping to build. Its first-person account now lives in my forest, alongside over 4,700 records and 60+ Rooms — including the one where this launch post was written.
That's not a pitch. That's what happened.
Rooms
A Room brings several AIs into one shared workstream. One implements, another reviews, a third tests. They keep handing work back and forth across multiple cycles, while the decisions and history stay in the Room. No agent framework. No loop configuration to maintain.
You could build the loop yourself. You shouldn't have to maintain it.
The other side of the context war
Right now, everyone is solving context from the AI side — bigger windows, better RAG, agents, skill files. Vendors ship memory features too. All of it lives inside one vendor's world.
Still within a session. Still not yours.
Organiee solves it from the human side: a memory you own, on your own disk, that any AI can walk into.
Most note tools let you collect. Organiee lets you continue.
What do you do today when an AI session ends before the work does?
Plant 100 trees for free. I dare you to stop there.
→ organiee.com (Mac only)
I can relate to this. Losing important AI context is frustrating, especially when a project spans multiple sessions. Keeping a local, searchable history sounds like an interesting approach, particularly for long-term development work where the reasoning behind decisions matters just as much as the final result. Curious to see how it evolves over time.
This resonates. I went the opposite direction with my own stuff: tools that can't talk to a server even if they wanted to. Everything runs in the browser, no upload, no API call. The "lost your context" problem only exists when the context lives somewhere you don't control. Treating local-first as a hard design constraint (not a feature) eliminates a whole category of bugs along with the privacy question.
Curious if you considered a browser extension or web app substrate instead of Mac-native — would've been a smaller build, but cross-platform from day one.
What resonated with me is the distinction between preserving answers and preserving how those answers were reached.
When the reasoning survives, a new session can inherit more than context—it inherits judgment. That feels like a very different direction than simply making context windows bigger.
The idea of preserving the journey, not just the conclusion, is the part that stands out to me. Auto-summaries are useful for continuing quickly, but they often remove rejected ideas, trade-offs, and the reasons behind important decisions.
Right now, I usually rely on a mix of project notes, Git history, and manually written handoff files between sessions, but it still feels fragmented.
Keeping the memory locally and making it accessible across different AI tools seems especially valuable. How do you handle relevance once the forest becomes very large? Is retrieval based mainly on semantic search, or do Rooms and tree relationships also affect which records are surfaced?
Great question — and your current stack (notes + Git history + handoff
files) is exactly the instinct this grew out of.
The honest one-line answer: nothing that isn't recorded can be found —
and everything that is recorded, the search can now dig out one way or
another. That second half took a year.
On relevance at scale (4,700+ records in my own forest today): the
heavy lifting happens at write time, not query time. When an AI
records a conversation, it also writes the retrieval metadata — title,
TL;DR, tags, and the part that matters most: recall keywords, the
phrasings a future searcher might actually use, in both of my
languages. The librarian writes the index card at shelving time, while
it still holds the full context.
Retrieval itself is lexical — a local SQLite full-text index over the
records; no embeddings, no vector database. The pipeline (we call it
Synapse Search) falls back in stages when a query misses, and labels
those results "neighbors, not answers" instead of pretending. The
semantic step happens in the model reading the results: it sees titles
and TL;DRs, decides what matters to the current question, and pulls
full text only for those. A model judging "is this relevant to what
we're doing right now" beats any fixed vector distance — and it gets
better every time your model does.
Rooms are a parallel layer, not a ranking signal. Records are
immutable; Rooms hold the process that produced them — rejected ideas,
trade-offs, the argument before the decision — and you can walk from a
record back into the Room behind it. The forest is where records
sleep; a Room is where the right ones are already awake.
And when the search finds nothing, it says so — with a note on how
many records are still sleeping outside the current view — rather
than returning confident noise. At 4,700 records, that honesty has
mattered more than any ranking tweak.
The longer philosophy:
https://organiee.com/field-notes/wasnt-it-something-like/ — and your
handoff files aren't wrong, by the way. They're a forest maintained by
hand. The difference is only who does the planting.
That write-time indexing approach makes a lot of sense. I was assuming relevance would mainly be solved at query time, but generating recall keywords while the full context is still available is a much stronger design.
I also like the distinction between records and Rooms—the result stays immutable, while the reasoning process remains traceable. And labeling weak matches as “neighbors, not answers” is a great trust decision.
Thanks for the detailed explanation. This gave me a much clearer picture of how the system scales without embeddings.