My AI Personal Operating System - Version 2.0

Why I rebuilt it and how you can create one of your own

I’ve been running an AI Chief of Staff since February. For the first two months, I was doing it wrong and I didn’t know it, because it was still better than what I had before.

The spark was Justin Norris’s guest post in Kyle Poyar’s Growth Unhinged newsletter, “Becoming an AI-Native Operator.” Justin described using a ChatGPT project with a detailed system prompt as a Chief of Staff and doing morning check-ins and end-of-day reflections. He even shared the prompt.

I read it on a Sunday evening and had a ChatGPT custom GPT running by Monday morning.

Version 1.0 was really useful. I’d open it each morning, paste in my notes from the day before, talk through what was on my plate, and get something back that felt like a conversation with a smart, experienced mentor. The evening reflection piece — where I’d voice-memo my way through how the day actually went — turned out to be incredibly valuable. It was like having a thinking partner that asks one question at a time instead of just waiting for you to finish.

But my favorite part of all was how it took the emotion out of things. When I felt stressed, or worried, or anxious following a tough conversation or meeting — or when I’d start to read tone in Slack messages or emails — it would provide me with an unbiased perspective free of personal bias, and suggest strategies for how to respond. I used that advice and it worked EVERY SINGLE TIME.

I had a great working prototype of a Chief of Staff, but I was doing a lot of manual work to make it understand my unique context and adapt with my circumstances.

Where it broke

Every morning I had to paste in yesterday’s context, including call transcripts, data, and voice notes with information about the meetings coming up that day. Every evening I’d talk to it, using Wispr Flow, and provide a reflection on the day including what went well, where I had concerns, important things I learned, and new priorities or initiatives. If I forgot a step, the continuity was gone. And worse, the system had no memory across conversations, so what happened Tuesday and what I learned from it would be lost when I came back Thursday. Every session started cold.

The bigger problem was data. My Chief of Staff was only as smart as whatever I manually fed it. It didn’t know what was in my inbox, which ClickUp tasks were overdue, what meetings were coming up, who was who on my team, or what we talked about in meetings and on calls unless I uploaded or pasted the information in myself.

I was both the integration layer and the memory.

Justin’s piece actually flags this directly. He notes that for the vision of AI-native knowledge work to be real, context needs to be continuous across sessions — and that anything more sophisticated typically requires “custom tooling.” He gave the process a 7/10 for where things stand today.

After a few months of using it, I knew that I wanted the other 3 points.

You cannot architect what you have not experienced

Here’s what I know now that I didn’t know in February: it’s really hard to build the right system the first time. You have to use something imperfect, feel exactly where it fails you, and then build toward that.

My ChatGPT Chief of Staff failed me in the same two places every week. First, I’d show up to my Monday planning meeting and realize I’d forgotten to carry forward some commitment I’d made in a Thursday meeting. Second, the weekly update I sent to Sequel’s leadership team still took me 30 to 45 minutes to assemble because I was manually pulling numbers from HubSpot, reconciling them against our ClickUp OKR targets, and then writing the narrative from memory.

Both problems had the same root cause. The system was smart in conversation and blind to everything outside of it.

You cannot architect what you have not experienced. Version 1 is research. Version 2 is the system.

That’s what I built.

What I rebuilt - and why I built it in Claude Code

I did more than build a better Chief of Staff. I created a personal operating system. And instead of using a custom GPT, the new system lives in Claude Code. This was a key architectural decision because Claude Code is a command-line tool that can read files, run scripts, query databases, and string tools together in ways that the ChatGPT, Claude AI and even Claude Cowork cannot.

The new system has four components:

• AI Chief of Staff: Daily morning briefings and evening reflections

• Weekly Executive Marketing Update: An automated exec report that pulls from live data and is designed to be shared with Sequel’s leadership team

• Big Rocks Identifier: A weekly top-5 priority synthesis that runs before my Monday planning meeting.

• Team Roster: Institutional memory of everyone on the team, including their roles, team assignments and reporting lines.

All four share foundational infrastructure, and the thing that makes them work together is a nightly GitHub Actions workflow that pulls every meeting transcript from Granola — my meeting recorder — and writes them to a Supabase database. From there, Claude can query them directly via MCP. That shared database is what makes the whole thing coherent. Every component is reading from the same source of truth.

💡 In the following sections, I detail how I built it. If you want to recreate something similar for yourself, you can use these detailed instructions. Just give these directly to Claude Code and ask it to build the system — no need to build each step manually (and no need for coding skills).

Here’s more detail on each of the four components:

1. AI Chief of Staff

This runs daily. Every morning, I open the project and say “brief me,” and within about a minute I have a structured debrief of everything that happened yesterday. It draws from three live sources simultaneously:

1. My Granola transcripts in Supabase (every meeting, synthesized and attributed)

2. ClickUp (overdue tasks and anything due in the next two days)

3. Superhuman (inbox scan flagging anything time-sensitive or needing a reply).

The output is structured as:

• Yesterday at a glance

