How I built my AI Chief of Staff

#280 - May.2026

What if everyone can have a Chief of Staff who can take out the coordination burden, while partnering for strategic decisions? 

I've been struggling for a long time to remove a burden that all managers carry: tracking and coordination. Every time I tried to focus on deep work there was one more email, one more Slack channel, one more task to add to my to-dos, one more... 

Half of my day was mostly about catching up with a wave of information from the day before. A sense of being reactive all the time. Over the years, this got worse as the size of the team and number of projects got bigger.

I was using AI under the promise of removing repetitive tasks but I was scratching the surface: ad-hoc prompts here and there asking for a summary, generic questions about general things and, maybe, drafting a narrative for a business document. 

I needed a true partner. A Chief-of-Staff that could serve as my front-line barrier to filter noise from what's important.

So I tried to build it. My personal Chief-of-Staff. 

A way to connect all the relevant context with the wave of signals that crashed at the shore of each morning. I needed a system that helped me perform 10X better as a Manager, removing the admin load and allowing me to think more deeply as a Product Leader.

If you also struggle to make time for deeper work, I think this is for you.

AI agents

I was already playing with multi-agent workflows. But so far, most cases were about search and summarization. Useful. But not what I needed in my day-to-day. 

So I imagined the following "ideal" morning: what if, as soon as I get to the office, I got an executive brief of how my day looks, what are the important things ahead, an update across every project I care about, a list of updated tasks under my direct ownership and a strategic prioritization recommendation on what will move the needle for my team?

I thought that, if this was meant to be a process with roles and responsibilities, what would that team look like?

I started with these what-if questions to design a solution.

I thought that, if this was meant to be a process with roles and responsibilities, what would that team look like? So, I decided I needed: 

• An information seeker who knows all my communication channels, what information is relevant and what is noise. This person has a big network for getting news. 
• A project organizer who understands where each new piece of information fits, what is new vs. existing. This person loves structure and order.
• An executive assistant who knows me as a close partner. Knows about my team's goals. My personal goals. Calls out the things that I don't want to hear. And offers me perspective to make decisions. This person is my trusted advisor. 

I couldn't hire all three as real employees. 

So I tried to emulate them as AI agents. 

What started as a playground for testing later became an essential part of my daily routine as a Head of Products.

Building the system

I needed a few ingredients to run this process. 

First, a place to keep a knowledge base that could fuel all agents. I've been taking digital notes for years using Apple Notes. It has been my go-to tool for tracking reminders, to-dos, and project-specific notes. 

But then, I found Obsidian. 

If this is the first time you hear about Obsidian you can learn more here. In short: Obsidian is a note-taking app based on markdown files. At first it can feel overcomplicated (markdown files need to follow a specific format) but, once you get used to it, the complexity disappears. Obsidian also offers a rich knowledge graph that lets you connect and navigate between related notes. Knowledge repository: checked.

Second, I needed an intelligence engine. I used Claude for this. Before this system, I was already using Claude Projects. I stored documents in each Project and used them for chats. So I decided that instead of using specific Projects I was going to feed Claude with my entire Obsidian vault.

I can't say enough how the Obsidian + Claude combination is a super tool. 

Local markdown files become the context. Practical and efficient. Obsidian + Claude is like having a personal Google-like repository. Intelligence layer: checked.

Now I needed to design the workflow. 

I started by defining a few design tenets on how this system should work: 

1. I wanted it to be fast so it can run first thing in the morning (speed)
2. I wanted it to be smart enough and use as much context as possible (useful)
3. I would like to make it flexible to propose changes when needed (adaptable)
4. I wanted to be the final decision-maker (controlled)

I organized the information in Obsidian using a PARA-inspired structure. This structure helped me organize a place where new information can land, one for all context files, one for all active projects and one for all the rest. 

Vault/
├── 0. Inbox/                    ← Default landing zone
│   ├── MY TASKS.md                ← Central task tracker (single source of truth)
│   └── CONTEXT/                    ← Strategic context files (goals, team, stakeholders)
├── 0. Projects/                 ← Active project folders
│   └── {YYYY - Project Name}/
│       └── Project Status - {Name}.md  ← Per-project health file
├── 1. Areas/                    ← Ongoing areas (career, management, tools)
├── CLAUDE.md                       ← Project steering (auto-loaded every session)
├── .claude/
│   ├── agents/                     ← Agent prompt files (.md, spawned as subagents)
│   ├── commands/                   ← Slash commands (/project:<name>)

I think the most important part of this structure is the context folder. I wanted to ensure all agents got fresh context information. Things like strategic goals, yearly plans, product roadmap, team structure, stakeholder lists. Better context, better outcomes.

The second most important part of this structure was the project trackers. Each project folder has a home note where I track what's the project about, the latest status, key risks, key dependencies and milestones. 

Now I needed to define the tasks of each agent. A clear scope and output so that they could work as a team. Each output becoming the input for the next one. 

The Seeker

I created a Seeker Agent, responsible for scanning all my emails and Slack messages for the last 24 hours (I can override the timeframe if needed). The only purpose of this agent is to get information. 

Running it a few times, I quickly learned that I don't have infinite tokens and scanning a huge amount of information can take a lot of time. Context windows were crashing. I needed to separate noise from the important stuff. 

I fixed this by adding a high-low signal mechanism. How this works: before reading the entire email, the agent scans all context files and active projects and looks for key words in the title. If it matches the high-signal criteria the agent moves ahead and reads the entire message. This helped me skip ~60% of noise (OOO emails, general announcements, "thank-you" replies). For Slack channels, the solution was simpler: setting the specific channels to track and organizing all high-priority channels into a single section. All channels under this section are scanned by the agent.

