Your Personal AI Operating System

In April 2026, Andrej Karpathy described his daily knowledge-work setup in a GitHub gist that hit five thousand stars in the first week and accumulated more than sixteen million X views around the companion post. The pattern he named was the LLM Wiki — a folder of source material, an Obsidian vault as the visual interface, and an AI agent compiling, cross-referencing, and maintaining the entire knowledge base. His one-line summary: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." Practitioners had been converging on the same shape for at least a year under different names. Personal OS is the community shorthand. The label tracks the same foundation: a small set of files, an agent that uses them as memory, and a working library of skills that the user accumulates by doing real work.

A leader cannot design the organizational operating system they have not themselves operated. The specific things that get calibrated through daily personal use are practitioner intuitions that do not exist before the practice. Taste on AI-generated output: which of a hundred drafts is the one worth shipping, and why. Cost intuition: what a task actually costs in tokens, how much a bad prompt burns, which model tier is worth the premium for which work. Blast-radius intuition: where the agent can run unsupervised, where it cannot, and how to tell the difference before the mistake. The ratio of context to prompt: why encoded context about the user, the work, and the constraints produces better output than any clever phrasing of the question. None of these can be delegated. None is legible from a dashboard. Each develops through first-hand reps on real work. The Personal OS is how a founder or senior operator builds the four calibrations in a quarter: a small set of markdown files, a weekend of setup, thirty days of disciplined practice, and the working artifacts that become the organization's first encoded knowledge when the team adopts.

Build this yourself before building it for the team

What gets calibrated is the four practitioner intuitions named above, rather than the bare fact of using AI. Leaders who skip the personal practice end up unable to distinguish AI theater from transformation in their own organizations. They mandate things they cannot themselves do, and the mandate decays on contact with reality the moment a frontline employee asks a sharp question about how the system actually behaves. The corrective is mechanical: a weekend of setup, then one to three hours a day of pushing the agents to do things the leader does not yet think they can do, with the explicit goal of discovering capabilities rather than producing output. The orientation matters because the first week is for building calibration the leader can evaluate AI-native work against once the team adopts, not for saving time on the leader's own work.

The right tasks to start with are whichever the user is worst at, rather than the ones that demo well. The Skill Gaps Principle, originally stated by Ethan Mollick in 2023 and restated repeatedly since: "AI elevates the skills of the lowest performers across a wide range of fields to, or even far above, what was previously average performance"↗. On tasks where the user sits well below expert level, the AI output is genuinely better than what the user would produce alone. On tasks where the user is at the top of the distribution, AI output becomes the baseline to improve from. The morning brief, the email drafting, the research synthesis. The painful tasks are where the calibration compounds fastest, because the user's baseline is low enough that the AI's output is actually better, and the discipline of accepting AI output as the starting point becomes natural rather than aspirational.

Context carries more weight than the prompt

A weak model in rich context outperforms a strong model in thin context. The same principle runs at the personal layer with a sharper consequence. The agent that knows who the user is, what the company does, what the role requires, and what the user has learned produces work the user can ship. The agent that knows nothing produces confident generic output the user has to rewrite into usability. The single best diagnostic of whether the context is working is the ratio of rewrite time to review time. Rewrite-heavy sessions almost never have a prompt problem. They have a context problem. The agent does not know enough about the user to produce the output the user would have produced. The four files in the next section are the specific form this takes at the personal layer: cheap to maintain, portable across machines, and durable across model generations in a way that prompt-craft is not.

The workspace is a folder, not a product

The system that works in 2026 is a file-based workspace an AI agent uses as its memory, context, and output surface while collaborating with a knowledge worker. A convention over a folder tree, combined with a small library of skills. No database, no runtime, no hidden state. The entire state is visible on disk as Markdown, which is what makes the system Git-native, model-agnostic, and grep-debuggable. The workspace pattern is described in detail in the team-AI-OS reference implementation that ships with this book at docs/reference/team-ai-os.md for readers to fork and adapt.