• Action items extracted from transcripts

• Decisions made

• Things to watch

• One strategic observation

• Task status

• Updates from my emails.

At the end, Claude presents the action items as a numbered list and asks which ones I want added to ClickUp. I say “1, 3” or “all” — and it creates the tasks, assigned to me, with the meeting source in the description.

The evening mode is different. When I say “let’s debrief,” Claude invites me to share how the day went and follows my lead, asking one question at a time — what went well and why it worked, what I’d handle differently, how I showed up as a leader. It’s the feedback loop that helps the system get to know me better and makes the whole thing more effective at giving advice that is tailored to my personality and leadership style.

2. Weekly Executive Marketing Update

Every Monday I send an executive-level marketing update to Sequel’s leadership team. It used to take me 30 to 45 minutes. Now I type /weekly-update and have a draft in under two minutes. It pulls live pipeline data from HubSpot (MTD demos vs. target, pipeline value created, top channels by volume), OKR targets from ClickUp, and narrative content from the prior week’s Granola transcripts.

The output has six sections:

1. A revenue snapshot with numbers

2. What’s working

3. What’s lagging with one-line remediation notes

4. Key decisions from the week

5. Focus for the coming week

6. Asks addressed to specific executives by name

Tone rules are enforced in the system prompt which calls for short bullets only, leading with numbers, and no over-explaining.

3. Big Rocks Identifier

At Sequel, we run weekly company-wide sprints, with every member of the team committing to a short list of “big rocks” (key priorities) that we will accomplish that week. These are shared in a company-wide weekly business planning meeting held every Monday.

Every Sunday evening or Monday morning, before our the weekly business planning meeting, I run /weekly-rocks. It queries ClickUp for everything assigned to me that’s due in the next seven days or overdue in the past thirty, then scans the prior week’s meeting transcripts for every commitment I made — any time I said “I’ll,” “I will,” or “I can get that done,” any deadline that was mentioned, any item that came up across multiple conversations.

Then it applies a scoring framework and returns exactly five priorities, ranked, each with an action-oriented name, one sentence on why it made the list, and a due date. If there aren’t five clear rocks, it says so and gives me three.

4. Team Roster

This one is different from the other three — it’s a static file, not a live query. It’s a list of every team member at Sequel including:

• Full name spelled correctly

• Title

• Department

• Manager

This might seem like a small thing but it has actually made a massive difference in helping the other parts of my operating system understand who’s who, discern which conversations relate to marketing, and how our various internal teams are working together.

It’s particularly important because we have two Andreis (our CTO and our Creative Director), a CEO named Oana and a Sales AE named Ioana, two Nathans (an AE and a product marketer) and several names that autocorrect reliably mangles.

The CLAUDE.md project instructions tell Claude to load the roster any time a person is mentioned in a task. So every piece of communication, every update, every analysis involving the team is automatically grounded in accurate information. It’s passive — it just runs in the background and prevents a lot of mistakes.

The 3 things that actually make it smart

This is the part I want to be precise about, because it’s the part that gets glossed over in most “I built an AI workflow” write-ups.

Three things separate this system from every other AI assistant I've used. None of them work automatically in Claude.ai or Claude Cowork. All three required deliberate engineering. And they're the reason this had to be built in Claude Code rather than a Claude project.

1. Persistent memory across conversations

Every session Claude runs in a project is isolated by default. There’s no memory of what happened in the session before unless you build it and in Claud AI that typically requires a manual process where you ask Claude to summarize learnings and then copy that summary into a project file which you then need to re-upload into the project knowledge base. My goal was to eliminate those types of manual steps altogether.

My new Chief of Staff maintains four memory files that Claude writes to proactively whenever something worth capturing surfaces including feedback from a key member of the team (which it can identify automatically thanks to the roster I created) or new patterns that show up in my evening reflection.

Every subsequent morning briefing loads those memory files first. The system accumulates knowledge about how I work, what I’ve learned, and what I keep getting wrong. Basically, it gets smarter over time without me doing anything.

2. Live data

The recursive learning doesn’t just apply to my preferences — it applies to the world I’m operating in. Because meeting transcripts sync to Supabase every night, new commitments surface in next week’s Big Rocks synthesis without any configuration changes.

The MCP connections to ClickUp, HubSpot, and Superhuman mean every output is generated from current information, not whatever I remembered to paste in. The system knows what happened — because it has direct access to where things happened.

3. Recursive learning

The first two features give the system eyes and a memory. Recursive learning gives it the ability to improve its own outputs over time without me reconfiguring anything. To me, this was the single most important feature — and one of the main reasons I chose to build the system in Claude Code.

Here’s how it works:

• After the weekly update is generated and I’ve reviewed it, the system asks “any feedback for next week?”

• Whatever I say (ex. change the order of sections, stop including that metric, always lead with QTD not MTD) gets written immediately to a set of preference files. format_preferences.md, section_feedback.md, recurring_context.md.

• Entries accumulate, meaning that nothing is overwritten and every subsequent weekly update loads those files before generating anything.

