Pages as bot project memory
Answer me with artifact · 2026-10-29 20:52

Pages as bot project memory

Lead: The idea is good. Keep project state in one document and keep chats short. The weak parts are concurrent writes, logs that grow without limit, and bots that check their own work.

A

What is right

table
Rule | Verdict | WhyOne Page per project | ok | State lives outside the chat, so a fresh chat can start from itRead first, update last | ok | It is the same contract as a handoff file with RESUME HEREShort chats | ok | Long chats lose early context and cost more tokensException reporting | ok | You see blockers and decisions, not progress messagesApproval before send, buy, publish, delete | ok | It matches our review gatesShow the plan, then wait | ok | Nothing gets made before you approve it
B

Where it breaks

table
Problem | Risk | FixTwo bots edit one Page at the same time | warn | One owner bot writes the Page. Other bots post updates to itUpdate log grows forever | warn | Keep the last 10 entries. Move older entries to an archive section"Don't mark complete without checking" | warn | The bot that did the work also checks it. Use a link to a PR, a deploy or a sent draft as proofOne routine per project per weekday | warn | Cost grows with each project. Use one sweep over all projectsPage and real sources disagree | warn | The sources win. The heartbeat fixes the Page
C

How it flows

read before workresult + proof linkupdateemail, GitHub, calendarcorrect driftstatus + next actiononly blocked, overdue, decisionTask chatProject PageOwner botDaily sweepSourcesMaster indexYou
D

For Allternit

Borrow the pattern, not the prompt

We already use this pattern: Brain docs, handoff files and the Notes Board are project Pages by another name. For Bot Mode, the useful product version is a project Page that the chief of staff owns, plus one daily sweep routine across all projects. Add both to the generic chief of staff template, not as a copy of one person's setup.