Eight design principles do most of the architectural work:

• Files are the API. Every piece of state lives as a Markdown file at a predictable path. Tasks, organizational context, identity, project status, collected data, outputs. The agent reads and writes these files directly. No custom data layer.
• Convention over configuration. Paths are fixed (./content/<type>/, ./private/projects/<slug>/) so every skill knows where to look without being told.
• Idempotent setup. Every initialization step checks for an existing marker before creating anything. Re-running setup never destroys work.
• Portable, relative paths. The workspace is a self-contained folder that can be moved, copied, or opened on another machine without rewriting skills.
• Root-anchored resolution. Paths starting with ./ resolve against the workspace root (the nearest ancestor that contains the operating manual and the task list), not against the current working directory. This keeps skills correct when invoked from any subfolder.
• Separation of collected data and generated artifacts. Data pulled from external sources lands in one tree and is treated as input. Anything the agent generates lands in a different tree and is treated as output. The two never mix.
• One command surface, namespaced. Every skill is a slash command under a single prefix, so the bundle installs without colliding with other skills on the same machine.
• Interactive where it matters. For onboarding-style steps (identity capture, tone-of-voice profiling), the agent renders UI form components rather than driving a chat Q&A. Faster, less error-prone, less tedious.

A fresh setup produces this tree:

<workspace-root>/
├── CLAUDE.md                  # operating manual for this workspace
├── GTD.md                     # living task list (Now / Next / Waiting / Someday / Done)
├── content/                   # all generated artifacts (briefs, research, memos, drafts)
├── private/
│   ├── context/               # inputs the agent reads but should not overwrite
│   │   ├── org.md             # organization context (pre-seeded at setup time)
│   │   ├── who-am-i.md        # user identity, role, priorities
│   │   ├── style/             # tone-of-voice profile(s)
│   │   └── calls/, emails/, chat/, ...   # connector outputs
│   └── projects/<slug>/       # multi-session work, one folder per project
├── connectors/                # custom data connectors (code, configs)
└── shared/                    # collaborative content shared with others

Each top-level directory has one job. The split does the heavy lifting. content/ is agent-written. private/context/ is connector-written. private/projects/ is shared user-and-agent work. shared/ is what the user intentionally exposes to teammates. The reference implementation in the book's repo includes the skill structure, the slash-command set, and the setup script. Forking it is faster than writing it from scratch, and the structure is intentionally generic enough that the org-context file is the only piece a new team needs to rewrite.

The three context files and the living task list

At the center of the system are three files the agent loads at the start of any non-trivial task, plus a fourth that tracks active work. Keep them hand-crafted and short. Auto-generated multi-hundred-line files measurably hurt agent performance because the agent cannot tell what is load-bearing and ends up averaging intent into generic output.

CLAUDE.md — operating manual for this workspace. Who the user is, how the workspace is organized, which skills exist, where outputs go. The first file the agent loads on any session. Roughly 40 to 60 hand-written lines is the right size. The common failure mode is drift into marketing copy. The agent needs operating constraints, not positioning.

private/context/org.md — organization context. Products and pricing, ICP, logistics, partners, vendors, current OKRs, what has been tried, what did not work. Everything that would otherwise have to be re-explained in every prompt. Pre-seed the file during setup from a template shipped with the skill repo rather than gathering interactively, because the content is the same for every member of the organization. Versioning the template in the repo means every user gets the current version for free. The common failure mode is trying to design the perfect structure up front. Describe what the agent needs to know and let the structure emerge from use. Within a week of dumping context, the agent is useful. Trying to get it clean before starting delays use by months.

private/context/who-am-i.md — user identity. Name, role, top priorities, communication handles, and any "things I want the agent to always know about me" notes. Captured once during setup via a visual form, not chat. Weighted against task output, so a morning brief prioritizes items related to the user's stated priorities rather than rendering them as background information. The common failure mode is title-speak instead of verbs. The agent needs "I approve invoices over $10K" / "I run the weekly exec review" / "I own the pricing decision", not "Senior Director of Operations."

