LifeOS 2.0

Luis Alt · September 2026 · Version 2.0

This is the second version of this manual. The first, published in July 2026, is still available here for anyone who wants to compare.

Before anything else

I try. A lot. But I am not an organised person.

I say that at the start because most systems like this one are written by people who are, and the advice doesn’t transfer. I have always been good at designing structures and bad at inhabiting them. Twenty years of abandoned Moleskines, three false starts in Notion, a Trello board I haven’t opened since 2019. If a system requires discipline to survive, I will kill it. That is a constraint, and it shaped every decision in what follows.

When I published the first version of this manual, I made a claim: LifeOS keeps working while you are disorganised, because it is simple enough to survive you. Three months later, the first half of that sentence still holds. The second half does not.

The vault became more demanding. Tasks now carry two dates and a count of how often I have postponed them. Every active project must show its next action or admit it has none. Decisions have a four-part structure and a review calendar. Documents hold conversations. None of these rules would survive me if I had to keep them myself. I know, because I have tried to keep rules like them for twenty years.

What changed is who keeps them. An AI agent works inside the vault every day. It reads the same specification I wrote, and it enforces the rules I would not enforce on my own. The system still works while I am disorganised, but for a different reason: the discipline has been delegated. That is a different engineering choice from the one I described in July, and it is why this is a 2.0.

So the manual now has two floors. The ground floor is the system you can build by hand in about an hour: the same one as before, corrected where I was wrong. The second floor is the agent layer: what I hand over, how the handover is controlled, and what it costs. You can live on the ground floor indefinitely. I did, at the start.

Part 1 — Why the usual thing fails

The filing question has no answer

Every tool that organises by place — folders, notebooks, Notion pages nested in pages — asks the same question the moment you capture something: where does this go?

It looks innocent. It is asking you to predict the future. You are filing a note about a meeting with a client: is it about the client, the project, the decision that came out of it, or the person you met? It is about all four. Whichever folder you choose, you are wrong three ways, and you discover which way six months later, when you look for it under one of the other three.

Worse, the answer changes. A note that belonged to “prospect” now belongs to “client”. A draft that lived in “in progress” is now “published”. Every state change becomes a filing chore, and filing chores are exactly what a disorganised person will not do. So the state stops being true. A system whose state isn’t true is worse than no system, because you trust it and it lies to you.

The maintenance tax

Systems tend to demand maintenance in proportion to their sophistication. You build a beautiful relational database with eight linked tables, and then discover that keeping it accurate is a part-time job. The system starts as a tool and becomes a client.

The tell is when you find yourself working on the system on a Sunday instead of working with it. In version 1.0, my answer was to keep the system small enough that the tax stayed low. In 2.0, the system is larger and the tax is paid by someone else. Part 5 is about whether that trade is worth it.

The thing that changed

For twenty years, the format your notes were stored in didn’t much matter: you were the only reader. That is no longer true. I now work with a machine that reads my entire body of work, reasons across it and writes into it every day. It reads plain text natively and proprietary formats badly or not at all.

Which makes the format of your notes a strategic decision. Store your thinking in a database owned by someone else and you have a pretty archive. Store it in Markdown in a folder on your disk and you have a thinking partner that has read everything you have ever written.

In July I called this the single largest change in personal knowledge work in my lifetime. Three months of daily use have made me more confident of that, and more precise about its cost.

Part 2 — The five principles

Everything else follows from these. If you understand the five, you can rebuild the system without my templates. They survived the move to 2.0 intact; two of them gained a refinement.

1. Folders describe what a thing is. Properties describe everything else.

A folder tells you the nature of a note: something I consumed, something that happened, something I made, someone I know. Nature doesn’t change. A book you read is a book you read, forever.

Everything mutable — which project it belongs to, which area of life it sits in, whether it’s finished — lives in properties: a small block of metadata at the top of the file, called frontmatter:

---
type: task
status: active
priority: high
date: 2026-10-02
deadline: 2026-10-09
intention: sell
area: "[[work.sales]]"
related_project: "[[Acme Redesign]]"
---

The consequence: you never decide where a note goes because its state changed. You change one word, and every view that cares about the note updates itself.

