How I Used AI to Restructure My Obsidian Vault

Or: how I went from 100+ root-level files to an organized knowledge management system in one afternoon.

My Obsidian vault had become the exact thing I tell other people not to let happen. Over a hundred files sitting at the root level. Meeting notes wedged between project docs and half-finished reference pages. A Daily Notes folder with exactly twelve entries in it, because I’d set it up with good intentions and then never opened it again. Standup notes scattered as one-off files instead of living anywhere useful. Every time I went looking for something, I had to remember exactly what I’d named it eight months earlier, because there was no structure to fall back on.

I’d been meaning to sort it out for the better part of a year. The reason I kept not doing it is probably familiar to you. Reorganizing a hundred-plus files by hand is tedious and all-or-nothing, the kind of project that never makes it to the top of the list. You can’t do it in the fifteen minutes between meetings, and you don’t want to give up a Saturday for it. So it sat there, getting a little worse every week.

What finally got me moving was realizing I didn’t have to do the moving myself. I pointed an AI agent at the vault and had it do the whole thing in an afternoon.

People always ask what tool I used. I first did this with Cursor, before I’d settled on a daily driver, and I’ve since moved through Factory Droid to Claude Code, which is what I use now. None of it is tool-specific, though. Your vault is just a folder of Markdown files, so any agent that can read your filesystem and run commands can do this, whether that’s Claude Code, Cursor, or Codex. (If you’re brand new to Obsidian, start with my guide to getting started with Obsidian as a developer and come back.)

Resist the urge to start moving files

The instinct, when you finally sit down to a job like this, is to start dragging files into folders. I almost did. Instead I asked the agent to do something far less satisfying and far more useful: analyze everything I had before touching a single file.

That turned out to be the whole game. The planning mattered more than the execution. I had the agent walk through my vault and ask me the questions I’d been avoiding. Which of these files are active, and which are really archive? Is this company a vendor or a partner? How much detail do I actually want in a profile for a direct report versus someone I meet with twice a year? How should standups be organized so I’ll actually keep them up?

We went back and forth on this for a while. Each answer sharpened the structure a little more. By the time we finished planning, the migration itself was almost an afterthought, because every decision had already been made. I caught problems in the plan that I would otherwise have discovered three weeks later, after I’d already filed forty things in the wrong place.

The structure we landed on

I manage two teams and wear both a product and a people-management hat, so the structure had to hold both without making me think about it. Here’s what we built:

00-Inbox/                    # New notes before categorization
01-Active Work/              # Current focus areas
  ├── Product Management/
  │   ├── Teams/
  │   ├── Projects/
  │   ├── Planning and Roadmaps/
  │   └── OKRs/
  └── People Management/
      ├── 1-on-1s/
      ├── Performance/
      └── Hiring/
02-Reference/               # People, products, partners, vendors, technical docs
03-Archive/                  # Completed/inactive items
Daily Notes/
Templates/
Meta/                       # Index, workflows, tag taxonomy

A few things mattered more than the exact folders. Every note type got a template, and every template carried consistent frontmatter. Standups became one file per team that I update daily, instead of a new orphan file every morning. The People folder split by relationship, with the most detail reserved for my direct reports. None of this is novel if you’ve read about PARA or any other system. What was different was how fast it all came together once the agent was doing the labor.

The migration took fifteen minutes

This is the part that would have broken me if I’d done it by hand. We’d mapped out seventeen batches of files: active work, reference material, archive, plus a few special cases like merging two overlapping People folders. The agent moved each batch, verified it landed where it was supposed to, handled the edge cases, and reported back. It took about fifteen minutes from start to finish.

When I went back in afterward, only three files were left at the root, all of them vault-management docs that belonged there. Everything else was where I’d actually go looking for it.

What I’d tell you before you try it

A few things I learned that would have saved me time.

Moving files is exactly the kind of work to hand off. It’s tedious, mechanical, and easy to verify, which is the sweet spot for an agent. The thinking stayed with me, and that’s the part worth your attention. I spent my energy on what goes where and why, and let the agent spend its energy on the dragging and dropping.

Write the documentation while the structure is fresh. We created an index note, a short workflows note, and a tag list as part of the same session. I didn’t appreciate how much that mattered until weeks later, when I asked an agent to file a new batch of notes and it could read those docs and just do it correctly. The documentation isn’t only for you. It’s what lets the next agent understand your vault without you re-explaining it every time.

Don’t over-commit to the first version. When I realized a week in that I needed a separate folder for a peer Product and Design team, adding it took thirty seconds. The structure is supposed to move with your work, not freeze it in place.

Structure is what makes the AI useful

Here’s the part I didn’t see coming when I started. The reorganization did far more than tidy things up. It was the thing that made everything I now do with AI agents possible.

A messy vault is just as confusing to an agent as it is to you. When every note lives in a consistent place and carries consistent frontmatter, an agent can route new notes, pull context, and synthesize across your whole vault without guessing. That’s what turned my notes from a pile I had to dig through into something I could point agents at to do real work, which is now a core part of my day job as a product manager.

A few months after I did all this, Andrej Karpathy tweeted out a version of the same idea and it took off. His framing is the clearest I’ve seen: “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” The idea is that you rarely write the notes yourself anymore. The agent writes and maintains them while you stay in charge of sourcing, exploring, and asking the right questions. I’d stumbled into the same place from my own messy vault around the same time he was writing that up, which is mostly to say: if even Karpathy is running his notes this way now, it’s worth setting your vault up so you can too.

You don’t need my exact folders. You need a structure that matches how you actually work, consistent metadata so an agent can navigate it, and the willingness to let the AI do the tedious part while you do the thinking. Start there, and the rest compounds.