GTD.md — the living task list. Five sections: Now, Next, Waiting, Someday, Done. The agent reads it before planning and writes to it when state changes (completing a task, starting a new project, unblocking a waiting item). Single source of truth for active work. Any skill that needs to know what the user is focused on right now reads this file. No secondary system. The common failure mode is that the file stops getting updated. Without a nightly or weekly review, the file drifts and the agent starts prioritizing against stale signal.

A fifth file, private/context/style/tone-of-voice.md, loads when the agent is drafting written content the user will send or publish. Writing samples and inferred voice dimensions so the output reads like the user wrote it. Together, these files mean the agent never has to ask "who are you?" or "what does your company do?" or "what's on your plate?" on a given invocation. They are the baseline prompt context.

The four files are portable. They move with the user across models, across harnesses, across employers. The skills and pipelines built on top of them are replaceable. The context encoded in these four files is not.

Skills, projects, and connectors compose on top of the context layer

Three object types sit on top of the context files.

Skills are folders on disk. The folder name becomes the slash command. Inside is a SKILL.md file with three parts: a description frontmatter one-liner, a Context section (what the agent needs to know about how this team works for this task), an Instructions section (step-by-step phases), and an Output format (template or example of the expected deliverable). Four skill categories cover most of the working library:

• Setup and scaffolding. Shape the workspace itself: the initial setup command, project scaffolding, connector installation.
• Data ingestion. Pull external data into private/context/. Connector-specific installers and a single collection skill that runs them all.
• Synthesis. Read across collected data and context files, produce a digested artifact: situational brief, daily summary, weekly review.
• Deliverables. Long-form domain artifacts using orchestrated sub-agents for parallel work: research reports, investment memos, redlines, briefing documents.

What makes a good skill in this system is that it reads the context files first, writes to conventional paths only (no asking the user where to save), is idempotent where possible, prefers visual components over chat for structured user input, and emits a short final report that suggests two or three next commands the user might run.

Projects are self-contained folders under private/projects/<slug>/, created by a scaffolding skill. They exist because one-off artifacts in content/ are not enough for work that spans weeks. A deal evaluation, a launch, a hiring loop, a research track. A project folder carries its own CLAUDE.md, a README, a status.md, an append-only decisions.md, a context/ folder for research and notes, and a deliverables/ folder for final outputs. When the agent is invoked inside a project folder, it reads the project-scoped operating manual first but still loads the root-level GTD.md and org.md for global context. Root-anchored path resolution means ./GTD.md from inside a project still refers to the workspace root's task list, not a misplaced copy. Deliverable skills check whether a project exists for their current target and route outputs into the project's deliverables/ or context/research/ accordingly.

Connectors are small adapters (often MCP servers) that pull data from an external service and write it to private/context/<channel>/ as Markdown. A single collection skill runs all configured connectors and produces a time-windowed snapshot. Two rules keep the data layer clean. Collected data is input, not artifact, and lands in private/context/ (a directory the agent reads from but does not generate artifacts into). Managed paths are off-limits for manual writes, which means the agent never modifies private/context/{calls,emails,chat,...}/ by hand because connectors own those directories. The separation makes the data layer predictable. A user can blow away private/context/emails/ and re-sync without touching any deliverable.

A note on connector efficiency. The naive pattern of loading every available tool definition upfront breaks down past a few dozen connectors because the tool catalog itself eats the model's context window before the user has typed a question. Anthropic's November 2025 engineering post on MCP code execution showed the alternative: instead of loading every server's tools, the agent discovers tools by exploring a filesystem of server folders and reading only the tool files needed for the current task, dropping context use from 150,000 tokens to 2,000 tokens for a 98.7% saving on the same workflow. The Personal OS pattern naturally aligns with this approach because the workspace is already a filesystem the agent reads on demand. Connector descriptions live in their own folders, and skills reference the specific connector files they need rather than enumerating the whole catalog upfront.

