How I replaced my PM stack with files + AI agents

August 9, 2026 · By Matt Roach, CPA

I've spent nearly two decades across consulting, audit, transaction services, and multi-entity operations — much of it leading management teams and change initiatives. Every version of that work carried the same overhead: administrative tracking, status updates, and the meetings that exist to repeat them. A real fraction of every week went to reporting on the work instead of doing it.

The solution finally snapped into focus when I launched a software company and ran the whole build with AI agents — Claude Code working out of a folder of plain context files. The folder already knew the status. Nothing had to be retyped into a tool for the tool to report it back out.

I call this the status-reporting tax, and I stopped paying it. This is a write-up of the system I replaced it with: plain files in a folder, a handful of conventions, and AI agents that read and write those files on a schedule. No new platform. No per-seat license. The task board, the daily brief, and the stakeholder update are all generated from the files where the work already lives.

This isn't a product pitch — most of what follows you can build yourself in a day. It's a description of what I actually run, what it's built on, and where it breaks.

The problem: the truth never lives in the PM tool

Every project-management tool I've used has the same failure mode. The truth of the work lives in files, inboxes, and commits. The PM tool holds a second copy of that truth, maintained by hand. Second copies go stale. Once the tool is stale, people stop trusting it, so they ask each other for status directly — in meetings, in DMs, in weekly emails — and now you're paying for the tool and doing the manual reporting it was supposed to eliminate.

The tax shows up three ways:

Daily huddles and status meetings. People reading aloud what's already written down somewhere else, because no shared surface is trusted to be current. When the huddle is daily and everyone in the room is billable, the cost compounds fast.
Keeping the plan current. A project plan or task board is only as current as its last manual update, so someone is always paying the upkeep — re-entering work that already happened somewhere else just to keep the tool believable. That maintenance competes with the real work, every day.
Project updates. The weekly stakeholder email, the monthly summary, the things-for-the-partner list — each assembled by hand from meeting notes, AI summaries, and task lists that already say the same thing. The information exists; the format is the work.

For me the tax was multiplied by structure: two companies, a software product mid-build, and personal operations — three reporting rhythms, one person, and no one to delegate the reporting to. The tax isn't only the hours. It's that the hours land on exactly the days you most need to be building.

For years I assumed the fix was finding the right tool. It wasn't. The fix was refusing to maintain a second copy of the truth at all.

The architecture: files are the system of record

The whole system is a folder — in my case a private git repository — with four load-bearing parts:

ops/
  AGENTS.md        conventions every AI agent obeys (board etiquette,
                   tagging, append-only rules, pull-before-edit)
  TASKS.md         the board: workstreams, owners, due: / BLOCKED: tags
  decisions.md     append-only decision log — never edited, only appended
  status/          dated stakeholder updates, generated from done history
  _inbox/          raw capture (meeting notes, emails) triaged by any agent
  dashboard.html   rendered view — a derived artifact, never edited by hand

Three rules make it work:

The task board is text. TASKS.md is a markdown file with a line per task, area tags, due: dates, and BLOCKED: markers. Humans can edit it in any editor. AI agents can edit it with the same tools they use for everything else. There's no API, no sync, no schema migration — and no gap between "where the work happens" and "where the work is tracked," because a completed task is one line-edit away from the file you were already in.

Decisions are append-only. decisions.md is a dated log. You never edit history; you append a new entry that supersedes an old one. This is the single highest-value habit in the system. Six months in, "why did we do it that way?" is a search, not an argument.

Everything rendered is disposable. The dashboard, the briefs, the status drafts — all generated from the source files, all safe to delete and regenerate. If a rendered view is wrong, you fix the source, not the view.

Multi-party: hub and spoke

Solo, this is just a folder with good habits. The interesting version is multi-party — a project where each participant brings their own AI, and all of them obey the same conventions file. That's a hub-and-spoke shape with git as the sync fabric:

