The orthodoxy everyone repeated
For about a decade, personal knowledge management has agreed on one thing loudly: folders are dead. Roam made it a manifesto, the Obsidian graph crowd made it an aesthetic, and "no folders" became a badge of honour. Don't organize, the line went — just capture, tag, link, and search. Hierarchy is rigid; the graph is alive. Filing things away is the old world; a web of connections is the new one.
My entire system does the opposite. It runs on folders, top to bottom — and it's better for it, not despite the folders but because of them. I want to argue the unfashionable position, but carefully, because the anti-folder crowd is right about something real. The mistake wasn't preferring links. The mistake was treating folders and links as rivals — two teams, pick one — when they were never competing for the same job.
The thesis: coarse structure and fine structure are different altitudes
Here's the whole reframe in one line:
Folders are the coarse structure — this is one thing. Links are the fine structure — this thing relates to that thing. They're two altitudes, not two teams.
A folder answers a question links can't: what are the boundaries of this unit? A link answers a question folders can't: what does this unit have to do with that one? You need both answers, constantly, and they don't substitute for each other any more than a country's borders substitute for its roads. The "folders are dead" camp noticed that links are powerful — true — and leapt to the conclusion that folders are therefore obsolete, which is like noticing roads are useful and concluding you no longer need to know where one town ends and the next begins.
Everything below is that one distinction, worked out.
A folder is a decision; a tag is a reflex
Start with what the act of creating each one is, because it reveals what they're for.
Making a folder is a deliberate act of boundary-drawing. You are declaring: this is one unit, and here's where it starts and stops. That decision costs something — you have to think about what belongs together — and that cost is exactly the value. It's structure, applied on purpose. It's the two words I keep coming back to: structure, and deliberate.
Sprinkling a tag is the opposite. A tag is something you add after the fact, cheaply, without committing to a boundary — #idea, #work, #maybe. That cheapness is why tag systems rot: with no cost and no boundary, you accumulate #writing, #write, #articles, and #content, all meaning roughly the same thing, none of them a decision. A tag records a passing association. A folder records a considered judgment. For anything you intend to keep and act on, the considered judgment is worth more.
Folder-per-article: structure you can physically pick up
The clearest proof is the pattern my whole content corpus now runs on: folder-per-article. Each article is a folder — the .md that is the article, its assets/ of images, its private working notes and briefs — and everything that belongs to that article lives inside its folder.
The payoff is something a tag structurally cannot give you: the unit is a physical thing you can pick up. Move the folder and the article moves with its images and its notes — no dangling references, no hunting through a shared attachments dump. Publish the folder and the build script has everything it needs in one place. Back it up, hand it to a colleague, or point an AI at it, and the whole self-contained unit travels as one. A tag can't be picked up. #article doesn't gather the image and the notes into a thing you can carry. The folder does, because a folder is the boundary, made real on disk.
This isn't nostalgia for filing cabinets. It's that a bounded, self-contained unit is the thing every downstream system — a build script, a backup tool, a sync engine, an AI agent — needs to operate on. Folder-per-article is what makes a corpus portable and buildable instead of merely searchable.
The move the anti-folder camp never saw: the folder-note
Here's where the war actually ends, and it's a feature most "no folders" advocates never had: the folder-note.
In Obsidian, a folder can contain a note of the same name — when-sql-becomes-the-architecture/when-sql-becomes-the-architecture.md — and that note becomes the folder's front door. Now the folder is simultaneously two things: a container (it holds the assets, the sub-notes, the working files) and an atom (it's an addressable, linkable, frontmatter-carrying note in its own right). You can link to it like any note. You can put metadata on it. You can open it and read it.
That's the reconciliation. The "folders vs links" war existed because people thought you had to choose: hierarchy or graph, container or linkable node. The folder-note dissolves the choice. You get the container and the atom in the same object. Your folders participate in the graph — they're link targets and metadata-holders — while still doing the coarse-structure job that links are bad at. The dichotomy the whole debate rested on was false, and the folder-note is the proof.
Paths are context — for you, and for the machine
There's a second reason folders quietly win in 2026, and it wasn't obvious a decade ago: a path is context a machine can read.
Point an AI at articles/when-sql-becomes-the-architecture/assets/hero.png and it already knows a great deal before it opens anything — this is an article, here's its topic, this is that article's hero image. The path is a sentence about the file, written in structure. A tag cloud gives the machine nothing comparable: #sql #architecture #diagram floats free of any boundary, telling the model that these tags exist somewhere but not what contains what. File-paths-as-context is an architectural feature, not legacy baggage — and it's precisely why a structured, folder-organized vault is the thing an AI can act in rather than merely answer from. The folder hierarchy is a map the machine can walk. The tag cloud is a word list it has to guess with.
Search is a query, not a structure
The strongest version of the anti-folder case is "just search — you don't need to organize, you need to find." And search is excellent at finding. But finding is one operation, and it's not the one that breaks.
The moment you need to move a unit, publish it, back it up, or reason about it as a whole, search has nothing to offer — because search returns matching lines, not bounded things. You can't back up a search result. You can't hand a colleague a query. You can't point a build script at "everything about SQL architecture" and get a clean, self-contained unit out. Search finds; folders contain. They're not competing — search is a query you run over a structure, and if there's no structure underneath, the query has less to stand on. You need both, and the folder is the part search can't replace.
Where tags and links genuinely win — because I'm not a zealot
The honest position has to concede the other altitude, or it's just the mirror image of the dogma it's arguing against.
Tags and links genuinely win where folders are weak: cross-cutting themes that don't respect any single boundary (a note that's relevant to three unrelated projects), many-to-many relationships (this concept touches those eight articles), and emergent connections you didn't plan and couldn't have filed in advance. A strict folder hierarchy is bad at all of these, and forcing them into folders is exactly the rigidity the anti-folder crowd rightly complained about. That's the fine structure — the web of relationships between units — and links own it.
So the answer was never folders or links. It's folders and links, each at their own altitude: folders to bound the units, links to relate them, and a folder-note so your bounded units are also first-class citizens of the graph. Take a side in the war and you lose half the structure. Refuse the war and you keep all of it.
Folderize your corpus
Folders didn't die. The discourse mistook a coarse structure for an obsolete one, threw it out, and spent a decade rebuilding worse versions of it out of tags. The fix isn't to pick the winning team — it's to notice there were never two teams, only two altitudes, and one bridge between them.
This is structure beats magic at the level of how you file a single thing. The magic answer is "don't organize, just search and let the graph emerge." The structural answer is humbler and it holds: draw the boundaries deliberately with folders, relate them freely with links, and use the folder-note so you never have to choose. Then folderize — put the unit and everything it owns into one deliberate, self-contained folder — and watch it become portable, buildable, and, as it turns out, exactly the shape an AI can work with.
Part of the Structure Beats Magic series, and the same pattern scaled up in Structure Beats Magic at Every Scale. Pointing an AI at this structure is Context Engineering for One; the folder pattern applied to time is Day-Folders as the Atomic Capture Unit.