Stage 0 and the thirty-day arc

Stage 0 — instant wins, five to thirty minutes each. The personal practitioner list that compounds fastest:

• Set up the workspace (15 minutes). Install Claude Code or an equivalent harness, create the <workspace-root>/ folder with the four files above, connect email and calendar via MCP. Every subsequent AI interaction becomes dramatically more relevant because the agent knows the user's role, organization, and active work without being told.
• Record all meetings (2 minutes). Turn on Granola, Fireflies, or an equivalent for every call. Auto-transcribe, summarize, extract action items. The user stops writing notes manually and stops missing decisions made in meetings the user was distracted during.
• AI email drafts (5 minutes). One prompt template that drafts all outgoing email. The user reviews and sends. Thirty to sixty minutes a day reclaimed per person at modest quality, more once the tone-of-voice file is calibrated.
• Daily AI briefing (10 minutes). A skill that reads the calendar, inbox, and chat for the prior day and generates a morning brief: what matters today, what is on fire, what needs attention. Replaces the thirty minutes of morning scanning that used to absorb the leader's first hour.
• Personal style guide (20 minutes). Collect the user's own writing samples, preferred document formats, visual taste, code style. Save as a reference file every skill uses. AI output starts matching the user's voice from day one, not after a long calibration period.
• Lesson capture (5 minutes a day). After every problem or mistake, write one sentence to lessons-hot.md. After fifty lessons, tier the file into HOT (loaded every session) and WARM (loaded only for relevant domains). Three months in, the agent stops repeating its own errors at a rate the user can measure.

The thirty-day arc that follows the Stage 0 setup runs in four phases. The phases are imperative because the practitioner is following a protocol, not reading an analysis.

Week 1 — route everything through the agent. Not to save time, but to record what actually saves time versus what feels like progress without producing measurable output. Keep a running log of what worked and what was a toy. Watch for the pattern METR documented in their 2025 study of experienced open-source developers using AI tools: developers self-reported a 24% speedup while measurement showed they ran 19% slower. The roughly forty-percentage-point gap between perception and reality means that in Week 1 the user cannot trust how the work feels. Measure against the prior week's concrete outputs, not against the felt sense of productivity.

Week 2 — encode the patterns that actually saved time. Take the three workflows from Week 1 that produced measurable output above the manual baseline and encode each as a skill file. A skill is an encoded worker rather than a prompt: it carries the role, the constraints, the escalation rules, and one or two examples. The discipline that matters in Week 2 is the practitioner rule: only encode what has been done at least twice. Everything else stays as a two-step manual pipeline and is never worth the maintenance overhead. Skills written for one-time tasks rot and burn token budget for output the user could have produced manually in less time.

Week 3 — encode judgment. Pick one decision the user makes repeatedly (a deal-scoring rubric, a hiring screen heuristic, a support-triage rule, an investment-memo checklist) and capture it in a skill file. The goal is not a perfect rule but a first-draft rubric the agent can apply while the user oversees it. The act of writing the rubric is itself the forcing function that reveals which of the user's own decisions were actually consistent and which were whatever-felt-right-on-the-day. The marker for a good Week 3 outcome is that a colleague can run the rubric and produce a result the user would have produced themselves.

Week 4 — measure. Against the Week 1 log, quantify what actually changed. Time saved, quality held, cost incurred, debugging overhead. Kill any workflow that looks good on feeling but fails on numbers. The Day-30 goal is three to five workflows running daily at adequate quality and known cost, plus one encoded judgment rubric. Twenty experiments running halfway is the failure mode, not the target.

Three Day-30 markers separate compounding from plateau

Three concrete markers indicate whether the Personal OS is compounding or plateauing.

Three to five daily workflows running at adequate quality. Morning brief, email drafts, meeting notes, one research-synthesis pattern, and one domain-specific workflow tied to the user's role. Not twenty. Five workflows running reliably and in rotation is the signal that practice has hardened into habit. More than that and nothing runs reliably because the user is splitting attention across pilots that never graduate.