The shared repo carries shared truth only. Each party keeps a private layer locally — their own context, drafts, and confidential material — and controls sensitivity by deciding what crosses into the shared tree. The agents handle the git mechanics (pull before edit, small frequent commits, push), which matters because it means the sync fabric can be invisible to people who wouldn't touch git themselves. None of this is hypothetical at my desk: Claude Code does the daily work, and Gemini, Codex, and Perplexity have each been dropped into the same folder to evaluate or extend pieces of the system — same conventions file, no special setup, and each one knows the current status the moment it opens the folder.

A scheduled render job — a GitHub Action, or just a local script on a timer — regenerates the dashboard and drafts the status updates from whatever is on main. Nobody "does" reporting. Reporting is a build artifact.

One system, your whole life

Because every rendered view is a filtered view, the same fabric carries more than work. Almost everyone runs their life on a second set of systems — kids' activities in one app, home projects on a list, property management in a spreadsheet — all carried as mental load alongside the job. Here those are just workstreams: they live on your own board, render to your personal dashboard, and are simply excluded from every shared one.

I've taught Stephen Covey's 7 Habits for Managers course, and the argument his First Things First makes is that priorities fail when your roles — professional, parent, partner — live on separate lists. One board that holds all of it, with each audience seeing only what belongs to them, retires the separate lists and the mental load of carrying them. That filter is what makes the system livable — and it's a big part of why it sticks.

What actually runs, day to day

The system earns its keep through three scheduled routines. None of them is exotic; all of them are just an AI agent with file access, a prompt, and a schedule — which also means every routine is customizable. Change the prompt and the routine changes with you.

The morning brief — with a quiet-push policy. Every morning an agent scans the board and the inbox, refreshes the dashboard, and drafts a brief. The design decision that makes it livable is the quiet-push policy: the brief only notifies me about items that are overdue, due today, or newly blocked. Everything else stays on the dashboard for when I choose to look. A daily digest that reports everything is a fourth inbox; a daily digest that reports three genuinely urgent things is an assistant.

The Friday review. Once a week a longer-running agent does hygiene: verifies the backup actually ran, checks git state across repos, flags tasks that haven't moved in weeks, and asks one standing question — "what did you build this week that should be captured as a reusable asset?" Weekly is the right frequency for maintenance you'd otherwise skip; daily would be noise, monthly would let rot compound.

Status updates generated from done history. This is the piece that kills the retyping tax directly. Because every completed task is a dated line in the board's done history, and every decision is a dated log entry, a period's status update is a query: done items this period, open items, risks, blocked items — drafted by an agent into status/ as a dated file. I edit the draft rather than composing from memory. The draft is never sent unreviewed — by design, a human owns the send.

The change isn't that writing an update got faster. It's that the update stopped being a separate act of assembly — the thing I do at month end is edit, not compile and compose.

That's the whole daily surface: a brief that only interrupts when something needs me, a weekly hygiene pass, and updates that arrive already drafted.

The foundation: ICM

I didn't invent the underlying idea. The structure extends the Interpretable Context Methodology (ICM) — Van Clief & McDermott, arXiv:2603.16021, released under the MIT license — which makes the case that AI-assisted work should live in plain, human-readable context files that both people and models read and write, rather than in opaque application state.

Software developers will recognize the shape. Tracking work in plain files beside the code is an old, proven habit on engineering teams — and today's AI coding agents are built around exactly this convention. The markdown context files that guide Claude Code and its peers are the native way those tools understand a project's state. This system doesn't ask AI to do anything unusual; it applies the pattern the assistants were built on to running an operation.

What I've added on top of ICM's foundation is operational: the board and tag conventions, the append-only decision log, the quiet-push briefing policy, the generated-status pattern, and the multi-party hub-and-spoke layer where each participant brings their own AI under a shared conventions file. Where my templates reuse ICM template code, the MIT attribution travels with them.

The reason to care about the lineage, beyond credit: it means the core of this approach is an open, documented methodology — not a proprietary black box you'd be locked into. The files are markdown. If every agent and script disappeared tomorrow, the folder would still be a complete, readable record of the work.

Why this matters more if you run more than one entity

Running this solo across two companies is where the design constraint came from, and it points at who benefits most: multi-entity operators — PE operating teams, holdcos, family offices, franchise operators, fractional executives — anyone responsible for work spread across organizations that do not share a software tenant.

