A PM with an agent chief-of-staff

I run delivery across three client accounts on two Jira instances, plus the internal work of a consultancy. For the past few months, the first thing that happens in my working day is not me reading email. It's an agent reading everything, and briefing me.

I've written here about building agents for clients. This post is about the one I run on myself: what it actually does, how it's built, and the parts that failed. Especially the parts that failed, because that's where all the design came from.

The morning briefing

When I start a session, the agent scans both Jira instances for status changes, my inbox, Teams, today's calendar, meeting transcripts from a local recorder on my Mac, and my time tracking. It cross-references all of that against a task file, updates what moved, and produces one briefing: today's calendar, top three priorities, follow-ups due, what's new, what's blocked, and whether my logged hours match the work it can see I did.

The last one stings regularly. It's supposed to.

The same setup preps me for meetings (pulls the previous instance's transcript, open tickets, and what I promised last time), turns recorded refinement meetings into drafted Jira tickets I approve before anything is created, and assembles the weekly client status from actual Jira movement instead of memory.

The architecture is files

There is no vector database and no platform. The agent's memory is markdown files in a folder: a small router file, a core file with people and terminology, one file per project, one per person that matters. The router decides what gets loaded: a morning session loads roughly 15–25KB of context depending on which clients are on the calendar that day, and nothing else.

Files sound primitive. They are also diffable, portable, reviewable, and mine. When the agent gets something wrong, I open the file and fix the sentence. Try that with an embedding.

Everything interesting came from a failure

Memory went stale. Early on, facts about people lived in two places, and both drifted. The fix was structural: an index with one current line per person, and depth in a separate dossier. One place to update. The lesson generalizes — duplicated memory isn't redundancy, it's guaranteed contradiction.

The task list became a diary. Every sync appended a dated "new since yesterday" section, and within weeks the file was 300 lines of archaeology. Now there's a hard rule: the task list is a task list. Updates edit existing items in place; the journal lives elsewhere; the file has a line budget and a weekly archive that enforces it. Agents are enthusiastic appenders — containment has to be a rule, not a hope.

Warnings never died. The agent flags risks. That's part of its job description: I ask it to push back. But a flag that gets repeated every morning without being acted on isn't diligence, it's wallpaper. The rule now: a pushback flag that survives three mornings gets escalated into a forced decision, or dropped. Alerts must have a lifecycle.

Noise crowded out signal. Uptime reports, auto-resolved cloud alerts, recurring warnings that are "known, monitor only": the agent used to file them all as tasks. Now there's an explicit noise filter: they can appear in the briefing, they may not become work items. Deciding what the agent must ignore took as much care as deciding what it reads.

Each of those rules is written down in the agent's instructions, in plain language, and I add one every time something new goes wrong. That file is the real asset. The model behind it has changed several times; the rules survive every swap.

The same discipline I sell

If this sounds familiar, it's because it is the argument I make to clients about their agents: the model is a component, the operating discipline is the product. Human-in-the-loop isn't a checkbox here, it's the whole shape of the thing: the agent drafts, updates and flags; I decide, send and commit. It has no send button.

The honest summary after a few months: it doesn't make me faster at any single task. It makes the start of every day cheaper (no rebuilding context, no "what did I promise whom") and it makes dropped balls rare, because a file with a line budget and a lifecycle rule is remarkably bad at forgetting.

A chief of staff doesn't do the job for you. It makes sure you walk into the room already knowing everything you were supposed to know. Turns out you can build one.