The refinement. Version 1.0 said a note never moves. I have since allowed exactly one kind of move: into a folder that is a straight read of a property the note already carries. My finished tasks sit in 04_log/tasks/complete/ because their status is done or dropped. My content sits under a domain folder because of its area, and under a project folder because of its related_project. Nobody decides anything. The field changes first, the move follows, and if folder and field ever disagree, the field is right and the note gets moved.

The test for a folder is whether two reasonable people could put the same note in different places. If they could, the folder is a judgement, and judgements drift. If they couldn’t, the folder is a computation, and computations are safe.

2. Capture must cost nothing. Structure is applied later.

A thought arrives in a meeting, a shower, a car. The friction you can tolerate at that moment is roughly zero. A system that asks you to choose a folder, pick a template and fill in six fields at that moment will lose the thought.

So there is an escape hatch: an inbox with no rules. No template, no metadata, no naming convention. Write the thing and move on.

The price is that you must empty it. Once a week the inbox goes to zero: filed, promoted into something bigger, or deleted. Most of it gets deleted, and that’s the point. An inbox you never empty becomes a graveyard, and a graveyard teaches you not to trust the system.

3. Think in entities, not documents.

Four kinds of thing get to be an entity, a hub note that exists to be pointed at:

• People you’ll deal with more than once
• Institutions: companies, clients, schools, teams
• Projects: initiatives with a beginning and an end
• Areas: the standing domains of your life that never finish

Entity notes are deliberately thin. A person note is three lines. Its value comes from what points at it. Every meeting note that links [[Ana Silva]], every task, every decision accumulates as a backlink on her page. After a year you open her note and see the whole history of the relationship, assembled without your ever keeping a relationship log.

The discipline is small but real: link people, companies and projects by name whenever they appear. Type [[Ana Silva]] instead of “Ana”. That one habit is the engine.

4. One vocabulary for state, across everything.

A task can be active. So can a book you’re reading, an article you’re drafting, a project. Most systems invent a vocabulary for each. Resist it. Use five words, everywhere:

One vocabulary means one dropdown, one mental model and one query. “Show me everything that is waiting” returns the stalled proposal, the unanswered email and the book you put down in March.

The refinement. status says how far along something is. It says nothing about why it exists, and after three months I found I kept needing the second answer. So tasks, meetings and content now carry a companion field, intention, from a closed list of five:

The distinction that does the most work is sell against deliver. A week that is all structure and manage is a week in which nothing was sold and nothing was delivered, and no status field will ever show you that.

5. Plain text, because your notes should outlive the tool.

The files are Markdown, sitting in an ordinary folder, readable by any editor written in the last forty years. Obsidian is how I look at them; it is not where they live.

Plain text is also what makes the system legible to a machine. Two different agent tools work in my vault today. Neither needed an export, an integration or a permission from the vault. They open the folder and read.

Part 3 — The architecture

Seven folders at the top. That hasn’t changed.

When you hesitate, two tests resolve almost every case:

• Did I make it, or did I meet it? Made it → 05_content. Met it, did it, decided it → 04_log.
• Will I link to this from other notes for years? Yes → it’s an entity → 03_entities.

Below the top level, version 2.0 adds structure that is computed, never chosen:

• 04_log/ is split by note family: tasks/, events/, decisions/, journal/, predictions/. Nothing sits loose at its root.
• 05_content/ is split by domain, then by project, read from area and related_project.
• Every folder that holds notes with a lifecycle has a complete/ subfolder for what is done or dropped, so the sidebar shows only what is in play.
• 00_system/playbooks/ holds reusable instructions — how a kind of work should be done, evaluated or published — kept apart from the content produced by following them.

The frontmatter contract

Five fields do the real work.

type: what kind of note this is (task, log, source, content, entity, quote). Never leave it blank. A note with no type is invisible to every view in the system. It exists on disk and nowhere else.

status: one of the five words. Lowercase, single value.

area: which domain of your life this belongs to. Mine are namespaced with dots so they group naturally: lw.innovation, lw.bizdev, lw.strategy for my consultancy, luisAlt for my own brand, board for my board track, and bare words for personal life. Each value has its own hub note in 03_entities/areas/, so an area is a page with backlinks rather than a tag. One rule I learned the hard way: an area names a domain of your work, never a counterparty. Clients run through every area, so a value that appears everywhere partitions nothing.

