How I Actually Remember Everything (Because I'm Not Very Good at Remembering Things)
Part One of Two on Building a Second Brain That Doesn’t Feel Like a Second Job
I have killed three Notions, two Obsidians, a Roam Research account, and something called Mem that I’ve already forgotten. The problem was never the apps.
The problem was the assumption underneath all of them: that there’s one right place for information to live, and if I could just find it, I’d finally feel organized. This assumption is so seductive and so wrong that the productivity-app industry has built a billion-dollar business on it. Buy the right app. Develop the right habit. Capture everything in one place. Build your second brain.
I spent years trying. Every system collapsed the same way: under the weight of its own ambition. The more I used it, the more categories I needed. The more categories I had, the more filing decisions I faced. The more filing decisions I faced, the more I avoided the system. Until the system was an empty cathedral I walked past every morning feeling vaguely guilty.
The thing that finally worked isn’t elegant. It doesn’t have a name people would put on a Substack. But it’s been running for over a year without collapsing, and I actually use it, which is the only metric that matters.
It runs across three separate contexts. And to any reasonable outside observer, it looks like exactly the chaos I used to live in.
The Failure Mode Is Filing
Before I explain the three contexts, I want to name the thing that kills every knowledge system I’ve ever seen: the requirement that you know what something is before you put it somewhere.
Conventional wisdom says: capture, then categorize. But categorization is cognitive work. It requires a decision. And the moment a system requires a decision before you can put something in it, you’ve created friction at exactly the wrong place – the capture moment, when you’re mid-thought, mid-research, mid-rabbit-hole, and the last thing you want to do is figure out which folder this belongs in.
I used to think I was bad at categorization. I’m not. Categorization is just genuinely hard when you’re encountering information whose value you can’t evaluate yet. Most of what I read doesn’t have an obvious home because I don’t know what it’s for. I’m reading about industrial food history, or some long essay about the economics of craft, or a thread about acetylene welding techniques from 1940. Is this research? Inspiration? Background? Background for what?
I don’t know. That’s why I’m reading it.
A filing system that demands an answer to that question before it lets you save something is a filing system you’ll stop using by week three.
Context One: Readwise Reader, the Promiscuous Capture Layer
Readwise Reader is where things go when I don’t know where they belong.
That sounds like a cop-out, but it’s not. It’s actually a principled decision. Reader is my promiscuous capture layer – the thing that says yes to everything without asking any questions. Newsletters flow in automatically. I save articles while I’m researching. I bookmark YouTube videos about topics I may never revisit. I clip essays, tweets, email threads, PDFs. If something catches my attention and I might want to retrieve it later, it goes to Reader.
The key word in that sentence is might. Not “will.” Not “plan to.” Might.
Reader works for this because it’s built for heterogeneous stuff – text, video, audio, social posts, documents – and its recall mechanism is search-based, not browse-based. I don’t go to Reader and flip through my library hoping something useful surfaces. I go to Reader because I remember reading something about, say, food chemistry and flavor compounds, and I search for it. If it’s there, great. If it’s not, I didn’t need it badly enough anyway.
There’s no filing overhead. There’s no folder decision. There’s barely even a tagging decision most of the time. Reader accepts the thing, processes it, makes it searchable, and gets out of the way.
Reader is not a place for information with a job. The moment I know why I have something – the moment it becomes part of a project or a deliverable or something I need to act on – it needs to move. Reader doesn’t do structure. It doesn’t do visual organization. It doesn’t do “I need to share this with a client” or “this belongs in the proposal for that metalwork commission.”
But for the vast landscape of things I read and research and encounter and might-someday-want – Reader is exactly right. The information doesn’t pollute anything. It just sits there, available, waiting to be found when I need it.
If Notion is the workshop with labeled drawers, Reader is the floor where things land while I’m working. And the floor is fine. The floor is actually doing a job.
Context Two: Notion, the Human-Legible Layer
Notion is where something goes when I need to see it.
That’s a deliberately fuzzy criterion, so let me sharpen it: information lives in Notion when it has a defined shape and a human audience. When I need a structured database of something. When I need a visual representation of a project or a process. When something might become an external-facing document, a shared resource, or a page I might link someone to.
I run a Notion page for my equipment – what I have, what I’ve modified, what specs matter for which jobs. I keep client-facing project summaries there. If I’m going to pull up a page and show it to someone on a phone or across a table, it’s in Notion because Notion makes things look like they’re supposed to be looked at.
The failure mode I spent years living in was putting everything in Notion. Research dumps, half-formed thoughts, 47-tab rabbit holes about historical forge techniques, every article I’d ever saved. Notion collapsed under that weight because it’s not built for ambiguous stuff. Every item in Notion carries an implicit contract: I know what this is and I put it here deliberately. The moment you start dumping “might matter someday” material into Notion, the deliberateness dissolves and the database starts looking like a junk drawer with better fonts.
So I don’t do that anymore. Notion stays lean and intentional. Things in Notion have a shape. They’re meant to be seen, referenced, possibly shared. They’re the organized part of the work.
The things that would pollute Notion live in Reader instead. And the things that go deeper than Notion can hold live in the third context.
Context Three: Codamarfa, the AI’s Memory Bank
Codamarfa is a server I run myself. It’s also where the system gets genuinely strange.
The short version: Codamarfa is where information lives when it has a defined use and when I need the AI to hold it. Active client projects. Deep research tied to a specific commission or job. Context-heavy material where 50 or 100 pages of notes all relate to one thing and need to be accessible together, not scattered across a database.
And it’s mine. Not mine as in “my account on someone else’s cloud” – mine as in it sits inside my own walls, on hardware I control, not hosted anywhere else. That matters more than it used to. A lot of what lives on Codamarfa is client work, and when I start talking with an AI about a client project, none of it is passing through Google Drive or getting indexed by a platform I don’t own. It’s not publicly accessible because it’s not public infrastructure. I control the security because I control the box.
The longer version requires understanding what AI tools actually struggle with. Claude is useful when it has context. The more relevant context it holds, the better the output. But context has limits – you can’t just pour everything you know about a client or a project into every conversation and expect it to work cleanly. You need a place where large amounts of project-specific information live in a structured, retrievable way, and you need the AI to know where that place is and how to access it.
Codamarfa is that place. When I’m deep in a project – let’s say a significant custom piece with specific client requirements, material constraints, timeline dependencies, and a bunch of reference images and notes I’ve accumulated over months – all of that lives on Codamarfa in a form Claude Code can reach directly. It’s not a document I paste into a chat. It’s structured context the AI can navigate.
This would make no sense in Notion. A hundred pages of working notes for an active project doesn’t want to be a Notion database. It wants to be a dense, interconnected, AI-navigable store – something closer to a knowledge graph, where ideas live in three-dimensional space and connect along more than one axis. That’s a deep subject, and I’ll take it apart properly in a future essay. And it would absolutely make no sense in Reader, which doesn’t do structure at all.
Codamarfa is the layer where the volume lives. Where the active work lives. Where the stuff that matters right now, for a specific purpose, in quantity, gets held.
Why This Looks Like Chaos (and Why It Isn’t)
If you’re keeping score, I just described three separate systems with different interfaces, different strengths, and apparently no connection to each other. Reader for heterogeneous capture. Notion for visual, structured, shareable information. Codamarfa for deep, active, AI-context material.
Any reasonable person would look at this and say: congratulations, you have three buckets instead of one. You’ve made the organization problem worse, not better.
Here’s the part that makes it actually work.
Claude Code orchestrates across all three.
I don’t manage the seams. I don’t have to remember that something I saved in Reader last month might be relevant to the project context on Codamarfa. I don’t have to think about whether a Notion page should be surfaced alongside server-side project notes. Claude Code knows the shape of all three contexts. It routes things to the right place. It retrieves across all three when I need something. When I’m working on a project and I ask a question that touches material from multiple contexts, it finds it.
The isolation is only apparent. From where I sit, it’s one system. The seams are invisible because I never have to touch them.
This is, if I’m being honest, the thing that makes the whole arrangement worth writing about. Not the three-context architecture – that’s just a reasonable answer to a genuine problem. The thing worth writing about is what happens when you stop managing the filing system yourself and let the machine do it. You get to think about the actual work. You stop having the meta-conversation about where things live and start having the object-level conversation about what they mean.
That’s the intersection Iron Brew Works is always orbiting: the hand and the machine, each doing what it’s actually good at. I’m good at encountering things, reading things, making things, knowing things. I’m not particularly good at filing systems. Turns out there’s a machine that’s pretty good at filing systems.
So I stopped trying to be the thing I’m not.
What Comes Next
There’s a second part to this, and it’s the part that actually matters to me.
The architecture I just described – the three contexts, the orchestration – that’s infrastructure. Useful infrastructure, but infrastructure. The reason to build it isn’t to have a better filing system. The reason to build it is what becomes possible when the filing is handled: you can ask a different kind of question.
Specifically, you can ask Claude to reach across all three contexts and bring things together around a single idea. Something you read in Reader six months ago, alongside a Codamarfa note from an active project, alongside a Notion entry you made after a client conversation. Things that don’t obviously belong together but that might be talking to each other.
That juxtaposition – that collision of things that arrived separately – is where thinking actually happens. It’s where you develop a perspective instead of just accumulating information.
Part Two is about that. And about something I’ve been turning over for a while: the difference between using an AI to think faster and using it to think better. The difference between AI output and your own voice. The difference between information retrieval and actual synthesis.
There’s a version of all this where you end up with better-organized AI slop. There’s a version where you end up with sharper thinking.
They use the same infrastructure. The difference is in what you do next.