A Week in My AI OS

TL;DR

A personal AI OS is the layer between you and your tools: persistent memory, scheduled routines, named specialists, a dashboard, reachable from any device. My week runs on three rhythms. A daily rhythm of automated briefings. An on-demand rhythm of work conversations that remember context. A periodic rhythm for training, metrics, and portfolio. The outcome: less time on the ambient tax of email, calendar, and coordination, more time on the handful of decisions that move the week.

The exec problem

Running a week as a founder or a principal is a fragmentation problem before it’s anything else. McKinsey put the email tax at 28 percent of the workweek back in 2012. Email volume has not gone down since. Gloria Mark’s UC Irvine lab, in the 2005 CHI paper that started the literature, measured the cost of an interruption at 25 minutes of refocus time. Harvard Business Review’s study of 27 large-company CEOs by Porter and Nohria put them at 72 percent of their total work time in meetings, averaging 37 meetings per week.

The scale differs for a founder or a family-office principal, but the shape is the same. The calendar owns the block, the inbox owns the interstitial, and what’s left is the work you actually wanted to do. Then there’s the other tax that doesn’t show up in any study: the repeated busy-work loops. Searching for the next lead to talk to, researching what a competitor just shipped, pulling a weekly status together across four tools. Each loop is small. Across a year they are the quiet majority of a week.

The software industry’s answer has been chatbots. Open a window, type a question, copy the answer back. Useful, and insufficient. A chatbot is a tool. An operating system is a layer. The difference shows up in the fifth week, not the first.

What I mean by “AI OS”

I use “AI OS” to mean five specific things. They are not futuristic, they are not speculative, and each one is cheap to build on its own. The value is in all five running together.

Persistent memory. A set of files the system reads before it answers. Who I am, what I’m working on, what I decided last week.
Scheduled routines. Jobs that run without me. A morning briefing arrives at 06:00. An agent triages overnight pull requests before I’m at my desk.
Named specialists. Personas with roles, not a single generic assistant. A strategist. A ghostwriter. A research analyst. Each one loads a different context and has its own tools to execute with.
A dashboard. One place to see what the system did, what it’s tracking, and what needs my attention.
Remote reachability. The system answers from my phone, my laptop, or a browser. Wherever I am, the same context.

This is different from the German-language enterprise framing of “KI als strategisches Betriebssystem,” which tends to mean governance, compliance, and CIO-layer tooling. A personal AI OS is the consumer end of the same idea. One user, one operator, one week’s worth of context.

The three rhythms

The week has a natural shape. Some things I want the system to do without asking. Some things I want to start on demand and have the system remember. Some things run on their own cadence: training, metrics, money. I label these the daily, on-demand, and periodic rhythms. Each has a distinct role in how a week unfolds.

Daily rhythm

The daily rhythm is what the system does while I’m asleep or getting ready. It delivers context before the first meeting, in a format I can read in five minutes, so that the rest of the day starts from information rather than from rummaging.

Morning briefing

A scheduled job runs at 06:00 and sends one email. It contains today’s meetings, tomorrow’s meetings, open tasks by project, and the two or three items from my goal document that I said I’d move this week. It doesn’t try to be smart. It aggregates what’s already true across calendars and task systems and presents it in one place.

The point of the briefing is not novelty. The point is that I no longer scan three apps before coffee. One email, five minutes, context loaded.

A daily strategy memo

A second scheduled job runs at 05:00. It goes deeper. It loads my five-year plan, my quarterly goals, my current project list, the last seven days of session notes, and asks: given what this person said they want this year, and given what they actually did last week, what is the single highest-leverage move they could make today?

The output is short, opinionated, and themed around one decision. It closes with a quote I’ve highlighted in a book. The strategy memo is not a summary. It’s a small, daily, low-stakes push against my own drift.

I have not seen this pattern described elsewhere in public discussion of AI OSes. It takes an afternoon of setup: a short persona prompt, one scheduled job, a memory file with your actual goals. The reason it doesn’t exist in most setups is not technical difficulty. It’s that most people haven’t written down what they’re trying to do this quarter in a form a model can load.

Agentic coding digest

An evening job, around 20:00, compiles what’s new in the agentic coding space: releases, essays worth reading, repository updates, community posts I’d otherwise miss. It runs while I’m making dinner. The output is a single email, sectioned, with the three to five items that actually deserve attention above a longer list I can skim.