Acceptance rate above 70%. The percentage of AI output the user accepts with minor edits or no edits on the workflows above. Below 70% means the user is doing the work twice (once by the agent, once by the rewrite) and no compounding is happening. The fix is almost never a better prompt. It is more context in the four files, or a lower acceptance bar on tasks where the user is not at the 99.9th percentile of expertise. Most leaders default to rewriting on autopilot because the rewrite reflex was the right behavior in the pre-AI era. Below expert-level on the specific task, the rewrite is now hurting the output quality more than the AI's first draft was.

One encoded judgment call. A single repeatable decision rubric (deal scoring, hiring screen, triage rule, writing-style check) captured as a skill file so the agent can apply the user's judgment on the user's behalf. This is the artifact that turns a personal workflow into organizational knowledge. It is the first thing that can be shared when the team adopts the pattern, and it is what the leader carries between roles or organizations because it encodes a piece of the leader rather than a piece of the company.

Autonomy at the personal layer

Most practitioners in 2026 operate their Personal OS at autonomy levels one and two: read-only briefs, drafts for review, agent-prepares-then-human-finalizes. The thirty-day protocol reliably moves a focused user to L2 on three to five workflows. Getting to L3 (the agent executes without asking every time) is a context-plus-evaluation problem rather than a skill problem. Three months of accumulated context in the lesson files, plus a rough evaluation harness that catches the characteristic failure modes on the user's specific workflow, is what earns the trust required for L3. Teams that try to move a personal workflow to L3 by just letting the agent try without the evaluation produce silent drift: plausible-looking output that is quietly wrong and stays wrong for a week because nobody was in the loop to catch it.

L4 at the personal layer is rare in 2026 and limited to well-defined adjuncts where the blast radius of a wrong answer is small and the action is reversible. Competitor monitoring, invoice extraction from known senders, inbox categorization, news-into-summary pipelines. The work that survives reaches L4 because each individual decision is cheap to override after the fact. Anything where a single wrong action moves real money or sends a public message stays at L2 until the eval harness gives strong evidence of reliability over months, not days.

Five ways the Personal OS fails

Five failure modes recur across 2026 practitioners. Each is paired with the underlying mechanism and the corrective.

Modifying AI output below the user's own expert level usually degrades it. Most tasks the user owns personally place the user below the 99.9th-percentile threshold where human judgment adds value to AI output. Below that threshold, every edit the user makes to the AI's output has a reasonable chance of reducing quality rather than improving it, because the user is modifying parts of a coherent whole without seeing the full dependency graph the agent held when producing the draft. The Dell'Acqua and Mollick BCG field experiment with 758 consultants put the bottom of the resulting output-quality distribution at the eighth percentile when partial human modification is applied below expert level. The practical rule at personal scale is to lower the acceptance bar to match the task rather than the ego. On tasks where the user is not a 99.9th-percentile expert, default to accepting AI output and spend review energy on outright failure modes (hallucinated data, broken dependencies, missed constraints) rather than aesthetic modification.

After three failures on the same task, stop re-prompting and add context. When the agent fails three times in a row on the same task, the failure is almost never the agent's intelligence. It is missing context. A typical case: an API credential lives outside the agent's sandbox, a file path the agent cannot see, a constraint the user mentioned in chat but never encoded, a tool the agent does not know how to invoke. The fix is always upstream of the prompt. Add the missing context to the org file, grant the missing permission, write a skill that captures the constraint. Re-prompting a fourth, fifth, and sixth time produces nearly identical failures and burns tokens for no diagnostic gain. The discipline is to treat the third failure as a signal to zoom out rather than as a signal to try again with more specific instructions.

