--- title: Anti-patterns: Seventeen Ways the System Dies description: The failure modes prior builders and the research literature agree on, plus two learned since — written down so they can be recognised in flight, each with the tell that reveals it and the fix. track: core url: https://www.chiefofstaff.io/guides/anti-patterns published: 2026-09-01 updated: 2026-09-05 author: chiefofstaff.io editorial system outcome: keep an anti-patterns file, recognise when a proposed change drifts toward one, and stop to re-read it before proceeding. prerequisites: what-a-chief-of-staff-system-is source: chiefofstaff.io --- # Anti-patterns: Seventeen Ways the System Dies The failure modes prior builders and the research literature agree on, plus two learned since — written down so they can be recognised in flight, each with the tell that reveals it and the fix. The reference system keeps this list in `Atlas/anti-patterns.md`, in the read-every-session list. If a future change starts to drift toward one of these, the instruction is: stop and re-read the file. Each entry has a **tell** (how you notice) and a **fix**. ## 1. The PKM Trap Spending more time organising the system than using it. If weekly maintenance of the vault exceeds thirty minutes, the system is too complex. **Tell:** a new "structure" idea every week; endless folder reorganising. **Fix:** optimise for retrieval, not storage. The brief is the product, not the file system. ## 2. Tool Hopping Every new app or skill feels productive for two or three weeks, then decays. The system that works is the one that gets maintained. **Tell:** "let's switch to X" without a stated reason. **Fix:** format matters less than consistency. New tools require a decision record with a reverse condition. ## 3. The Daily Brief Becomes a Newspaper If you skim the brief, you have been trained to skim it. Every item must demand a response. **Tell:** "FYI" sections growing inside the daily brief; items repeated day after day with no action. **Fix:** FYIs go to the weekly digest. Daily items either resolve or escalate within three days. ## 4. Status Meetings Masquerading as Strategy Synchronous time spent reciting status that could have been written. **Tell:** calls that produce no decisions. **Fix:** status goes on the brief, async. Synchronous time is for issues and decisions only. ## 5. Flexibility Theatre Building a generic "agent platform" instead of three high-value workflows. Every commercial chief-of-staff product has died this way. **Tell:** "let's make it configurable" without a concrete second use case. **Fix:** pick two or three workflows, build them deeply, resist generality. ## 6. Family Time as the Residual The single most common failure mode for multi-venture operators. Family commitments not scheduled in the same calendar as work get compressed to nothing within six months. **Tell:** "I'll be home for dinner" stated, not calendared; a child's event skipped because "work came up." **Fix:** family blocks live in the same calendar, surfaced in the same brief, with the same priority weight as investor calls. See [Family is a venture](/guides/family-is-a-venture). ## 7. Building Infrastructure before Establishing Habits Spending week one on the perfect sub-agent architecture instead of running a manual brief by hand. **Tell:** no brief has been delivered yet, but five commands exist. **Fix:** run the brief manually for the first two weeks. Automate only after the format is stable. ## 8. No Decision Log Without a written record of why, every revisit costs cognitive energy reconstructing context. **Tell:** "why did we decide that?" with no answer in the vault. **Fix:** a significant decision means a record, written before the decision is acted on. ## 9. Sub-agents Writing Things A sub-agent can read and summarise. The moment one writes a task, sends a message, or edits a venture file, blame and traceability collapse. **Tell:** a sub-agent prompt that says "and create the tasks." **Fix:** the sub-agent returns a structured list; the parent reviews and acts. ## 10. The Chief of Staff Doing Operational Work If it starts doing the work of an engineer or an assistant *inside* a venture, it has stopped being a chief of staff. **Tell:** it is writing production code for one of your companies. **Fix:** that work belongs in the venture's own repository with its own session. The chief of staff coordinates; it does not execute inside ventures. (Bounded deliverables — a report, a research answer — are different; see [The execution lane](/guides/the-execution-lane).) ## 11. Editing the Vault without Provenance, Commit, or Log The bargain for full edit authority is full traceability. **Tell:** a diff you cannot trace to a source; a vault edit with no commit; a curation log with gaps. **Fix:** re-run the edit through the proper flow. If the source cannot be cited, the edit was too speculative — ask first. ## 12. Folders as Mutable Properties Putting status in a folder name (`ventures/active/`, `ventures/dormant/`) means changing status requires moving the folder, breaking links and history. **Tell:** a folder name describing a state that can change. **Fix:** status lives in frontmatter only. The folder is a permanent logical home. ## 13. The Daily Note as Graveyard Using the daily note as the only capture surface. **Tell:** voice notes and forwards landing in `Calendar/daily/` instead of `Efforts/inbox/`. **Fix:** the inbox is unprocessed capture; the daily note is structured reflection. Two functions, never blurred. ## 14. Context Bloat Inventing new cognitive-mode labels beyond the four. **Tell:** a task labelled `@strategy` or `@morning`. **Fix:** use one of the four. If you genuinely need a fifth, write a decision record amending the cap first — never add silently. ## 15. Project-List Explosion A venture with twenty active projects cannot be reviewed weekly. **Tell:** more than seven active project notes under one venture. **Fix:** move the excess to `someday.md` or close them. The weekly review refuses an eighth until one moves. --- Two more, learned after the original fifteen and worth adding to yours. ## 16. "Routed" Is Not "Done" A request that has been acknowledged, filed as a task, and receipted — and then never executed — reads to the person who sent it as being ignored. **Tell:** a task with a receipt, an owner and no movement for a week. **Fix:** structural — an execution lane for the work whose doer is the system itself. ## 17. The Commitment That Exists Only in a Session The assistant is told something that applies later, replies *"noted for later"*, and notes it nowhere. The session ends and the intention goes with it. This is the sharpest failure available to a system whose whole thesis is that files are memory, and it is invisible: nothing is wrong in the vault, because nothing is in the vault. It hides in instructions that are deferred (*"later"*), conditional (*"once we've…"*), or phrased as a behaviour rather than a deliverable — none of which name a file, so none of which get written to one. A setup prompt is full of them. **Tell:** the words "noted", "I'll remember", or "I'll raise it then" in a reply with no commit behind them. Or, later: an instruction you clearly gave that nothing in the vault mentions. **Fix:** nothing is deferred without an artifact. Every deferral becomes a task with a trigger condition, a line in a named ritual, or an ADR — the same three places a decision goes. If a deferral cannot be attached to one of those, it has not been deferred, it has been dropped, and the assistant says so at the time rather than agreeing pleasantly. The general rule underneath both: **the reply is not a durable surface.** Anything that must outlive the session is written before the reply that promises it.