Run a personal LLM-native operating system (the Life OS stack)

1. Make the wiki hostile to collision before adding a second agent

The moment two agents can write to the same vault, you need rules. If you skip this, you will lose work within a week.

Write these into AGENTS.md and enforce them with file conventions:

• Ownership. One agent owns each shared file. On my own stack: Claude Code owns all vault writes except a named Codex section in the daily note and the mobile-bridge inbox folder. Codex writes only to its named sections.
• No shadow memory. Agents are forbidden from storing decisions anywhere except the vault. If Codex "remembers" something, it writes it to a markdown file.
• Bridge files. Each agent writes an active-session-YYYY-MM-DD-N.md file during a session. Other agents can read these to know what is in flight without interrupting.

This is the contract. Every rule below assumes it holds.

2. Add a second agent with complementary strengths

BYOAI as a practice, not a principle. Pick the second agent by looking at what the first one is bad at.

• Claude Code primary, Codex secondary: Codex is sharper at structural scope gaps and fresh-eyes code review. Use it for audits, not rewrites.
• Add Gemini CLI when you need massive context sweeps. Gemini's context window holds more than Claude's 1M window for some tasks.
• Add a mobile-capture agent, a Telegram bot or similar, whose only job is intake: dump user messages into 00-inbox/<bridge>/inbox.md, nothing else.

Each agent has one lane. Cross-lane writes are forbidden by AGENTS.md.

3. Build the atomic session protocol

Multi-agent coordination lives or dies on session numbering. Without a protocol, two tabs both pick session 5 and the logs corrupt, and you only find out when you're trying to reconstruct what happened.

You need three things:

• Atomic session numbering that tolerates orphan files, counter drift, and concurrent sessions. "Just increment a counter" is not enough, you need a computation that reconciles multiple sources of truth at session start.
• A compaction-safe bridge file per session. Each agent writes a small status file at start and updates it as it works, so a context-window compaction does not erase what the agent was doing.
• A deterministic end ritual, update operating docs first, then append to the session log, then clean up orphans.

The exact mechanics are the kind of detail that rewards care. Get any of the three wrong and you will lose a session's worth of work before you notice the pattern. I have a specific implementation that I run on my own stack; the shape above is the contract it satisfies.

4. Schedule the vault's background work

A personal OS has background jobs. Use cron for simplicity.

Typical cadences that earn their keep:

• Hourly, refresh any semantic index so search is current
• Every few hours, pull in whatever task tracker you use
• Nightly, pre-generate tomorrow's daily note from the template so the file exists when you wake up
• Early morning, sync any data feed that matters (finance, calendar, analytics)
• Morning, compose a daily brief and push it to wherever you read it

The pattern: cron runs a script, the script updates a file in the vault, the next agent session reads the file as context. The vault is the queue.

Commit every cron script into the vault next to the data it writes. Same file-over-app principle applied to automation.

5. Add a mobile bridge for capture

You are not at the desk sixteen hours a day. A personal OS needs mobile intake.

Set up a Telegram bot (or similar) that writes into 00-inbox/<bridge-name>/inbox.md. Rules:

• Intake only. The mobile bridge never modifies promoted content. It appends to the inbox with a timestamp.
• Tagged lines. Format is - [YYYY-MM-DD HH:MM] <content> so later agents can parse without guessing.
• Triage happens at the desk. When you sit down, the first agent task is to sweep the inbox into the right vault locations. The bridge captures; the desk promotes.

This keeps the bridge simple, secure, and non-destructive. Losing your phone does not corrupt your vault.

6. Plug in live data feeds

The vault gets more valuable the moment it includes data you did not type.

Possible feeds:

• Finance. Plaid webhook → local SQLite → daily snapshot markdown
• Calendar. Google Calendar API → today's schedule block in the daily note
• Analytics. GA4 API → weekly-summary markdown for any site you run
• Tasks. TickTick or similar → sync into 00-inbox/ticktick/
• Email. Gmail API → labeled threads surfaced into the vault

The rule: every feed writes markdown. No data source gets a special format. The vault stays uniform, the agents stay simple, grep keeps working.

7. Let decisions compound in operating documents

The three operating documents (soul.md, AGENTS.md, NOW.md) are meant to change. Small updates weekly, bigger restructurings monthly.

• soul.md, rarely changes. Identity, values, decision principles. When it changes, it's important.
• AGENTS.md, changes as the agent roster changes or a collision rule needs tightening.
• NOW.md, changes weekly. This is where the current North Star lives, and where every agent learns what to prioritize this week.

If you notice the same context being pasted into every agent session, promote it. Write it into AGENTS.md (if it's a rule) or into soul.md (if it's an identity claim). The operating docs are the compounding asset.

---

Why this is an OS, not just a vault

An OS schedules. Crons and background feeds mean the vault improves while you are asleep. A static vault is a notebook. A scheduled vault is a system.

An OS has multiple users (agents). Multiple agents reading and writing the same filesystem, with ownership rules and collision protocols, is the definition of multi-user computing applied to AI.

An OS is reachable from everywhere. Mobile bridge, desktop agents, CLI, cron, webhook, all of them touch the same markdown filesystem. No device is privileged.

An OS has a boot sequence. The session-start ritual, read soul.md, AGENTS.md, NOW.md, today's daily note, the active-session bridge, is the boot. Every agent starts in a known state.

A wiki gives you memory. An OS gives you operations.

Steal this starter

AGENTS.md skeleton for multi-agent coordination:

# Agent Rules

## Roster
- Primary: <agent>, owns <scope>
- Secondary: <agent>, owns <scope>
- Mobile bridge: <agent>, intake only, writes to 00-inbox/<bridge>/

## Ownership rules
1. <primary> owns all vault writes except <explicit exceptions>
2. <secondary> writes only to its named section in daily notes
3. <bridge> writes only to 00-inbox/<bridge>/inbox.md
4. No agent stores decisions outside markdown files

## Session protocol
- On start: read soul.md, AGENTS.md, NOW.md, today's daily note
- Increment the session counter atomically, the exact computation needs to
  tolerate orphan files, counter drift, and concurrent sessions
- Write memory/active-session-YYYY-MM-DD-N.md with current state
- On end: update operating docs FIRST, then append to session log
- Clean up orphan active-session-*.md files older than today

## Collision prevention
- Check memory/active-session-*.md before writing to a shared file
- If another agent is active, append to your own section instead

Cron skeleton (adapt filenames to your own scripts):

# Vault background jobs
0 * * * * cd /path/to/vault && python3 .scripts/<index-refresh>.py
0 */4 * * * cd /path/to/vault && python3 .scripts/<task-sync>.py
55 23 * * * cd /path/to/vault && python3 .scripts/<tomorrow-note>.py
0 6 * * * cd /path/to/vault && python3 .scripts/<finance-sync>.py
0 7 * * * cd /path/to/vault && python3 .scripts/<daily-brief>.py

Boot checklist for every agent session:

• Read soul.md (identity)
• Read AGENTS.md (rules)
• Read NOW.md (current focus)
• Read today's daily note (context)
• Read memory/active-session-*.md for any open session
• Compute next session number atomically
• Write your own bridge file
• Begin work

Three focused evenings get you from "markdown vault" to "personal OS." The wiki was step zero. This is step one of running on it as if it were real infrastructure, because at this point it is.

---

If you want live guidance installing this on your actual stack, the specific session formula, the collision-prevention quirks, the cron-script shapes that stay clean over months, that is what the workshop is for. Subscribe below; I will send details when the next cohort opens.