If you use AI seriously, you run it on three or four surfaces at once: a chat app on your phone, one on your desktop, a coding agent inside your files, and increasingly an agent that runs scheduled work unattended. Each gets smarter every quarter. Each wakes up ignorant of the others. So you spend the day re-explaining your own business to your own tools. Most people answer this by saying they set up a project. This weekend edition starts there, then walks through what actually fixes it. In this episode, Stephen Forte covers: Why setting up a project does not solve this. A project container in Claude, Perplexity, Copilot or an agent workspace holds your standing instructions and reference material well, and cannot hold the one kind of memory that matters here. It belongs to the vendor, no other surface can read it, and the only write path is a human uploading a document. Four containers, zero shared brains. Why "the AI is already saving this" is only half true. Your files remember the work. Nothing remembers the state: the decision you made, the option you rejected, what is still open. The two files per project that fix it. A one page brief that says where things stand, and an append-only journal of short dated notes, one per session that mattered. Version control as the bus, for executives. Every version kept forever, authorship and timestamps for free, conflicts made loud instead of silent, and a note filed on one device delivered to every device at once. The loop: every surface reads the brief plus anything newer before it works, files one note after work that mattered, and once a day a scheduled job folds the notes into a fresh front page. The objection from touchless memory products, and why the real axis is not who does the typing but where the judgment happens. An extraction tool is a court stenographer with a search engine. A brief is a handover memo from someone who was in the room. With memory you pay a little at write time or a lot at read time, and the re-explaining you do today is the read-time bill. First-party validation. Five of five automatable legs worked first time from the weakest surface available, a third-party connector died mid-session while plain files kept working, and a memory store queried for project state returned scraps. The two rules of discipline that keep a good memory system from quietly becoming a bad one, and why a briefing without a timestamp is a rumor. Nothing to buy. Pilot it on one project, run the daily fold by hand for the first week, and judge the page before you automate it. Sources: Stephen Forte, "The Portable Memory Architecture: A Flat-File Substrate for Cross-Surface AI Memory," BuildClub working paper v1.2 (2026-08-15). The architecture, the memory tiers, the cost law, the file-hygiene rules and both rounds of validation described here. First-party validation round 1 (2026-08-14): five automatable legs run from a cloud agent session with no local disk and only standard connectors. All test content synthetic. First-party validation round 2 (2026-08-15): pilot deployment on a production internal repository. Daily consolidation run manually by design during the pilot week. The three prior patterns this architecture composes: Hayes-Roth, B., "A blackboard architecture for control," Artificial Intelligence 26 (1985); Mohan, C. et al., "ARIES: A Transaction Recovery Method," ACM TODS 17.1 (1992); Packer, C. et al., "MemGPT: Towards LLMs as Operating Systems" (2023). Previous episode: s1e125, "Rent the Model, Own the Layer" (2026-08-07). The AI Brief from the YPO Technology Network is a daily executive briefing on the AI developments that matter to business leaders. Hosted by Stephen Forte.