related_project: a link to the project hub, if there is one.

intention: on tasks, meetings and content, the reason the note exists.

Get those right and every view finds every note. Get them wrong and notes go missing: not deleted, just unfindable, which amounts to the same thing.

The front door and the file tree

Version 1.0 said that views replace folders and that you barely look at the file tree. I was describing what I hoped I would do. I look at the file tree every day. So instead of fighting the habit, I split the two jobs.

The Home note decides what I do. It opens with:

1. Do now: tasks dated today
2. Slipped: open tasks whose date has passed, each one a commitment already missed
3. Open threads: questions left inside documents, waiting on me or on the agent (Part 5)
4. Decisions to make and decisions to revisit: open choices, and past ones whose review date has arrived
5. Projects running, content in flight, events waiting
6. Inbox: how far from zero

The file tree shows me what exists. That is why the computed subfolders above matter: with complete/ folders taking finished work out of sight, the tree became readable enough to browse without a query.

Views answer “what now?”. The tree answers “what do I have?”. Both earn their place.

A worked example

I meet a prospect at a hospital group. Here is how one meeting lands:

1. 04_log/events/Meeting Hospital Aurora.md: an event, with people: [[Marina Lopes]], institutions: [[Hospital Aurora]], area: [[lw.bizdev]], intention: sell, status: done. The notes from the room go in the body.
2. 04_log/tasks/Draft Hospital Aurora Proposal.md: a task, status: active, date set to Monday (when I will work on it), deadline set to the following Friday (what I promised her), related_project: [[Hospital Aurora Proposal]].
3. 03_entities/people/Marina Lopes.md: a person, three lines.
4. 03_entities/institutions/Hospital Aurora.md: an institution, same.

Four notes, a few minutes. Her page shows the meeting and the pending proposal without my having written that down. My task view shows the date. My lw.bizdev area shows the opportunity beside the others. When the proposal goes out, I change one word, and every view corrects itself. And because the task was linked to a project, closing it triggers a question I used to skip: what is the next action on that project, if there is one? That question is the agent’s job. More on that below.

(Hospital Aurora and Marina Lopes are invented. The shape is real.)

Part 4 — Build the ground floor (about an hour)

Everything in this part works without any AI.

1. Name your areas. (20 minutes — do this properly.)

This is the only real thinking in the setup. What are the standing domains of your life? Domains, not projects: things that never finish. Mine are five: my consultancy, my decision-making product, my board track, my personal brand, my family. Keep it under eight, and create one note per area in 03_entities/areas/. If you’re inventing a ninth, you’re probably describing a project. The dotted convention (work.sales, work.delivery, home) lets you slice by work.* as a group or by one sub-area precisely.

2. Seed the entities you already know. (15 minutes.)

Ten people and five organisations you deal with most. Three lines each. The rest will appear as you work.

3. Import nothing.

Do not migrate your old system. Your old notes are still on disk, still searchable. Let this vault fill with live work. (Part 6 explains why.)

4. Write your rules down. (15 minutes.)

This step is new, and it is the bridge to the second floor. Write one page that says where each kind of note goes, which fields it carries and what the five status words mean. Mine began as a single page and grew into a full specification, with the one-page version kept alongside it as a summary. If the two disagree, the specification wins. Even if you never add an agent, you will be glad of it the first time you forget your own conventions.

5. Work for a week. Change nothing.

Meeting ends, write the event. Decision made, write the decision. Thought at a red light, it goes in the inbox. Don’t tune the system this week. Notice what feels wrong.

6. Friday, twenty minutes.

Empty the inbox. Sweep the tasks: anything active that hasn’t moved in two weeks is either waiting or a lie. Check each active project: is it being advanced by at least one open task? If not, it isn’t active. Say so.

7. Monthly — the part that compounds.

Re-read the decisions whose review date has passed. Score the predictions that have resolved. You were right less often than you remember, and the record is the only thing between you and that comfortable illusion. Skip anything else in this manual before you skip this.

Part 5 — The second floor: an agent that keeps the rules

Why an agent