This is a small example of a scheduled research agent. The template is generic: pick a topic you track professionally, define three or four sources of truth, have a daily job compile them. I track agentic coding because that’s what I’m using to build my SaaS startup and where my consulting practice lives. A biotech founder might track a set of journals and clinical-trial registries instead. The pattern is the same.

Calendar overview

The morning briefing already pulls today’s calendar into one email. When I want to look further out (“what does the rest of the week look like,” “where am I likely to run over,” “where am I double-booked”) I ask in conversation rather than opening the calendar UI. The system reads across all my calendars (read-access to five of them) and answers in prose, not a grid.

Google Calendar stays the source of truth. The briefing reads from it every morning, and the OS reads from it whenever I ask. The change is that I rarely have to open the calendar UI myself: the calendar feeds the OS, the OS answers the question, I stay in one surface.

On-demand rhythm

The on-demand rhythm is everything I start by talking. Project work, research, outreach, decisions. These don’t run on a schedule. They run when I open a chat window, and they remember what we said last time.

Pipeline filling

For cold outreach on the consulting side, the loop looks like this. I describe the ideal customer profile. The system pulls candidates from the sources I’ve wired up (LinkedIn searches, HN comments, GitHub repositories in a target space). For each candidate, a research agent does ten or fifteen minutes of desk research and writes a short brief: the company, what they’re working on, what the angle might be. A drafting agent then writes the outreach, in my voice, against a template I’ve iterated on. Nothing is sent. Everything lands in a review queue, where I read, edit, and approve.

The leverage here is specific. The research step was the bottleneck before. Writing a well-researched cold message used to cost me twenty minutes per person, which meant I didn’t send many. It now costs me two minutes of review, which means I send enough to actually learn what works.

This is the single most straightforward exec workflow in the whole OS. The component pieces (research, enrichment, drafting) exist in dozens of point tools. Connecting them in one voice-consistent, review-queued flow is what makes them worth running.

Ad-hoc project discussions that remember

When I start a conversation about Daycare Butler (our upcoming SaaS solution), the system already knows what Daycare Butler is, who the co-founder is, what shipped last sprint, what’s in the backlog, which regulatory bits are sticky. I didn’t paste any of that into the chat. A project memory file exists, gets loaded when the topic comes up, and the conversation starts where the last one ended.

This is the single biggest quality-of-life lift after the morning briefing. The ordinary ChatGPT or Claude experience resets every session. Context is expensive to rebuild. A persistent project memory file, updated at the end of each working session, turns every new conversation into a continuation.

The unlock is not magical retrieval. It’s the habit of writing a short note at the end of a session: here’s what we decided, here’s what’s open, here’s what’s next. The system then loads that note at the start of the next conversation on the same topic. Memory is a practice before it’s a technology.

Code review and workflow kickoff

For the engineering work, the on-demand surface is a chat window that can call a full agentic coding harness. I can ask it to review an open PR and it pulls the diff, compares against our coding standards, posts structured feedback. I can ask it to scaffold a new feature and it opens a branch, files the first commit. The engineering substrate this sits on is what I wrote about in Harness Engineering; the more autonomous version of the same loop is what my consulting practice deploys with engineering teams.

An exec reader who doesn’t code should read this as: the same pattern (specialist persona plus memory plus tool access) works for software development, it’s just that the tools it reaches for are a test runner and a pull-request API instead of a calendar or a mail client.

Periodic rhythm

The periodic rhythm is the layer that runs on its own cadence: health, metrics, money. Not daily, not only on demand, but present across the week in a way that a notebook or a spreadsheet is not.

Hyrox training coach

I train for Hyrox. The system holds the 13-week plan, knows which week I’m in, and adapts. When life reshuffles the schedule (a trip, an off day, my son’s daycare closing), I say so in conversation and the plan updates. When I finish a session, I describe what I did and how it felt, and the session gets logged. When I ask about nutrition the next day, the advice already accounts for what I trained.

The pattern generalises. A training coach is a persona plus a plan file plus a log that updates from conversation. The same shape works for language learning, physiotherapy protocols, or anything else with a plan and a log. What’s unusual is not the persona; every chatbot can play coach. What’s unusual is that the plan and the log persist, so the coach has continuity.

Scorecard that writes itself

I track a handful of metrics across health, training, and business progress. They live in a dashboard with charts and trend lines, the way any founder scorecard does. The specifics are mine; the shape is the point.

