Most knowledge work is context maintenance. The real job, the thing you were hired to do, sits on a base layer of remembering what was said in the meeting six weeks ago, what you owe whom by Friday, what the second-best option was when you picked the first one. The base layer leaks. By Wednesday you've forgotten three of yesterday's commitments.

This is the gap an executive assistant fills, when one exists. The traditional model is a person. Someone whose job is your continuity: they remember what you don't, redirect what you can't, and keep the week from collapsing into a stack of post-its.

That model is fine if you can afford it. Most people who do knowledge work cannot. And increasingly, even those who can are finding the continuity-keeping job has shifted shape. A person sat across from you isn't obviously the right tool any more. The work is too distributed, too async, too tangled with software. Half a CTO's decisions live in Slack threads. Half their inputs live in Linear and a Notion last visited in March. Half their commitments live in a calendar that doesn't know about the other half. Holding all that together is mostly a software job.

Which is good news, because you can write the software.

This series is about doing exactly that. Not "AI for productivity" (there's enough of that, most of it bad), but a particular shape of assistant, built differently from the ones the analyst class is selling. The shape is: a markdown repo, git, a handful of skills, and a small amount of glue. That's it. No SaaS bill, no vendor lock-in, no analytics dashboard pretending to be a tool. The thing you build is yours.

The CTO role is the worked example through this series. Partly because that's what the author has, partly because the CTO job is unusually well-suited to this treatment. The same substrate generalises to any executive role; we'll come back to that.

Why a repo, not an app

Three properties matter when you're building the base layer of someone's working life.

The first is that everything has to be inspectable. You should be able to read your assistant's memory at any time, change a sentence, and have the change take effect. SaaS dashboards fail this without trying. Plain text in a folder passes it without thinking.

The second is that history has to be cheap. You'll change your mind. Decisions you made in May will look different in October. The assistant's view of last quarter has to be reachable, and a thirty-second git log should bring it up. There's also the more pragmatic case: any assistant worth using will eventually edit its own memory, and at some point it will edit something you wanted left alone. History means rolling back is a small job, not an incident. SaaS tools either don't keep history, charge to access it, or store it in a format that's painful to query.

The third is that the substrate has to be programmable. The interesting work isn't "log this meeting." It's "given this meeting and the three before it, tell me whether the project is going to slip." That needs programs running over your context. Programs run over folders much more easily than they run over Notion.

Markdown in a git repo gives you all three for free. It's also the substrate every modern coding agent is best at (Claude Code, Cursor, the rest), so the same tools that build your assistant can use it. The circularity is a feature.

If git feels heavy, the same shape works on a cloud-synced folder: Google Drive, Dropbox, OneDrive, iCloud Drive. Version history comes with the territory; rollback is clunkier than git checkout but still there, which is the part that matters when the assistant has just deleted a playbook you actually wanted. The third property, programmability, takes a hit. Running programs over a Drive folder is less ergonomic than running them over a directory; you have a Google API where you wanted rg and find. For many roles the trade is fine.

Hosted agent environments tip the balance further. If your primary interface is Claude Cowork, or any other cloud-resident runtime, a cloud-synced folder isn't a fallback, it's the natural substrate: the agent already lives in the cloud, and the substrate may as well live there too. The git-repo version assumes you have a laptop your assistant runs on. The cloud-drive version doesn't. The series leads with the git-repo setup because that's the one where every move is cleanest to write down, and notes the cloud-folder equivalents (and the Cowork-on-Drive variant) where they differ.

What lives in the repo

The CTO version, in rough shape:

  • Playbooks: the things you've decided to do the same way every time. How to run a 1:1. How to interview a senior hire. How to evaluate a vendor. Each one is a markdown file, edited when you change your mind.
  • Decision records: one file per material decision, in the style of an Architectural Decision Record. The decision, the alternatives, the date, the reasoning. Searchable. Quotable. You'll reach for these more often than you'd guess, six months in.
  • Weekly reviews: a journal, but structured. What changed, what's outstanding, what to drop. Mostly written by the assistant from the week's evidence; you edit and confirm.
  • Project files: one folder per active project, with the brief, the open questions, and the decisions that have landed inside it.
  • People notes: what you know about the people you work with, that you'd be embarrassed to forget. Tactical, not gossipy.
  • Skills: a small library of one-page markdown files telling the assistant how to do a recurring task. Morning briefing. Council-of-five for hard decisions. Eval loops. One per repeatable shape of work.

Folder per concern, frontmatter conventions, an auto-built index. The skeleton is straightforward. The discipline is doing it.

Why the CTO works as the example

A CTO's job is mostly decisions about systems made under uncertainty: many of them, fast, with incomplete information. The output is mostly writing (design docs, decision records, reviews, hiring notes), interleaved with conversation. There's no production line; the work is the thinking.

This shape rewards an assistant unusually well. Because the work is mostly context-shuffling and writing, the assistant has something to do at every step. Because decisions are recorded, the assistant has a corpus to learn the executive's style from. Because it's high-leverage work, even a five per cent lift compounds.

But the substrate isn't CTO-shaped. Replace "Architectural Decision Record" with "client engagement note" and you have the same thing for a partner at a firm. Replace "playbook for 1:1s" with "playbook for board prep" and you have it for a CEO. Replace "weekly review" with "studio review" and you have it for the head of a creative team. The substrate generalises because knowledge work generalises: context, decisions, follow-ups, recurring shapes of writing.

The series leans on the CTO version (concrete is easier to learn from than abstract), but every piece ends with a "translate this for your role" note. If the substrate is right, the translation is mostly mechanical.

What's next

The next piece is the boring one: the repo skeleton, the conventions, the pre-commit hook that keeps the schema honest. Boring on purpose; the work has to sit on something. After that comes the first capability: a morning briefing that does what an EA's first hour used to do.

You can build any of this in an afternoon. The interesting question, which comes up throughout, is whether you trust it enough to use it on a Tuesday. That part takes longer.