Prompts getting longer over time signal missing context, not missing instructions. The common personal-scale failure happens when the user hits a wall and tries to rescue the interaction with a cleverer prompt. More instructions, more examples, more formatting rules. It almost never works because the fluent output is already pattern-matched from the training distribution. The missing ingredient is information about the user and the user's work that the agent has no way to know. The diagnostic is to track which is growing month over month: prompt length or context-file length. Prompts getting longer over time without context files growing is over-prompting, not under-instructing. The fix is to move the content that belongs in context into the org file and the identity file, leaving the prompts shorter.

Costs drift quietly because each individual session feels cheap. Personal use does not produce catastrophic incidents the way shared service accounts do, but it produces a quieter failure: spend that drifts from a few dollars a day to several hundred without the user noticing, because each individual session feels affordable in isolation. Three mitigations are sufficient at personal scale. Set a hard per-day token cap. Route tasks to model tiers at the skill level (cheap-tier for classification and summarization, frontier-tier only for the reasoning steps that need it). Run a weekly cost review. The pattern to watch is the day the daily spend stops surprising the user. That is usually the day it has become too high for the output the user is getting.

Skills installed from marketplaces run with the user's credentials. A skill is executable code the agent runs with whatever credentials the workspace exposes, not a passive data file. Several documented incidents in early 2026 involved popular skills that exfiltrated credentials or wrote unintended commands once installed. Three architectural rules are sufficient at the personal layer. Keep the agents that read untrusted content (web pages, email from unknown senders) separate from the agents that can execute code or send communications externally. No single agent should hold all three of read-untrusted, write-sensitive, and external-communication. Apply least-privilege MCP scopes (the news-reader agent does not need calendar write access). Treat third-party skills as code rather than as instructions. Read them before installing, and treat any skill that asks for broad scopes as misdesigned at best.

What a day in the system looks like

The end-to-end flow is the concrete illustration that ties the architecture together. The five steps below are the daily protocol.

1. Morning sync. The user runs the collection command. Connectors pull the last day of email, chat, and meeting transcripts into private/context/. The agent confirms what was synced and what failed.
2. Situational brief. The user runs the brief command. The skill reads the task list, the identity file, the organization file, and the freshly collected data. It produces a brief at ./content/briefs/<date>.md: what was done, what's in progress, what's planned, what needs attention. The user reviews the brief, updates the task list to reflect changes.
3. Deliverable work. The user runs a domain skill (the research command, the memo command, the redline command). The skill checks whether a project exists for the current topic. If yes, outputs go to private/projects/<slug>/deliverables/ or context/research/. If no, they go to ./content/research/ or ./content/memos/.
4. Multi-session handoff. When a topic graduates from one-off to ongoing, the user runs the create-project command. The skill scaffolds a project folder, links it from the task list, and seeds the project-scoped operating manual with the topic context. All future work on that topic lands in the project folder.
5. Evening close. The user updates the task list manually or asks the agent to reconcile it against the day's deliverables. New lessons go into the lesson file. Anything notable in tomorrow's calendar gets a one-line note.

The agent never has to be told any of this at runtime. It is all encoded in the workspace operating manual and the individual skill files. The user's job is to direct the work, not to repeat the protocol.

The bridge to team and what carries forward

The artifacts produced in the Personal OS are the seeds of the team version. The morning brief becomes the team standup agent. The style guide becomes the communication standard. The deal rubric becomes the team's due-diligence process. Which of these becomes a team standard is revealed over the next quarter as colleagues start asking for the artifacts the leader built. The leader does not have to choose what to share. The pull from the team identifies the artifacts that scale.

Three investments carry forward regardless of which AI platform, harness, or model tier wins the next cycle. Encoded identity and decision patterns in files are portable across any future harness and any change of employer; the four context files are the most durable asset the practitioner builds in this period. Company-specific skills matter because no vendor is going to write the exact rubric a particular team needs, and the skill is the durable asset even when the underlying model changes. Underlying architecture knowledge (context, skills, memory, tools, evaluations) transfers to any system that adopts the same pattern, while product-specific UI knowledge is obsolete within a generation.