The same loop runs across the Chief of Staff and the Big Rocks tool. The system isn’t just executing a static prompt — it’s executing a prompt that gets annotated with everything it has learned about what good output looks like for me specifically.

This means that in week one, I’m spending some time editing each draft, but by week six, I should barely need to touch it.

This is also the core reason I couldn’t build this in Claude.ai or Cowork. In Claude.ai, the model has access to a memory feature — but it’s a black box. The model decides what to store, you can’t inspect it directly, and you can’t guarantee it will surface the right context at the right moment. Claude Code writes to readable .md files that I can open, edit, and verify. Claude then reads them deterministically at the start of each session as part of the project instructions. The memory is transparent, portable, and fully under my control.

The goal is that every morning briefing benefits from everything I’ve learned in every prior session. Without these features, you have a very expensive to-do list.

Without all three of these — persistent memory, live data, and recursive learning — you have a very sophisticated search tool. With them, you have something that gets measurably better every week without you doing anything to make it so.

Why I almost built the wrong thing

My first instinct was to have this system push updates to me in the form of a morning Slack message or an evening email digest. That approach seemed like the right one because it felt clean, automated, and low friction.

That would have been a mistake.

Delivery by Slack or email turns the system into a report. You read it, maybe act on it, and close it, but there’s no back-and-forth. There’s no “wait, what did I commit to in that Thursday call with the product team?” or “show me all the meetings where we discussed the website project this month.”

The conversational layer was a must for me. I don’t just want to be briefed on my data — I want to be able to interrogate it. When the Big Rocks output surfaces something I didn’t expect, I want to ask why it ranked that item third, and when the weekly update draft has a narrative section that feels slightly off, I want to push on it in context, not start over in a new window.

A push notification can tell you what happened. A conversation can help you figure out what to do about it.

The right tasks for this kind of build

Here’s what I’d offer to anyone thinking about whether to build something like this: not every workflow is a candidate.

The tasks I built around — morning briefings, weekly updates, priority synthesis — have three things in common:

• They’re repetitive

• They happen on a fixed cadence

• They require pulling from multiple data sources that I already have access to but don’t have time to manually reconcile every time

That’s the pattern worth scanning for. Ask yourself “what do I spend time on, repeatedly, week after week, that follows a predictable process?” Those are the builds that you should start with.

What it actually changed

The morning briefing takes two minutes to read instead of thirty minutes to reconstruct from memory. The weekly update takes two minutes to generate instead of forty-five minutes to write. Big Rocks takes two minutes to synthesize instead of a half-hour of mental overhead before Monday’s meeting.

That’s not the real gain.

The real gain is that I start every week with accumulated intelligence about how I work. The system has read every meeting I’ve attended since I turned it on. It knows what I tend to over-commit to. It knows what the CEO and leadership team care about when they review marketing updates. It knows which of my recurring priorities keep slipping week to week.

I built Version 1 in a Sunday evening. Version 2 took about 4 hours, but only after I used Version 1 for a few months in order to understand what was missing.

That’s the thing about building AI systems. The prompt you get from someone else’s newsletter is a starting point. The system you actually need is the one you discover by using something imperfect and paying attention to where it fails you.

— Kathleen

💡Get my detailed instructions for building your own personal operating system here.

---

Tools, platforms & resources mentioned in this issue

Growth Unhinged — Kyle Poyar’s weekly newsletter on the hidden playbooks behind fast-growing startups. The original article that inspired Version 1 is here.

Claude Code — Anthropic’s command-line tool for agentic coding and multi-step task execution. Not the chat interface — the terminal-based tool that can read files, run scripts, and query databases. This is where the system lives.

Granola — AI meeting recorder and transcript tool. Every meeting I attend gets transcribed here; a nightly GitHub Actions workflow syncs those transcripts to Supabase.

Supabase — Open-source database platform. Serves as the central data store for meeting transcripts, queryable by Claude via MCP.

MCP (Model Context Protocol) — Anthropic’s standard for connecting Claude to external tools and data sources. The connectors to Supabase, ClickUp, HubSpot, and Superhuman all run through MCP.

GitHub — The automation layer running the nightly Granola → Supabase sync at 1:00 AM UTC.

ClickUp — Task and project management tool. Queried via MCP for task status, overdue items, and OKR targets.

HubSpot — CRM. Queried via MCP for pipeline data in the weekly executive update.

Superhuman — Email client. Queried via MCP for the inbox scan in the morning briefing.

---

💜 A note on my content:

Yes, I use AI to help me write this newsletter. Every idea, insight, and point of view here is mine. AI helps me think, structure, and draft — it does not replace my judgment. I also use em dashes (and emojis 👀) unapologetically, sometimes because AI likes them, and sometimes because they’re grammatically correct. If you’re here to sniff out “what was written by AI,” you’ll probably be disappointed. And if you’re fundamentally against the use of AI in writing, this newsletter is likely not for you. You’ll find this disclaimer in every issue, because transparency matters to me.