Two properties do the heavy lifting:

One fabric across tenant boundaries. Platform AI is getting genuinely good at "know my work and draft my update" — inside a single tenant. But a fund plus N portfolio companies is N+1 tenants on mixed stacks, and no platform's context layer crosses that edge. A neutral file-and-repo fabric does, because it doesn't belong to any of the platforms. One repo per portfolio company, a rollup that aggregates rendered outputs (never raw files, which keeps each company's boundary intact), and the same conventions everywhere — with each company's team using whatever AI their stack provides. The monthly ops report stops being a thing you chase CFOs for and becomes a thing that renders from each company's own done history.

Records that are structured for auditability from day one. This is the CPA in me talking. An append-only decision log with dates, a done history where every completed item carries its completion date, and a git history underneath it all — that is disciplined record-keeping by construction, the kind of trail that makes later diligence less painful. Every PM tool claims to track history; almost none produces a record you'd want to hand over, because the record was never designed as one. Here the record is the system.

For a PE operating partner specifically: you already pay for portfolio monitoring software. This pattern rides on files your teams already have and AI they already use — and its exhaust is a dated, append-only operating record per company from the day you install it.

What this doesn't solve (honest limitations)

I want this section to be longer than a marketing person would allow, because the failure modes are real.

Merge conflicts are a convention problem, not a solved problem. Two agents editing one hot file will eventually collide. The mitigations work — file-per-workstream, append-only patterns for logs, agents that always pull before editing, decisions going through pull requests — but they are conventions, and conventions require adoption. A team that won't follow the etiquette file will corrupt the board, same as they'd corrupt a shared spreadsheet. Git makes the damage recoverable; it doesn't make it not happen.

Non-technical users need the git layer fully hidden. I'm comfortable in a terminal. Most executives are not, and no amount of enthusiasm changes that. The pattern survives this — agents can do all the git mechanics, and a synced folder (SharePoint-style) can stand in for git at the cost of losing the review-and-history discipline — but be honest about the trade: the further you get from git, the weaker the record. The answer for that user is rendered views only — a partner-level user should never see a merge conflict in their life.

Text-first means binaries live elsewhere. The repo works because it's almost all text. Workbooks and decks live in linked storage; the system reads data in and renders artifacts out. If your work product is mostly large binary files, the git tier gives you much less.

Platforms will commoditize the easy half. Tenant-scoped context layers and task agents are shipping now across the major platforms. On a one-to-two year horizon, "AI reads your work and drafts your status update" inside a single organization will be a checkbox, not a product. I'm building on the assumption that the durable pieces are the ones platforms don't ship: cross-tenant fabric, bring-your-own-AI neutrality, the record-keeping discipline, and the installed habits. If you only need single-tenant status drafting, honestly — wait a year and your platform will hand it to you.

A system of record still requires telling it the truth. If work happens and never lands on the board, the generated status is confidently incomplete. The capture conventions (the _inbox/, the say-it-in-a-sentence routing) lower the cost of logging to nearly zero, but nearly zero is not zero. The discipline is small. It is not optional.

Where this is going

The system described here runs my own operation — two companies, product development, and everything it takes to operate them, all on one fabric. It has been in daily use long enough that I trust it, and is new enough that I'm still changing it most weeks. I'd rather write it up honestly at that stage than wait until I have a tidier story.

What I'm working on now is whether the pattern generalizes — whether conventions that hold for one operator still hold across a handful of very different ones. That's a question about other people's operations, not mine, and it isn't one I can answer from my own desk. If you run something with more than one entity, or more than one reporting audience, I'm interested in comparing notes. Further write-ups land at msoflow.io/ops-automation.

And if you'd rather just try it: paste this write-up into the AI you already use and ask it to design a starter version for your own operation — the folder, the conventions file, the first scheduled routine. It's a method, not a product — an afternoon is enough to find out whether it fits how you work.

The files + your AI are the project-management system. The task board, the brief, and the stakeholder updates are just rendered views of it.

Methodology: extends the MIT-licensed Interpretable Context Methodology (Van Clief & McDermott, arXiv:2603.16021). Attribution is retained wherever ICM template code is reused.