Five durability properties keep the workspace pattern useful over time. The system is Git-native, so the whole workspace minus private/ can be version-controlled, forked, and diffed. It is model-agnostic, with no code coupling to a specific provider, because the operating manual is a prompt and the skills are prompts; swapping the underlying model leaves the rest intact. It is grep-debuggable, meaning the fix for output landing in the wrong place is a grep and a one-line edit in a skill file rather than a framework debugging session. It is incrementally adoptable, so a user can start with the setup command and one skill and pick up more over time without committing to the whole library. It is forkable per team, because another team can take the same structure, swap the org-context file, rename the command prefix, and have their own flavor of the operating system running in a day. The bet the pattern makes is that a well-organized folder plus a small library of conventionally-structured skills is more useful than a custom application, because the folder is legible to the user, the agent, and any tool in between, and because the cost of changing it is near zero.

The system combines three familiar ideas. GTD (Getting Things Done) gives the task list its structure: Now, Next, Waiting, Someday, Done. Second Brain and PARA-style organization (Projects, Areas, Resources, Archives) inspires the split between one-off content and project-scoped content. The instructions-plus-context pattern of modern AI agents is the substrate that lets these older ideas be executed by an AI rather than a human: a long-lived operating manual, per-task skill prompts, and readable on-disk state. None of the three ideas is new. The contribution is the specific packaging that makes them work together for a single practitioner.

Two extension paths matter once the core workspace is running. Match the tool shape to the person and role. CLI-native skills fit engineers living in the terminal. GUI desktop harnesses fit operators living in a visual environment. Messaging-first harnesses fit executives living in chat tools. The architecture underneath is the same; only the interaction surface differs. An executive and an engineer on the same team do not need to run the same harness for the workspace pattern to hold up across both. Add a retrieval layer when the corpus outgrows naive load. Some practitioners outgrow the base workspace as the corpus grows past roughly fifty files or absorbs streams of call transcripts and meeting notes. The upgrade path is a local hybrid-retrieval layer (SQLite index plus a daily entity-extraction job using a cheap-tier model, BM25 plus vector search plus an LLM rerank step) exposed as an MCP server the agent queries on demand. Tobi Lütke's open-source qmd repo (MIT-licensed, roughly 22.8K GitHub stars as of April 2026) is the citable reference implementation for this scale-up path. Start with files. Add retrieval when files outgrow naive load.

The complete reference implementation (design principles, folder layout, skill structure, daily flow, connector patterns, project scaffolding) ships in the book's public repo at docs/reference/team-ai-os.md. Written as the canonical concrete example of the pattern, intended to be forked, modified, and adapted rather than copied verbatim.

Run this week

A six-item time-boxed checklist for the practitioner who wants the Personal OS running by the end of the week.

1. Day 1 morning, 30 minutes. Install the harness, create the workspace folder, drop in the four context files. Pre-seed the org file from the team's existing documentation rather than writing it from scratch.
2. Day 1 afternoon, 30 minutes. Connect email and calendar via MCP. Run a meeting recorder on the next call. Verify that the agent can read the calendar and produce a one-paragraph brief on the next three meetings.
3. Day 2, 30 minutes. Capture the tone-of-voice file from three to five samples of the user's existing writing. Confirm that a draft email written by the agent reads like the user wrote it.
4. Day 3-5, 1 to 3 hours per day. Push the agent to do tasks the user does not yet think it can do. Keep a running log of what worked and what did not. The goal is calibration, not output.
5. Day 6. Pick the three patterns from the log that produced measurable output above the manual baseline. Encode each as a skill file with role, constraints, escalation rules, and one or two examples.
6. Day 7. Run the morning brief, the email-draft skill, and one of the encoded skills end-to-end. Update the lesson file with anything that broke. Set a calendar block for the same hour next week to review against today's outputs.

The goal of the first week is the calibration that the leader can only acquire through reps. Five workflows arrive at Day 30 if the practice holds for the four weeks that follow; Week 1 is not the moment to expect them.