The difference is how they get updated. I don’t open the dashboard to log them. I say “I weighed 80.5 this morning” in a conversation about something else, and the weight gets logged. I mention I trained four times this week, the count goes in. A business-progress update after an invoice clears writes itself to the right metric without me opening the scorecard. The system recognises the pattern, picks the right metric, confirms it did, and carries on with the conversation we were having.

The scorecard writes itself. I’ve not seen this described in other practitioner essays. It’s not technically hard: a few keyword-to-metric mappings and a write endpoint. It’s unusual because most AI OS discussions focus on what the system does on your behalf, not what the system notices while you’re doing something else. The second category is smaller, quieter, and in my experience more valuable.

Portfolio drift checks

Once a week, and on demand whenever I ask, a portfolio agent reads my current holdings, compares them against my target allocation, and reports the drift. It doesn’t trade. It proposes. “You’re 4 points overweight in European equities, 3 points underweight in bonds. If you want to rebalance, here’s the smallest set of trades that would get you within tolerance.”

For a family-office principal or a boutique fund PM, this is the most transferable shape in the whole rhythm. You already have a target allocation. You already do drift checks manually or with an analyst. What an AI OS adds is that the drift check lives next to the calendar, the pipeline, and the morning briefing, so portfolio discipline is not a separate context switch. Same persona, same chat window, same memory.

The substrate

A quick tour of what’s underneath.

The dashboard. One web page with tabs: activity (what ran, what it produced), team (the specialists and what they’re working on), scorecard (the five metrics), pipeline (leads and outreach), calendar (the week), projects (status per project). The dashboard is a window into the system, not the system itself. It runs on the Mac mini at home and is reachable over a private network from any device.

The specialists. A small roster of named roles, each with a memory file and a prompt. A strategist for the morning memo. A ghostwriter for outreach and articles in my voice. A research analyst for deep dives. A portfolio role for allocation and drift. Plus a handful of role-specific ones (lead engineer, training coach, house manager) that each load different context. They route by topic, by file path, or by explicit mention.

Skills and memory. Procedural knowledge lives in skills, which are small self-contained workflows the system can invoke by name. Factual knowledge lives in a memory pyramid of structured files (always-loaded at the top, lazy-loaded by topic, searchable via a vector index at the bottom). This is the same pattern I described in Harness Engineering, applied to a personal rather than a team context.

Hardware. Any dedicated machine works. An old laptop, a spare desktop, a Windows PC, a virtual machine, a cloud sandbox. I run it on a Mac mini because it was cheap and I’m in the Apple universe. What matters is that the machine is dedicated. An AI OS needs real access to files, browsers, and tools to be effective, and that’s not access you want granted to the laptop where your private documents, photos, and logged-in banking tabs live. A separate machine, or an isolated VM, gives the system a runway without touching the parts of your life you’d rather keep out of reach.

Remote access. The Claude mobile app on my phone, the Claude desktop app when I’m at the laptop, and a browser dashboard for anything visual. The same memory, the same specialists, the same context, whichever surface I open.

A full walkthrough of the substrate, with templates, belongs in a separate article. This one is about what the week feels like, not how it’s wired.

What’s not there yet

Three gaps I’d flag for any reader thinking about building something similar. The honest list is part of the point.

Grocery list and household e-commerce. The model can write a shopping list. The missing piece is a reliable agentic checkout flow I’d trust with a credit card. Until the reliability of that is better than my supermarket app, I’m not wiring it up.

Meeting prep and post-call summaries. This is the single most cited exec use case I don’t yet have. Pre-call briefings (“you’re about to meet X, here’s what matters to them”) and post-call capture (“here’s what was decided, here are the action items”) are standard in published practitioner essays. Mine aren’t wired yet, largely because my calendar is currently dominated by internal and known contexts. It’s the next thing on my list.

Inbox automation beyond reading. The briefing reads email. It doesn’t reply, triage, or file anything. Outbound email still goes through me. I will relax that eventually, with a tight scope (templated replies for known-clean categories), but the cost of an inbox mistake is high enough that I’m letting this one accrue trust slowly.

Every AI OS has a list like this. The discipline is to keep the list visible, and to add to it from the weeks that feel most fragmented.

Monday-morning checklist

If you want to start building your own, the order matters. Steps 1, 4, and 7 you can do alone. Steps 2, 3, 5, and 6 are the hour or two of wiring where an engineer on hand (or an engineer-for-hire for an afternoon) pays for itself.