Living on the ground floor taught me which rules I keep and which I don’t. I keep the ones that cost one word. I don’t keep the ones that ask me to check something across twenty notes, every day, with nobody watching. Those are exactly the rules that make a system honest.

An agent inverts that. Checking twenty notes costs it nothing, it never gets bored, and it doesn’t negotiate with itself on a Friday afternoon. So the second floor is built on a simple division: I write the rules and make the judgements; the agent keeps the rules and raises the judgements it can’t make.

The agent works in the same folder I do. It reads the specification before it touches anything, proposes what it will change, waits for my yes, writes, and records what it did. Part of what follows is what I hand over. The rest is the contract that stops that from going wrong.

What I hand over

Dates that tell the truth. Every open task carries two dates. date is the day the task should next appear in front of me: the day I intend to work on it, chase whoever I’m waiting on, or reconsider it. It is never in the past and never empty. deadline is the commitment made to someone else, and it moves only when that commitment moves. On the ground floor, a stale date was my evidence of procrastination. Once dates are kept current, that evidence disappears, so each task also counts how many times its date has been pushed forward.

The five-push rule. At five pushes, rescheduling is no longer an option. A task deferred five times has been decided against five times without anyone saying so. It is dropped, rewritten into something that can actually be done, or tied to a deadline committed to another person. The rule binds the agent as much as it binds me: it will not offer “push again” a sixth time. This is the single rule I most needed and would never have kept alone.

Every active project has a next action. If a project is active, at least one open task must link to it. A body checklist, a pending decision or a paragraph of intentions doesn’t count. When I close a project task, the agent checks the others immediately. If the next action exists, it tells me which one. If none exists, it proposes one to three candidates and recommends one, or suggests that the project is honestly waiting or done.

Decisions with a memory. A decision note is built in four stages: the request (what must be decided, why now, what’s missing), the record (the alternatives, what was known, assumed and unknown, the expected outcomes and their probabilities), the implementation contract (first action, checkpoints, success criteria) and the reviews. Each decision carries its stakes and its reversibility. Reviews separate the quality of the decision from the quality of the outcome and from luck. If a later review produces a materially different choice, a new decision note supersedes the old one and the original reasoning is never overwritten. The agent keeps the calendar of checkpoints and reviews; the Home note shows me when one is due.

Filing. When a status changes, the note moves to the folder that field implies. When a note is created, it lands where its area and related_project say it belongs. These are exactly the chores that killed every system I built before this one.

A morning brief. Before my working day starts, an agent writes a brief into the inbox: the day’s calendar, the vault’s open tasks and slipped commitments, what is waiting on whom. It is written to be read in three minutes, and it points at work; it doesn’t create any.

Conversations inside the document

The change that altered my working day most was small: questions now live next to the text they concern.

When I read a draft and something needs discussing, I write a callout in the document itself:

> [!open] The second paragraph
> **Luis:** Too many clauses. Cut to two sentences.
> **Agent:** Done. I kept the example and dropped the aside, which was doing the same work.

Every turn is signed. The rule that makes it work is one line: whoever spoke last is waiting; the other owes the reply. A thread ending on my turn is the agent’s to answer; one ending on its turn is mine. Ownership flips by itself as the dialogue moves, so there is no label to keep up to date. My first version put the owner’s name in the title, and the titles fell out of sync.

When a thread is resolved, the answer goes into the prose and the thread is deleted. When the reasoning is worth keeping, it becomes a [!closed] note with the date. When a thread turns out to be a real decision, it graduates to a decision note and the callout shrinks to a link. Every open thread in the vault appears on the Home note. Two more callout types sit outside this system: a comment addressed to nobody, which owes no reply, and a plain box used purely for formatting.

The effect is that I no longer decide things in a chat window that disappears. I decide them in the file, and the file remembers.

Name your agent. In my vault the agent signs its turns with a name I gave it, and the name stays the same whichever AI tool is underneath. The model is an implementation detail; the working relationship is the constant. Choose a name for yours. It matters more than it sounds: a signed turn is a record of who said what, and “the AI” is not a signature.

The contract that keeps the agent honest

Handing rules to a machine creates a new failure mode: the machine doing something you didn’t expect, in a place you weren’t looking. Five rules contain it.