The output of this agent is high-signal information that will feed my knowledge base (updates, risks, actions, callouts, more context from projects, etc.). Now I needed someone to organize all this.

The Organizer

The organizer agent...well, it...organizes. I needed to process everything that the Seeker got into its corresponding buckets. Updates into project updates, tasks into my to-do list, risks into risk tables. I designed the prompt of this agent to scan all active projects, make sense of information and move it into the right places.

I quickly learned that, without the right context, information gets duplicated or lands in the wrong places. This was clear when I started to see a list of 20+ risks in a project and they were the same 4 risks written in different forms and assigned to multiple people. 

The way I fixed this was by improving the context information (especially the list of projects and owners) and also forcing the agent to avoid duplicating information if it already existed. In case of ambiguity, I prefer it to add new notes (with a distinctive date) rather than rewriting or adding a new chunk of information. 

I was not looking for delegating my thinking, but to augment it. I needed a strategist agent.

At this point, I already had the logic for scanning all important information and organizing it into specific notes. The last ingredient is what bonds everything together:

A "thinking" partner. 

I was not looking for delegating my thinking, but to augment it. I needed a strategist agent.

The Strategist

I designed this agent to be a guardian of the strategy. We all struggle to keep perspective when times are challenging (urgent requests, escalations, conflicts, etc.). We confuse the urgent with what's important. Especially for managers, we lose perspective of what are the 2-3 things that create leverage and maximize the outcomes for the entire team. I wanted to use this agent as a daily reminder of what matters. 

I gave this agent access to the notes with information about the product strategy, what we want to accomplish during the year, my personal goals, and everything that can lead into outcome-driven recommendations. I tasked it with using all this information to help me think about 2-3 high-leverage things I should focus on. 

I also noticed that it's not just about giving it more context, but asking better questions.

When running this agent, I learned that these models are far from perfect. They constantly make assumptions that are mostly related to a lack of specific context. Yet, by using it and refining the context, results were getting better and better. 

I also noticed that it's not just about giving it more context, but asking better questions. I was getting better at using it and interacting with it.

More and more, I was starting to get recommendations I struggled to accept but, deep inside, I knew it was needed (hard decisions). This was the best sign that the agent was improving. Models are data driven. Emotions don't affect them. I taught it to tell me the hard truths, and it was doing its job pretty well.

There was one more thing that increased the quality of this agent's recommendations. I implemented a stochastic consensus (kudos to Nick Saraev for sharing this!). It sounds very fancy but, in simple words, this approach uses multiple agents to work on the same problem but solving it through different perspectives. The output is a consensus of what they all agree on, disagreements and contrarian thinking. I designed this consensus by using these perspectives: 

1. Practitioner (goals + monthly priorities)
2. Skeptic (high risks and overdue tasks)
3. Strategist (future leverage)
4. Contrarian (What should not be deprioritized)
5. Synthesizer (what is realistic + impactful)

They all run with the same task: What is the priority for today? This approach really improved the outcomes. The model was not relying on a single shot for a recommendation, but iterating over multiple perspectives. It was like having a team debating and coming to an agreement. 

My new team was complete. 

My experience using it

Before I even open my email every morning, the first thing I do is run the coordination prompt. This triggers the sequence of all 3 agents. The first one usually asks me for any overrides (for example, on weekends I ask for a larger scan window). 

They all start working on their tasks. In general the entire workflow takes around 10 minutes. 

Once ready, the strategist agent comes with a recommendation based on the analysis of priority. I can accept it, override it or ask for a new execution. When completed, the final output is a coordination report that is saved as a new note in my Obsidian vault. 

The coordination report includes

• Today's Outlook
• Agent results
• Override summary
• Critical items

The coordination reports have two purposes. The first one is getting details about the entire workflow run, and also a quick overview of my day (tasks and calendar), with the arguments behind the recommendation of priorities. 

The second purpose is reflecting on my work. These reports became a great source for running personal retrospectives. I built a skill that uses archived reports to give me a summary of how I'm allocating my time, common prioritization patterns and any improvements in the efficiency of the workflow. In fact, many of the rules I added later to this workflow came from inspiration from these retrospectives. 

What I've learned so far

The experience of building has given me direct exposure on how LLM agents work. Not theory from articles, but hands-on exposure. Now it's clear to me that the way we used to build software is changing. With LLMs, the quality of your questions and guidance makes a huge difference in the quality of what's built. 

With LLMs, the quality of your questions and guidance makes a huge difference in the quality of what's built. 

Some of the most important observations through my experience: 

1. These tools still fail. A lot. I've been running this workflow for the last 3 months, every day. Only now am I in a position where I can trust the outputs with some confidence. But early results were not that good. You need to put a lot of effort into iterating and refining to get something that is useful.
2. Context is everything. This workflow is only useful because of the quality of the context. Context is the best steering wheel for these models. Don't expect config files alone to be enough (e.g. Claude.md). Context is also constantly changing, so keeping these models accessing fresh information is the best way to increase their accuracy.
3. Tokens are finite. I developed a better appreciation of token consumption, not because I have any restriction at the moment, but for time efficiency. LLMs tend to default to long and detailed rule definitions. By making it think about optimizing tokens while keeping the same output, it can save you at least 30-40% in token consumption. 
4. Using the product becomes the best input for improvements. I realized that I was in a constant improvement loop. Every workflow execution became input for improvements. The product was improving daily. It just requires being aware of the positive and negative patterns and take action.

These systems are not meant to replace deep thinking. They augment it.

I really think I've become a better manager with this tool. Yet, agency and judgment are still on me. That's the leadership part no agent can replace.

¡Saludos!

César Rodríguez
LinkedIn / Instagram / X