Write a one-page file about yourself. Name, role, projects, three current goals, working hours, the people and entities in your week. This is the always-loaded context. You will rewrite it five times in the first month. That’s normal.
Pick one specialist. Not three, not nine. One role you most wish you had. A strategist. A researcher. A coach. Give it a prompt that references the file from step 1.
Ship one scheduled job. The cheapest useful one is a morning briefing with today’s calendar and task list. One job, one email, fixed time.
Add a memory discipline. End each working session by telling the system to save state. A short “wrap up” or “save all” triggers a skill that walks the session, extracts the decisions, the open threads, and the next moves, and writes them to a file the specialist loads next time. Set it up once, run it every time. Without the routine the rest decays.
Wire one metric. Whatever you’re actually trying to move this quarter. Log it from conversation, not from a form. One metric is enough to see whether the scorecard pattern will work for you.
Add a second specialist. Only after the first one has been useful for two weeks. The second is easier than the first, because the scaffolding is in place.
Stop before you build everything. The value of an AI OS is not the feature count. It’s that the handful of things it does, it does every day without your attention. Thirty good turns a week beat three hundred mediocre ones.

Models will keep getting better. The substrate (persona, memory, scheduled routine, dashboard, remote access) is what makes each model upgrade compound instead of restart. The investment isn’t in the model, and it isn’t in any one tool. It’s in the layer you build on top.

If you want to talk about building a personal AI OS for your own week, or about rolling AI-driven development into your team, book a 30-minute working session.

FAQ

Q: Is this only for engineers? No. The substrate is technical (a repo, scheduled jobs, a dashboard), but the daily experience is a chat interface and a daily email. A non-technical founder can run it once it’s set up. The piece that needs an engineer, or an engineer-for-hire, is the initial wiring: identity file, one scheduled job, a memory store. After that the system is conversational.

Q: Do I need to run this locally? A personal AI OS lives wherever your data lives. Mine runs on a Mac mini at home and is reachable from anywhere via the Claude mobile app, the Claude desktop app, and a browser dashboard. You can run an equivalent on a cloud VM, on a laptop that’s always open, or on any setup that keeps one process alive. The substrate matters less than the discipline of writing things down where the agent can read them.

Q: What’s the difference between this and Lindy, Dust, or Notion AI? Those are great products. They are also department or team tools, built to sell into companies. A personal AI OS is one person’s operating system. It knows your training plan, your pipeline, your portfolio, your son’s school schedule. It has specialists you named. The line between personal and enterprise matters: shared tools optimise for the median user, a personal OS optimises for you.

Q: Can I build this without being technical? Partially. The chat interface (Claude, ChatGPT, Gemini) is fully conversational. The scheduled jobs and the memory store are not. If you don’t have an engineer on hand, start with the parts you can do yourself: write a context file about yourself, paste it into every new conversation, and save useful outputs into a note-taking app. That’s a minimum viable AI OS. You can also ask an AI to build the rest for you if you feel brave, but security matters: a poorly-wired AI OS is a machine that answers questions about you to whoever finds the endpoint. Theoretically possible without an engineer; in practice, the wiring is the part where you want someone who knows what they’re doing.

Q: Where do I start? One persona, one daily job, one memory file. Pick the role you most wish you had (strategist, researcher, coach). Schedule one thing it does every morning. Keep one file of facts about you that the persona loads every time. That’s the smallest working version. Everything after that is accretion.

Q: What does this cost to run? It’s a range, not a number. If you use a provider’s subscription (Claude, ChatGPT) and lean on its built-in tools, tens of Euros or Swiss francs a month cover one busy user. If you wire in independent tools on pay-per-API pricing, the same usage can reach the low hundreds. The bigger cost either way is attention during setup: a week or two of part-time wiring, then minutes a week once the loop is stable.

Q: Is my data private? It depends where you run it. Running locally keeps data on your machine until the model call goes out. Most cloud providers offer commercial terms that exclude your prompts from training. If sending anything to a cloud model is off the table, you can run a local model end-to-end: the hardware demand is higher, but it’s a real option where “data stays in the building” is a hard requirement. A personal AI OS makes all of this explicit: you choose which memory files exist, which fields go to which model, which jobs run where. That clarity is one of the quieter advantages over general-purpose chatbots.