1. One specification, read before every write. Folders, fields, statuses, naming and conventions live in a single file in 00_system/. The agent reads it before creating, moving or editing anything. Summaries exist for me, and when a summary and the specification disagree, the specification wins. The instruction files that different agent tools load are kept as mirrors of each other, changed together or not at all.

2. Confirm before writing. For every change, the agent first states the plan: which files, what changes, which related people, institutions and projects the change ripples into. Then it stops and waits. A request to log one meeting usually touches four notes. I would rather approve four lines than discover them later.

3. A changelog of everything. Every change the agent makes is recorded in one file at the root of the vault, newest first, with what changed, where and why. It is the reason I can let something else write into my notes and still trust them. Mine passed 340 KB in a few months, which tells you both how much work the agent does and why the record is not optional.

4. Instructions live in the vault. How a kind of work should be done — an editorial line, a scripting method, a publishing checklist — is written as a playbook in 00_system/, separate from anything produced by following it. The agent’s skills are authored once in the vault and copied to each tool that uses them. When I change how something should be done, I change one file.

5. Nothing is destroyed as a side effect. The agent never deletes: files go to a _to_delete/ folder that I empty by hand. Its backups never carry a .md extension, because a backup that looks like a note gets indexed as a note. Generated files (an HTML render of a report, a document exported from a Markdown source) live in _output/ folders and are never edited by hand, because they can be regenerated.

What stays out

A capable agent will happily turn your whole life into notes. It should not.

The vault holds large and important work, not every exchange. Email replies do not become tasks unless I ask. Commercial follow-up lives in my CRM, and the vault does not mirror it: once a commercial message is sent, its task closes. When I do ask the agent to draft a message, the draft goes into a task note, where I review and edit it before sending. A draft that lives only in a chat window has no place to be corrected.

The test is the same one that governs everything else here: does this note compound? If it doesn’t, it belongs somewhere faster and more disposable.

What it costs

The second floor is not free, and a manual that hid the bill would be the kind of manual this one set out not to be.

The specification grows. My one-page rules became a specification of roughly forty kilobytes. Every rule in it exists because something went wrong without it. I read it rarely; the agent reads it every time.

You supervise. The agent proposes; you approve. On a busy day that is a stream of small confirmations. It is still far less work than keeping the rules yourself, but it is not zero, and a day without supervision is a day in which nothing changes.

The agent over-produces. Left alone, it answers with twenty points when I will read two. I had to teach it, in writing, that completeness is not quality. Expect to do the same.

Tools change. I already run two agent tools on the same vault, and I expect to change them again. Because every rule, playbook and skill is plain text inside the vault, a new agent inherits all of it on its first day. That is the plain-text principle paying out a second time.

Part 6 — How it breaks

Every failure I’ve had has been one of these. The first five are from version 1.0 and still true. The last four are new.

Silent invisibility. When I migrated from Notion, the import brought Notion’s field names with it: Priority with a capital P, where my templates wrote priority. To a human those are the same word. To the machine they are two unrelated properties. Dozens of notes existed on disk and appeared in no view anywhere. I assumed the tool was failing and started drafting a migration back. The tool was fine; my data was inconsistent. When something feels lost, suspect the metadata before you suspect the architecture.

Folder creep. The danger lies in the judgement. The moment you create 05_content/AI Stuff/, someone has to decide what counts as AI stuff, and every note now has two homes. A folder computed from a field carries no such cost. Ask whether two reasonable people could file the same note differently. If yes, don’t build the folder.

The inbox graveyard. Miss two weeks and the inbox has forty items; emptying it is now a project, so you don’t, so it has eighty. If you’re ever behind, declare bankruptcy: select all, delete, start clean. Anything that mattered will come back.

Over-templating. I have seventeen templates; my specification recognises eleven. The other six are scar tissue from Sunday afternoons spent working on the system. Build a template when you have written the same note three times, not before. On the second floor the rule has a corollary: the agent never creates or changes a template without asking. An agent with good intentions and no such rule will template your life.

Migrating structure instead of rebuilding it. When you carry your old system across, you carry its assumptions: its schema, its naming, its idea of what a database is. Those were built for a tool with different physics. Start empty.

