Every morning, I was still the glue.
I would check Calendar to see what was coming up. Then Gmail to see who needed a reply. Then Slack to see what changed. Then Granola to remember what happened in yesterday’s meetings. Then Notion or Obsidian to check the work I said mattered.
After all of that, I would open AI and ask it to help me plan the day.
The weird part was that AI was already useful in each individual step.
It could summarize the meeting. It could draft the reply. It could help me think through the project. It could turn scattered notes into a plan.
But I was still the person connecting everything together.
AI gave me the output.
I moved the output into the rest of my work.
That is the human-middleman problem.
The Old AI Workflow Has A Ceiling
For the last couple of years, this was still useful.
We opened ChatGPT or Claude. We asked for help. We copied the answer into Google Docs, Gmail, Slack, Notion, Asana, ClickUp, Sheets, or wherever the real work needed to happen.
Honestly, that first wave changed how I wrote, researched, planned, learned, and built things. I would not be writing AI Maker the way I do without it.
But the pattern had a ceiling.
AI lived in one place. My work lived everywhere else. So even when the answer was good, the handoff was still mine. That is why this year feels different to me.
I have written before about the shift toward the agentic era. The short version is that AI is moving from “answer my question” to “help execute the work.”
Claude Code, Codex, Cowork, and tools like them are not just better chat boxes. They can read files. They can work with connected apps. They can run tasks. They can move closer to the tools where work actually happens.
Given enough context, an AI agent can help with large parts of knowledge work end to end. It can research, plan, draft, review, organize, and prepare the next step.
I know that still sounds a little too big when I say it that way.
And to be clear, I do not think this means you hand your work to an agent and disappear. That is not the version I am trying to build.
The part that excites me is more specific: removing more of the mechanical middle layer so I can spend more time on the work that still needs my judgment.
Strategic thinking. Creative work. Writing. Research.
That is where this Chief of Staff idea came from.
Access Alone Does Not Fix It
When we talk about building an AI Chief of Staff, we mean an AI that can help me set my priorities and execute on them.
Because my work is scattered across multiple apps, the first instinct is to think the problem will be solved once AI connects to enough of them: Gmail, Calendar, Slack, Drive, Notion, Granola, and many more.
But access alone creates a new problem.
Now the AI can see more things, but it still may not know what matters.
It can see your calendar, but it does not automatically know which meeting needs preparation. It can read a transcript, but it does not automatically know which promise should carry into next week. It can find an email, but it does not automatically know whether the person is a customer, a collaborator, a friend, a cold lead, or someone you should ignore.
That is where the context layer matters.
The agent needs to know who you are, what you do, what you are building, who you work with, what happened recently, what you promised, and what matters this week.
Without that, it might summarize everything correctly and still miss the point.
But context alone does not remove the morning loop.
If I still have to wake up, open the tool, paste the prompt, point it at the right files, ask it to check the calendar, ask it to review the meeting notes, ask it to create the brief, and copy the result somewhere useful, I am still doing the mechanical work.
The answer was access plus context plus repeatable jobs that can run at the right time.
That combination is what made the Chief of Staff idea feel more useful than just an AI that can do stuff.
What I Actually Wanted From A Chief Of Staff
I did not want a giant AI employee that runs my life.
I wanted something that could look across the places where my work already lives and tell me what matters today.
That was the first job: daily priorities.
Because that is where the scattered-context problem shows up every morning.
If I have three meetings, fifteen unread emails, two open promises from yesterday, one transcript I have not processed, and a paid post I said I would finish, I do not need another generic productivity plan.
I need a system that can say:
Here is what is actually on your plate today.
Here are the meetings that need preparation.
Here are the open loops you should not forget.
Here are the emails or messages that might matter.
Here are the drafts waiting for your approval.
That is the kind of Chief of Staff I wanted to build first.
What We Are Building: The Chief of Staff
The version I have working now is built around four layers:
Source layer: the apps and files the system can read.
Context layer: the folder that tells it what matters.
Skill layer: the repeatable jobs it can run.
Automation layer: the scheduled runs that make useful work show up.
By the end of this build, you should have a small, working version of the system by copying from the folder I’m sharing, which includes:
A source setup that shows the AI where to look: Calendar, Gmail, Drive, Notion, Granola, etc.
A folder that explains what matters in your work.
A few reusable skills for daily briefs, meeting prep, follow-ups, and reviews.
A simple automation pattern so the useful parts can show up without you remembering to ask.
Approval rules so the system can help without quietly taking over.
If it works, your morning should feel different.
Instead of opening six apps before you know what matters, the first pass is already waiting for you. Instead of digging through yesterday’s transcript, the open loops are surfaced. Instead of rewriting the same prompt every morning, the recurring jobs have a place to live.
I still review the output, make the decisions, and approve anything sensitive. But I am no longer the person initiating every mechanical step.
The Chief of Staff is the type of AI agent I want in my life that can read the right sources, prepare my day, track open loops, and draft the next useful step while keeping anything sensitive behind approval.
You can build it in Claude Code, Codex, or Cowork. Regardless of the model or the app, it works across them. The Claude ecosystem will read CLAUDE.md, while Codex will read AGENTS.md as the brain of the system.
In this walkthrough, however, we are going to use Claude Desktop or Cowork instead.
Let’s dive into the first layer: Source.
1. Connect The Source Layer
The source layer is where the Chief of Staff gets the raw material it needs before it can prepare anything useful.
For my setup, the possible sources are Gmail, Calendar, Slack, Google Drive, Notion, Granola.
Yours may be different. The first thing you need to do is map out which apps you’ve been using in your work. This could include tools like Microsoft 365, Atlassian, ClickUp, Monday, Otter, Fireflies, Zoom, or Asana.
What we want to focus on in this layer is where AI can access your work, including projects, commitments, and people you interact with on a daily basis. Don’t overcomplicate it—start small.
How To Connect Sources In Claude
Fortunately, Anthropic has already most knowledge work apps integrated through their MCPs connectors. The integration process should be easier as you just need to authenticate your Claude into the apps account.
If an app requires a custom connector, you may need to add a remote MCP connector URL before authenticating.
To add MCP connection, go to Customize menu on the left side bar in Claude Desktop app and click “+” to add connectors.
All those apps under Anthropic Partners don’t require custom MCP connectors, so I’m sure you can integrate them instantly.
Just find the apps you are looking for and start integrating them.
After connecting, test them in a simple chat before building the whole system.
For example (Google Calendar):
“Look at my calendar for today and summarize my schedule.”
Then (Gmail):
“Look at recent Gmail messages that may need my attention today. Do not draft replies yet. Just summarize possible action items.”
You can also check your meeting transcript (Granola):
“Get my meeting transcript yesterday on Granola and summarize them for me.”
The goal is to know whether Claude can actually see the sources before you build system around them.
What To Connect First
Here is the order I would use:
Google Calendar.
Gmail.
Google Drive or local folder.
Granola or another meeting transcript source.
Notion or Asana or Clickup/Monday.com as project management tools.
Slack or team chat.
Task tools, CRM, or extra databases.
This is a good enough list as the starting point.
However, I would be very cautious with Slack specifically and treat it as optional.
Slack is useful because a lot of real work happens there, but it is also noisy. If you connect it too early, your morning brief can turn into a pile of messages instead of a useful plan.
My recommendation:
Do not connect Slack until the Calendar, Gmail, and folder version is already useful.
When you do connect Slack, start narrow:
Direct messages.
Mentions.
One or two important channels.
Do not start with the entire team history. That is how the system becomes overwhelming too quickly.
What To Avoid On Day One
I would not connect:
Every Slack channel.
Every Notion page.
Every client folder.
Every transcript archive.
Every task database.
That sounds like a stronger system, but it usually makes the first version worse. You want the Chief of Staff to answer a narrow question first:
“What matters today?”
Once it can answer that reliably, you can widen the sources.
The First Source Test
Before building the folder templates, I would run one simple test.
Ask the AI:
“Using my connected Calendar and Gmail, tell me what may need my attention today. Do not draft anything. Do not send anything. Just identify possible priorities, meetings that need prep, and open loops.”
The output will probably be useful, but incomplete.
That is the point.
It should show you what app access can do by itself, and what is still missing.
Most likely, it will know what is on the calendar. It may find a few email threads. It may identify obvious action items.
But it will not fully know which projects matter, who matters, what you promised last week, how you prefer to work, or which things should stay behind approval.
That is why the next step is the folder.
The source layer lets the AI see the work.
The folder tells it how to understand the work.
2. Build The Context Layer
The context layer is the folder that makes the Chief of Staff useful, but this is where I think a lot of AI systems quietly fail.
People connect the apps first. Calendar, Gmail, Slack, Drive, Notion, all of it. Then they expect the AI to know what matters.
The issue is a calendar event does not explain why the meeting matters. An email does not explain whether the sender is a close collaborator, a paid subscriber, a consulting client, a friend, or someone I should ignore. A transcript does not explain which promise should carry into next week.
The folder fills that gap.
For this build, the context layer is just a set of plain files:
chief-of-staff/
├── AGENTS.md
├── CLAUDE.md
├── about-me.md
├── my-work.md
├── tomorrow.md
├── commitments.md
├── people/
├── meetings/
└── briefs/Nothing about this has to be fancy. You can put this in Google Drive, a local folder, or whatever place your AI tool can read.
The goal is practical: give the AI enough stable context that it stops treating every morning like a blank conversation.
The Minimum File
If you want the smallest useful version, start with five files:
AGENTS.md for Codex or CLAUDE.md for Claude
about-me.md
my-work.md
tomorrow.md
commitments.md
That is enough to make the first morning brief much better. You can add people/, meetings/, and briefs/ once the first version works. The mistake I would avoid is filling every file perfectly before running the system.
Instead, you should fill each file just enough, run the Morning Brief, and then improve the files when the output reveals what’s missing.
Now, let’s explore what each file’s main function is and how to customize it for your case.
CLAUDE.md / AGENTS.md: The Operating Manual
The operating manual is the file the Chief of Staff reads first.
In the folder I’m sharing here, I include a CLAUDE.md version because Claude Code or Cowork already knows to read that file. If you are building this in Codex, use the same structure in AGENTS.md.
This file tells the AI:
What is the job of this Chief of Staff?
Which files should it read first?
What can it do without asking?
What needs approval?
What should it do when it is uncertain?
What output format should it use?
Which skills are available?
How it should handle source conflicts.
The template has eleven sections:
Role.
Reading order.
Approval rules.
Uncertainty rules.
Output format defaults.
Source priority.
File map.
Available skills.
Voice.
When to push back.
Maintenance.
That sounds like a lot, but the file is doing one simple thing: It tells the AI how to behave before it touches the rest of the folder.
Here is the template I would use myself that you can customize it yourself:
