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)
Losing three weeks of AI context must have been incredibly frustrating, especially if that context included decisions, research, and work that would be difficult to recreate. I can understand why that experience pushed you to build a local solution instead of relying completely on one platform. The privacy angle is also interesting for people working with sensitive projects. Does the memory forest work across different AI tools, or is it currently designed around one specific workflow?
Right now I just dump a "state of things" markdown file at the end of every session and paste it back in at the start of the next one — it works, but it saves conclusions and loses exactly the trade-offs I end up re-litigating a week later.
The part I'd want to test first is search across months-old records, since my handoff files are only ever useful for about two days before I stop trusting them.
You’ve named the exact failure I built this around: a handoff summary preserves the conclusion, but often drops the reasoning that made it trustworthy.
Organiee keeps whatever goes into a Record word for word. In a normal chat, you choose the scope each time — a decision, a specified stretch of dialogue, or several Records from one long conversation. The title, summary, and recall keywords are added on top, never instead. If you want everything to stay without deciding the scope each time, use a Room, where every post remains by design.
And yes—months-old retrieval is the real test, and I can’t honestly compress that into a day-one demo. My current forest has 4,700+ records spanning roughly nine to ten months. Across earlier versions I’ve created more than 10,000 over about a year and a half, but I deliberately kept those older versions out of the current forest. That’s the scale at which I use Organiee every day; your own test will still take time. The first 100 Trees are free at organiee.com.
"Everyone solves context from the AI side; Organiee solves it from the human side, a memory you own that any AI can walk into" is the whole product in one line, and a genuinely sharp wedge. Worth pulling out for anyone reading, because it's a structural bet, not a feature: every vendor memory feature is trapped inside that vendor's walls, and no vendor will ever build memory that spans competitors, because that helps you leave. The neutrality is the moat. OpenAI won't build memory that works in Claude, so the cross-vendor space is yours by default.
The honest tension, as a peer: your wedge is defensible against vendors, but the thing that makes it valuable (owning your context) also makes adoption hard. "Say record it and it becomes a tree" is friction, however small, competing against a vendor's zero-effort native memory that's just on. Vendor memory is worse and trapped, but automatic. Your bet is that people value ownership enough to do one deliberate thing. For power users who've been burned (your origin story), yes. For everyone else, native "good enough and free" is the real competitor, not other note tools. You're selling to the burned, not the general user, at least first.
Which points at positioning: lead harder with the loss. Your three-weeks-gone story is more persuasive than any feature list, because it makes the reader feel the pain of trusting disposable context. The ones who've felt that convert instantly; the ones who haven't won't care until they do. Sell the scar, not the forest.
To your question, what I do when a session ends before the work does: I lose it, and paper over it by re-explaining context to the next session, exactly the tax you're describing. That re-explanation cost is invisible until someone names it, and naming it is your best marketing, it's the moment a reader realizes they've been paying it for months.
Genuinely thoughtful build, and "they save the conclusion, they destroy the journey" is a line that'll stick.
Thank you — the idea of a re-explanation tax is what I'm taking away from this.
You're right that people who have already been burned feel the urgency first. That's where I'm starting, because I was one of them. But I don't want the product's meaning to end at the loss.
I care deeply about cross-vendor neutrality, but I think of it as a design principle, not a prediction about what vendors will never build. The part I can stand behind is simpler: the records are plain Markdown files on your disk, usable beyond any single model vendor.
"Sell the scar, not the forest" is half right for me. The scar makes the problem visible; the forest is the lasting value. The scar explains the first tree. The forest explains why you keep planting after the emergency is over.
And yes, "Record it" is deliberate. It keeps the human present at the moment a conversation becomes memory. Thanks for reading the product closely enough to see that tension.
The disposable conversation problem is real — I use Claude Code daily and every session is one
exitaway from losing the entire context. Today alone I built a Japanese job interview AI tool, redesigned a landing page, migrated 5 products to a new payment processor, and added analytics to 4 sites — all across multiple Claude Code sessions that don't share state. My workaround is crude: I save key decisions as Markdown files in the project folder.The memory forest concept is interesting — but my hesitation is whether the retrieval quality justifies the local storage overhead. How does it handle partial recall? Like "what was the reasoning behind that pricing decision last week?" vs "show me everything about the Creem migration." If it nails that fuzzy retrieval, I'd install it tomorrow. Mac-only is fine for indie devs — most of us are on Macs anyway.
Your two examples are actually two different kinds of search.
"Show me everything about the Creem migration" is a direct topical search. With Search Compass, Organiee can also group the related records into a dynamic cluster.
"What was the reasoning behind that pricing decision last week?" is the harder case — and the one I built it for. I have 4,700+ records now, and I rarely remember exact titles or wording. When a record is created, the AI also writes recall keywords: phrases a future you might naturally try. If the first query still misses, Organiee can return nearby records explicitly labeled as neighbors, not answers, so the AI can use them as clues and search again.
That is not only a design claim. Recently, an AI investigating one of Organiee's own subsystems used a poor query and got zero direct hits. The labeled neighbors still led it to the exact records it needed.
The honest limit is that the reasoning has to have been recorded. You already save key decisions as Markdown, so you have the important habit. Organiee automates the index card and lets different AI sessions search it later.
There's no embedding model or vector database: the records are plain Markdown and the local search index is SQLite. The free 100 trees are for exactly this test — organiee.com. Try both searches on your own work. If Organiee cannot recover reasoning you know you recorded, don't plant tree 101. Just tell me what failed — I'd genuinely want to know.
Wow !! A local memory forest
saving the conclusion but losing the journey is the part that stings. handing specs through mcp in bunzee, the why behind each decision always drops. does search pull that back too?
It can — if the "why" was preserved. And there's an important distinction.
A normal "Record it" does not automatically save every turn of the chat. The AI turns what you chose to preserve into a structured Record — and what goes in stays word for word; structure is added on top, never instead. Search can bring back the reasoning that made it into that Record. If I want the dialogue itself preserved too, I ask for that explicitly.
For the complete path — rejected approaches, exact wording, and the argument before the decision — I use a Room, where every post remains. A Record preserves the crystallized "why"; a Room preserves the trail. Both can be searched later.
So the honest limit is: Organiee cannot recover reasoning that was never recorded. But it gives me two ways to keep the journey from collapsing into only the final spec.
that's a useful split. record for the crystallized why, room for the whole trail. and yeah, nothing recovers what you never wrote down.
The three-week loss is the inflection point nobody talks about. Most people experience lost context as a minor inconvenience. But for knowledge work (architecture decisions, debugging sessions, API design patterns), three weeks of lost context can reset your entire approach.
What's interesting is that you didn't just rebuild the same thing—losing the context forced you to solve a different problem. That's a genuine insight: the value isn't just "preserve old conversations," it's "avoid architectural regression when context gaps force you to re-solve problems."
For anyone using Claude/ChatGPT for extended projects, this is the real risk. The platform's context window is huge, but durability across sessions is zero. Local-first seems inevitable for serious work.
"architectural regression" — that's the phrase I didn't have, and it precisely names one of the engineering costs.
For me, though, the deeper loss wasn't the decisions — it was the context itself. Those three weeks were lived: the exchanges, the connections, the whole experience of that time. No rebuild can give that back. What the ten-plus rebuilds since have changed isn't what I record — it's how the context is protected. The fire changed where I keep the records; it changed nothing about what I record.
You're right about the real risk: the window is huge, but durability across sessions is zero — and no amount of window growth touches that.
Records being immutable is right, but what happens when the decision itself changes? If I recorded "use approach A" three months ago and now the answer is "actually B, A had a bug," does search surface both with a clear signal of which one is current, or does it just return the closest match and let the AI figure out which is stale from context? That's the failure mode that scares me more than losing records: not missing history, but confidently retrieving the wrong slice of it.
You found the failure mode I worry about most. Honest answer first: Organiee has no hidden "current truth" flag, and a topical search cannot guarantee that A and B will appear in the same view.
Corrections never overwrite. When A turns out to be wrong, "actually B — A had a bug" is written as a new record that explicitly cites A and explains what it supersedes. The old record remains as evidence of what was believed at the time. Searching A's record ID can then find later records that cite it, so the correction trail is walkable in both directions.
The safeguard against confident wrongness is that search does not pretend its view is complete: each result set reports when matching records remain outside the current view, and fallback results are labeled as neighbors rather than answers. The AI still has to follow the correction trail and decide what is current — and that is deliberate. Newest does not mean truest: B may later need a C. That judgment belongs to a reader following the whole trail, not to a timestamp.
Stale retrieval is still possible; what the design tries to prevent is stale retrieval presented with silent certainty. That also depends on corrections being recorded as corrections — as the AI is instructed to do. I planted one this week.
That last line is the load-bearing wall though: the whole trail depends on the AI reliably writing the correction as a correction. Nothing stops it from dropping a fresh unlinked note instead when it's in a hurry, and now you have an orphaned belief with no citation back to what it replaces, indistinguishable from ordinary content until someone notices the gap. Anything that flags "this record talks about the same subject as an existing one but doesn't cite it," so a missed link surfaces itself instead of waiting to be found?
Ah, yes — you mean a write-time guard. No, Organiee doesn't have one, and I don't plan to put a semantic gate in front of recording. Multiple records about the same subject are normal in the forest; similarity doesn't necessarily mean that one replaces another. I let the storage layer keep them and leave that judgment to the model reading the records later.
At this point, I think trying the actual workflow would tell us more than designing that guard in the abstract. The Mac version is free for your first 100 trees if you'd like to test it.
Fair, that's real design feedback vs speculation from me. Deferring the judgment to read-time instead of gating writes makes sense once I think about it, a false-positive gate would cost you legit records. Appreciate you walking through the reasoning, and the offer.
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.
Respect — "can't talk to a server even if they wanted to" is a harder line than mine, and I like it.
I did consider the browser. But a purely browser-based substrate would break two constraints I cared about: native AI clients and terminals need a local MCP endpoint, and I wanted the memory to remain ordinary files on disk rather than storage owned by a browser sandbox. A browser extension could bridge that through a native companion — but then I would still be shipping and maintaining a local component.
Once a local component was unavoidable, a native Mac app became the most honest scope for one developer: the platform I use every day and can test end to end. It also let installation feel like installing an ordinary app: download, drag, enter your serial, and Organiee connects itself to your AI clients. No npm, no config files to edit, no terminal. People who never open a terminal deserve a memory system too.
There's also a purely personal reason: I wanted my memory to have its own door — a dedicated app I could open, rather than another place among everything else my browser already does.
The records remain plain Markdown, with SQLite as the search index. Mac-only today is a scope decision, not an architectural dead end: I'm proving the experience on one platform first, and the core is kept portable so Windows and Linux remain possible if enough people want them. Either way, the records are designed to outlive the engine that reads them. The longer version of that bet: https://organiee.com/field-notes/what-survives/
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.
"It inherits judgment" — you described what I built better in three words than I did in 550. Thank you.
I appreciate you saying that.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
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.
Lost a chunk of context on a client project the same way, mid session with no clean way to reconstruct what the agent had already decided versus what it just happened to write. What actually saved me wasn't a memory system, it was treating every commit as the real source of truth and re deriving intent from the diff instead of trusting whatever the agent's last summary claimed. Curious how your forest handles the case where the agent's own notes about a past decision turn out to be wrong. That's the part memory alone doesn't fix.
The origin story is the strongest part of the pitch — the whole thing exists because a Docker wipe ate three weeks with no recovery. Which is exactly why I'd lead with durability even harder than the feature list. Plain Markdown + SQLite on disk is the right call (I build offline-first, and "your data is just files you can read without my app" is a real trust unlock), but the failure mode you're solving for is data loss, and local files can still be lost the same way — no Time Machine, a bad sync, a corrupted index. What's the recovery story when the SQLite index and the Markdown disagree, and can someone rebuild the whole forest from just the Markdown if your app disappears? Nail that answer and it becomes the reason to trust it, not just a feature bullet.
Lived a much smaller version of this today — kept re-explaining the same project context to an AI every session, so I finally wrote it all down once and started using a persistent memory tool instead of relying on my own. Nowhere near the scale of what you built (three weeks lost is brutal), but same root problem: conversations that don't survive the session are expensive in a way that's easy to underestimate until you actually lose something.
The distinction you've landed on records as immutable evidence, plus corrections that explicitly cite what they supersede is a lightweight provenance model, and it's the piece most 'AI memory' tools skip entirely. Most competitors treat memory as a single mutable blob (a rolling summary, a vector store you overwrite in place), so when a decision changes, the old reasoning just quietly vanishes. You're keeping the 'why' next to the 'what,' which is the harder and more valuable problem, and the 'neighbors, not answers' labeling is the right kind of honesty; false confidence is worse than an empty result.
One thing I'd push on: this is still pull-based; someone (or some agent) has to think to search the forest before the relevant history shows up. The failure mode marc_kumiko123 flagged gets worse as the forest grows, precisely because nothing surfaces itself before you ask. Have you experimented with a proactive layer, something that looks at what you're about to work on at the start of a session and surfaces the 3-4 most relevant prior decisions, correction trail included, before a single query is typed? That's a materially harder problem than search, but it's the difference between a forest you have to walk into and one that meets you at the door.
The strongest part of this is not local storage, it's vendor portability, and the post buries it under the tree metaphor. Every model vendor will ship memory, and none of them will let you carry it to a competitor, so lead with that. One thing I'd test: your buying trigger is the moment someone loses context, so a lightweight import of existing Claude or Cursor history would let people feel the value before they have a loss story of their own.
"I accidentally lost three weeks of AI conversation context, so I spent over a year building a Mac app that stores and organizes AI memories locally in a 'memory forest,' making them searchable, persistent, and private."
This comment was deleted 18 hours ago.