The summary that drifts. Any system with a specification soon has summaries of it: a one-page version, the instruction file an agent loads, notes about conventions. Each summary is a copy, and copies diverge. The agent that follows a stale summary does the wrong thing confidently. Name one source of truth and make everything else defer to it.

The rule nobody can see. A convention that lives only in my head, or only in a chat, doesn’t exist for the agent. The first time it breaks one, correct the note and then write the rule into the specification, so it never breaks again.

Letting the agent decide structure. An agent is excellent at applying rules and poor at knowing which rules you want. When it proposes a new folder, field or note type, treat it as a question for you, parked as an open thread in the relevant file, never as a change to accept in passing.

Deciding in the chat. The conversation with an agent is the least durable place in the whole system. Any choice made there and not written into a file will be lost, re-argued or contradicted a week later. Decide in the document.

Part 7 — On Notion, fairly

I used Notion for years and it was good to me. It is better than this system at collaboration: LifeOS is single-player by design. It is better at genuinely relational data: a table of 500 rows with rollups is Notion’s home ground, not Markdown’s. It is better looking, and that matters more than purists admit.

What you trade is ownership and legibility. Your notes live in someone else’s database, reachable through someone else’s API. I moved because I wanted an AI that had read everything I have written and could work inside it. Version 2.0 is what happened when that wish came true: the agent now keeps the vault as well as reading it. That requires plain text in a folder I control.

If you don’t want that, Notion is a perfectly good answer and you should ignore this manual.

What to expect

This will not make you organised. Every system like this one is sold on a transformation it can’t deliver.

The ground floor makes your work findable, connected and true. Findable, because you stopped filing and started querying. Connected, because links accumulate whether or not you’re paying attention. True, because changing state costs one word, so the state stays accurate.

The second floor adds one more word: kept. The rules you would abandon by the third week are still being applied in the third month, because you are not the one applying them.

Weekly maintenance

Pampa: Version 1.0 said “perhaps ten minutes of maintenance a week”. I have no reliable number for your current load: the Friday review, plus the time spent approving the agent’s plans. What is the honest figure? I’ll write it into the paragraph below.

The compounding is real but slow. For the first month, the ground floor feels like extra work with no return. Around month three, you open a person’s note before a call and find the whole relationship laid out — meetings, decisions, the thing you promised in March — and realise you never wrote any of it down as history. On the second floor, the moment arrives differently: you notice that a task you had quietly postponed four times is in front of you, marked, with a question attached, and that nobody had to remember to ask it.

That is when it stops being a system you maintain and becomes a system that carries you.

What changed since version 1.0

For readers of the first version, the short list:

• The thesis. The system still works while you are disorganised, but because the discipline is delegated to an agent rather than because the system stays small.
• Folders. Subfolders are allowed when they are a straight read of a field: note families in 04_log/, domain and project in 05_content/, and complete/ for finished work.
• The file tree. Views decide what to do; the tree shows what exists. I stopped pretending I don’t browse it.
• intention. A second classification beside status: why a note exists (sell, deliver, structure, manage, decide).
• Tasks. date (when it next appears, never in the past) separated from deadline (the external commitment), plus a push counter and the five-push rule.
• Projects. Every active project must have an open, linked next action; closing a task checks for the next one.
• Decisions. A four-stage structure with stakes, reversibility, checkpoints, learning reviews and supersession.
• Open threads. Signed dialogues inside documents; whoever spoke last is waiting.
• The agent contract. One specification, confirmation before writing, a changelog of every change, playbooks and skills kept in the vault, nothing deleted as a side effect.
• Scope. Email replies and commercial follow-up stay out of the vault.
• Setup. A new step: write your rules down before the first week.

Questions, corrections, or your own variant: I’d like to hear about it. — Luis

AI usage disclosure:

AI tools were used in the development of this manual to support the author’s work. Claude (Anthropic, Opus 5.5) compared the published first version against the vault’s current specification, notes and configuration, proposed the version number and the two-floor structure (both accepted by the author), drafted the revised text in the author’s voice from the first version and the specification, replaced real names with invented examples and flagged the points the author had to confirm. The author designed LifeOS and every rule described here, lived with the system that the manual reports on, set the scope and the confidentiality limits of the revision and made all editorial decisions.