PARA in a Living System

The PARA method works fine for a personal note system. It works differently — and better — when an AI agent is reading and writing to the same vault. The categories give the agent something to reason about. The structure gives every note a predictable address.

This is about how the vault is actually organized, what gets promoted, what gets archived, and where the friction lives.

The folder layout

The vault lives at ~/vault/. Here's what it looks like right now:

vault/
├── 00-inbox/          # Capture zone — agent triages from here
├── 01-projects/       # Discrete efforts with a clear done state
├── 02-areas/          # Ongoing responsibilities, no end date
├── 03-resources/     # Knowledge library — topics, references, notes
├── 04-archive/        # Completed projects, inactive areas
├── 05-logs/           # Daily notes, weekly reviews, agent activity
├── 06-templates/      # Structured templates for new notes
├── wiki/               # Agent-readable operational knowledge
├── memory/             # Session logs from the agent's perspective
└── 02-areas/openclaw/agents/
    ├── harbor/
    ├── vector/
    ├── ledger/
    └── forge/

The agent configs live inside the vault — not in a separate _agents/ directory. That was an earlier decision that got reversed. Keeping them inside the vault means the whole thing backs up in one git push.

What goes where

00-inbox

The landing zone. A message routed to the agent that doesn't have a clear home yet goes here as a raw note. The agent (or Will) triages it within a day or two. If it stays here longer than a week, it either gets a home or gets archived.

The inbox is not a graveyard. It's a waiting room.

01-projects

Discrete efforts with a defined outcome and a realistic end date.

Current examples:

• next-chapter/ — the active job search pipeline
• honestfix/ — the maintenance tracking SaaS MVP
• uk-trip-may-2026/ — trip planning with a clear departure date
• swe-interview-prep/ — study materials with a moving target date

Each project folder has its own structure. Some have README.md at the top. Some have subfolders for supporting files. The structure follows the work, not a template.

02-areas

Ongoing responsibilities without an end date. They require sustained attention but don't have a finish line.

Current examples:

• career/ — professional development, networking, compensation
• finances/ — budget, taxes, investment thesis
• trading/ — active positions, trade log, market analysis
• health/ — fitness, sleep, provider notes
• openclaw/ — the agent system itself, including agent configs

Areas don't get "completed." They get updated, adjusted, and occasionally archived when the responsibility no longer exists.

03-resources

The knowledge library. Atomic notes on topics of ongoing interest.

Current examples:

• swe/ — software engineering patterns, Go idioms, architecture notes
• trading/ — strategy notes, ticker analysis, option structures
• tax/ — rule references, deduction tracking

Resources link to each other. A note on Go channel patterns might link to a note on worker pool designs. A tax rule note might link to a project note where the expense was tracked. This is where the Zettelkasten layer lives inside PARA.

04-archive

Completed projects and inactive areas. The archive is not a graveyard — it's a reference store. The distinction between "archived" and "deleted" is important. Archived notes are easy to recover. Deleted notes take more effort.

Projects move to archive when they hit their outcome or when the deadline passes without action. Areas move to archive when the responsibility ends (e.g., a project area that no longer needs attention).

05-logs

Chronological records. The vault has:

• daily/ — one file per day, capturing what happened, what was decided, what needs follow-up
• agent/ — agent activity logs, primarily for auditability and debugging

Daily logs are the connective tissue. They capture the context that would otherwise be lost between sessions — what was in flight, what changed, what the next step was.

06-templates

Templates for consistent note creation. When Will starts a new project, there's a project.md template that prompts for the right metadata. When a daily note is created, it has a structured header.

Templates reduce inconsistency. They don't enforce it — the agent and Will still make judgment calls — but they make the default path the right one.

What the agent actually does with this

The agents (Harbor, Vector, Ledger, Forge) each have their own workspace inside 02-areas/openclaw/agents/. Their HEARTBEAT.md files define what they check autonomously.

When the system works as designed:

• New capture in Discord routes to the right agent based on mention and channel
• The agent triages the inbox, creating a project note or routing to an area
• Daily logs accumulate naturally as the agent works
• Completed projects get promoted to archive without fanfare

The PARA categories give the routing logic something to work with. "File this in projects" is a vague instruction. "File this under 01-projects/next-chapter/" is a precise one.

Naming drift and how it creeps in

The main failure mode is naming drift — calling a folder one thing in one place and another thing in another. This matters more when the agent is reading the structure than when a human is maintaining it.

Examples that happened:

• Using /_agents/ in some places and 02-areas/openclaw/agents/ in others, depending on when the file was created
• Project folders with slightly different naming conventions (some with dashes, some with underscores, some with dates in the name)
• Inbox items that weren't triaged for weeks and accumulated without a clear home

The fix is small: audit the folder tree once a quarter. Correct inconsistencies. Move misplaced files. Update the names that have drifted. This is maintenance, not exciting work, but it's what keeps the system readable.

What gets promoted, what gets archived

The basic rule: if a note is still generating active work, it stays in Projects or Areas. If it's done and the work isn't coming back, it goes to Archive.

Practical examples from the vault:

• A project to track a job application round was in 01-projects/. When the last application was sent and the round was over, it moved to 04-archive/.
• A finances/ area note about a specific tax strategy was in 02-areas/. When the tax year ended and the strategy was no longer relevant, it archived.
• A resource note on Go concurrency patterns stays in 03-resources/ indefinitely — it's reference material, not tied to a project.

The archive is not deleted. It's just not in the active tree.

Why PARA still works here

PARA's categorical boundaries map cleanly to how the agent reasons about work:

• Does this have a clear outcome and a realistic end? → Projects
• Does this require ongoing attention without a finish line? → Areas
• Is this reference material that might be useful later? → Resources
• Is this done? → Archive

The agent can route a new note to the right category based on a few properties. Human judgment handles the edge cases. The discipline comes from using the structure consistently, not from building a perfect classification system upfront.

---

Next: what automation actually earns its place in this system.