Why organizing knowledge in the age of AI sucks, and what I built – Jordan Green's Blog
Why organizing knowledge in the age of AI sucks, and what I built
14 Jul, 2026
My experience<br>In both my personal and professional life, I spend a lot of my time in an AI chat session. Whether it's brainstorming a product idea I had, learning about shogi, or building a new feature, a lot of it is done through AI. However, the more I used AI the more frustrations I began to encounter. I would find myself digging through conversations to find a recipe I came up with using Claude. I would find myself re-explaining the same thing over and over again every time I wanted to revisit it. What I wanted was a way to store and organize context from my sessions with Claude, and to load the desired context back in on demand, but I soon realized that doing this was harder than it sounded.
For my nutrition plan, I tried using Claude Projects, but the fact that I couldn't easily edit project files from inside a chat made the solution unviable for me. During my time at Jolli, I would often store all of the relevant context for a feature in a single conversation with Claude, but this meant I needed to find the right conversation every time, not to mention my context would get clobbered at compaction time. I tried storing everything in Linear issues, but that meant using a tool built for tracking development issues as personal context storage. Anytime I tried to solve the problem, the solution would have some shortcoming. I decided I needed to sit down and properly think about the problem and how I could solve it for myself.
Key insights<br>The first key insight I had was that part of the tension came from the fact that tools treat the session as the unit of organization, but this is in complete misalignment with the way we store information in our heads. People have their own organizational systems in their head that they use to organize their knowledge and memories; we don't think in terms of conversations with Claude. This was why I would so often remember a recipe I came up with but be unable to find it. In my own head the recipe was stored under the idea of "nutrition", not under "session number 165". What I wanted was a way to organize context in a way that aligned with my own mental model.
Secondly, I realized the reasons why loading context into AI was so frustrating and never seemed to work right. One reason was that even if it could read the context itself, it didn't know any of the meta context about it. Even if it could read a design doc I received from my teammate, it wouldn't know that the doc was likely outdated and not to treat it as the source of truth. Even if it could read the mock HTML file, it didn't know that I wanted it used as a reference. Another reason was that I couldn't just tell it what I wanted it to read, I had to tell it where it was. For a Linear issue I'd have to give the exact number; for a file I'd have to give the path, and not all the relevant files even live in the repo. I don't remember things in terms of their ID or location, I remember them in terms of what they are. I remember a Linear issue by what it's about, and a file by its content.
The next thing I realized was the relationship between what I store for myself and what I store for AI. Some context I was storing only for the AI to remember later and not at all for myself, but a lot of it (probably most) I actually intended for both myself and the AI to use at some later point. For my use case, it didn't make sense to separate an AI memory store from a human-readable docs tool. Humans and LLMs consume the same medium, natural language, so a single legible artifact can serve both. Providing a way to store context for myself could simultaneously provide an easier way for the AI to retrieve it. RAG and vector stores are built purely for AI memory but not for humans to read, and doc platforms like Notion and Obsidian are built for people, with AI bolted on.
Finally, I realized that a huge pain point with AI-generated content is not only when it's inaccurate, but when you aren't able to know whether it's accurate or not. LLMs have a bad habit of both inferring things you never said yourself and asserting things confidently that they were just guessing at or straight up making up. To some extent this is inevitable, and it will get better as models improve, but I at least want to know the source of any derived content, and for anything generated, whether it's known for certain or was inferred or guessed by the AI.
My solution<br>No AI tools that I know of solved all of these problems, so with all of these ideas in mind I wondered if I could build a basic version myself. Nowadays doing something like this is often surprisingly easy, since you can do a lot of it with just Claude skills, essentially using the AI as both the interface and the OS itself. I aimed to tighten the connection between the AI and the context, and to tighten the loop of...