My calendar lied to me, and I have only myself to blame

The fire was in the calendar. Specifically, my calendar had begun lying to me, and I was the one who had taught it how.

I think a lot of us are doing some version of juggling more software than we have working memory for: calendars, task managers, note-taking apps, AI assistants, time trackers, journals, project boards. Every single one of them, at some point, leans across the table and makes the same Faustian proposal: let me be the one. Let me be the source of truth.

I have been building my “personal operating system” for years. It runs the way I work, which means it has to answer four very different kinds of questions: what am I doing, what did I just do, what am I going to do next, and where do I want to be.

Every time I add a new tool to the stack or “optimize,” I am implicitly making the same decision: which of those questions does this thing answer, and what happens if I let it answer more than one?

I made that call badly this April. A few days later, the wheels came off. Here is what I did, why it broke, and the small framework that survived.

Three weeks ago, filled with hubris because “AI can do everything,” I decided that my Google Calendar should be the single source of truth for what mode I was in throughout the day. Claude Code would manage it all for me as my personal assistant.

Single source of truth is what software people call a thing they would very much like to believe in.

I wanted to believe in it.

The mechanism was almost cute. Alongside the regular meeting placeholders, I started adding logs to record how I actually spent the day & time blocks for what we’ll laughingly refer to as a “plan to protect my focus.”

Every event title would carry a little state emoji and a mode word. ☐ Create: for a writing block. 🤝Connect: for a meeting. 🛠 Refine: for editing. 📞 Decide: for triage. Walking break? Strip the prefix. “Look at my todo list and fill up the day in 6 minute intervals with what I’m going to do next.” Slack DM crashing into a carefully curated Create block? Add ⚡ to the 1-minute calendar event to mark the interrupt. Generate a report at end of the day, for some reason.

The rules quickly spun out of control, but at least it was all promptable; and the emojis made me feel like I was performing “organizing.”

All the while, my AI agents were running inside Claude, refactoring my calendar in the background like a pack of sweet, loyal, but not especially bright Dachshunds. Bless their hearts.

I had named the entire arrangement "Architecture v2" in my system docs because I am the sort of person who versions his own life. And I’m the kind of person that maintains “system docs” about my life, for that matter… as if I’m a robot, not a person.

Day one: it worked. Sort of. I caught myself relabeling a couple of events to match what had actually happened, and chalked it up to setup tax.

Day two: I spent 96 uninterrupted, highly focused minutes relabeling the past. Re-titling a Decide block that had become a Connect block. Inventing events retroactively so the timeline looked coherent. Editing yesterday until the calendar resembled a cleaned-up transcript instead of a record. I felt anxiety when I couldn’t remember exactly how many seconds I spent in that Zoom meeting.

The calendar wasn't telling me what I'd been doing. It had become a forecast that I was constantly retconning.

I was finding myself spending way too much of my day managing the calendar. Disturbingly, this practice started to feel like a prison of my own making, albeit color-coded by how banal the tasks were according to Claude.

It was when I actually felt the need to add “fix calendar entries” as a daily recurring event in my calendar that I sat with that snake eating its own tail for ninety-six seconds.

Then I promptly deleted Architecture v2.

The lesson, when I stopped bandaging the calendar and finally looked at the wound, was bigger than the calendar.

A personal operating system over-couples when one surface tries to be authoritative for too many sources of truth.

Engineers have a name for this. They call it the separation of concerns and treat it as a load-bearing wall. Break it, and the building does not collapse all at once; it just gets slower, weirder, and more expensive to live in until, eventually, somebody has to refactor… and inevitably, somebody always says, “it’s easier to just burn it down and start over.”

When somebody asks one calendar to be a planner and a record and a dashboard and an archive, the calendar starts lying. Because what else can it do? You assigned it four full-time jobs and only gave it twenty-four hours a day.

The jobs for my calendar:

This physics applies just as cleanly to a single person and their entire app stack, not just the calendar. I am not a server farm. I have, on a good day, perhaps three concurrent threads. But the over-coupling tax shows up all over the place because the underlying mechanism is about authority, not scale.

So I burned it down and rebuilt.

The question I now run before any more personal system hacking is some version of:

What is your job, and what happens when I ask you to do more than one?

Every surface in the stack should have an answer to: what are you allowed to be the truth about?

If two surfaces are competing for the same job, there can be a coordination problem, and it’ll manifest as friction or redundancy tax. Lots of mistrust and “going back and fixing things.”

The red flag is when it feels like I don’t know which app has the “correct” information (or, frankly, when I'm not bothering to ask why I need the information to be so “correct”).

If one surface is being asked to do too many jobs at once, I have over-coupling, and it’ll feel as if the tool is slowly making me crazy as it struggles to tell any truth at all.

Jack of all trades, etc etc.

The balance is somewhere in between.

I need time to find it.

Aviation and science worked all of this out about a hundred years ago. A pilot files a flight plan, then keeps a separate logbook of what the flight actually was, including the deviations… especially the deviations. (14 CFR § 61.51.)

A scientist writes a procedure, then keeps a separate bench notebook of how the experiment actually went. (Francis Crick's lab notebooks, Wellcome Collection.)

Sometimes the log looks like art

The reason this works isn't because pilots and scientists are unusually disciplined. It works because nobody in either field ever asked that the procedure document also serve as the record. They keep the lived thing and the planned thing on different pieces of paper, in different inks, on purpose.

A team at University College London ran a diary study in which they asked 20 academics to plan their work at the start of the day, then record what they actually got done by the end of the day. The gap, predictably, was big. Their finding, less predictably, was systematic: some kinds of work (email, coding) were reliably underestimated; others (writing, planning) were reliably overestimated. (Ahmetoglu, Brumby & Cox, "To Plan or Not to Plan?", CSCW 2020.)

The implication: vague, optimistic planning isn't a personal failing. It is the default behavior of human knowledge workers when our tools force planning and recording into the same surface. There is real, peer-reviewed, paper-and-PDF evidence that your calendar lies.

Rest assured, you are not unusually bad at this.

Andy is one of the more careful thinkers about (ahem) “tools for thinking.” He's the one who turned "evergreen notes" into a verb. His March 2025 patron letter describes a small, lovely thing: he had Claude generate an Obsidian plugin to track his houseplants, and, in the process, discovered what he thinks the actual shape of near-future software might be. Not a smarter app. Software you can bend, around the work and the life and the houseplants you actually have, instead of contorting yourself around the app. (Andy is not alone in this; Ink & Switch on local-first software and Geoffrey Litt on malleable software point at the same horizon.)

This is the same failure mode I hit with my calendar at a much smaller scale. When a tool is too rigid about what it owns, you end up working for the tool.

Please stop asking "Which app should I use?"

Try "which app will let me reshape it when my life shifts shape?"

Mitchell, a HashiCorp co-founder who has been building software at the underside of operating systems for two decades, wrote a quietly excellent piece in February about how AI actually entered his daily work. Not as an autonomous agent nor as his replacement.

AI is the end-of-day instrument: the last thirty minutes of his workday, every workday, is used to kick off agents that triage, draft, queue research, and prepare warm starts, so that the next morning begins with less blank-page drag.

The honest signal in there, especially for people leading teams: the AI workflow that sticks is the one that gives tomorrow morning slightly more momentum than today's.

So that is my dispatch from the small fire. It went out eventually after I admitted that no single page of paper had ever successfully been both a flight plan and a logbook at the same time, and there was no good reason to think my calendar would be the first.

The question I'd love to leave you with: what is the smallest surface in your stack that is quietly trying to do two jobs at once?

Reply and tell me. I am, against my better judgment, building a list.

On repeat this week: Tomorrow Never Knows, Phil Collins's cover of the Beatles.

Building: the rebuild of my Personal Operating System, the Board. It sounds grand, but it is, in fact, a series of very small text files.