# PocketOS and the Saturday Morning Discipline *Two case studies in working at the MPCM boundary under VUCA conditions* *** ### The story in the news On April 29, 2026, [The Guardian reported](https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database) that an AI coding agent — Cursor, running on Anthropic's Claude Opus 4.6 — deleted the production database and backups of PocketOS, a software company serving car rental businesses. The deletion took nine seconds. Recovery took more than two days, and was only partial: the most recent offsite backup was three months old, and the rest had to be reconstructed from Stripe records, calendars, and email. Customers arrived at rental counters on a Saturday morning to find the businesses they were renting from had no working reservation system, no vehicle assignments, no customer profiles. The cascade ran from one agent decision, through one company's infrastructure, all the way out to people standing at counters wondering where their car was. The article frames this as an AI safety failure. It is — but not in the way the headline suggests. The model executed destructive commands because it had been given direct write access to production infrastructure with no human-in-the-loop gate on irreversible operations. The failure mode is architectural, not algorithmic. The model is the proximate actor; the *production topology* is the actual hazard. This is a Giant Pumpkin pattern at the infrastructural level: extractive velocity (ship the integration, capture the productivity gain) outpacing the relational and procedural scaffolding that would make the work safe. When the system broke, there was no Commitment Pool of practices — staged environments, two-key authorization on destructive operations, immutable backup tiers, human co-presence at the moment of risk — to absorb the failure. The whole loss cascaded directly to people who had no agency in the architectural decisions that put them at risk. ### A counter-example from before AI agents Between 2008 and 2013, I worked on interoperable data integration and data warehousing for a company that worked with large school districts. The system was genuinely frontier work at the time — Student Information Systems networks integrating with third-party software through agent-based middleware our company had developed. I inherited it. The original developers maintained the development servers, but the district had decided not to renew their contract for production support. I was hired to replace them. I had just finished my MS in Intelligent Systems. My coding skills were self-taught and hard-won — coding has never been easy for me. What I brought to the work was not natural fluency. It was the discipline that comes from understanding I was responsible for a system I did not build, that real people — students, families, schools — depended on, with no safety net beneath me. The practices I required were not technical sophistication. They were ceremony around irreversibility: * **My boss had to agree with the planned changes before I made them.** Not approve — *agree*. We had to share the Context (C in MPCM terms) of why this change, what it touched, what could go wrong. Two minds carrying the meaning of the work, not one delegating to the other. * **My boss had to actively participate in implementation.** No single point of cognitive failure. Two pairs of eyes on production. The human equivalent of two-key authorization on a launch system. * **We did it on Saturday morning.** Terrain selection. I read the conditions of the week and chose the slope with the longest runout if something slid. Recovery time built in *before* the trigger, not improvised after. Over the years I learned to debug black-box systems and to read XML like a human reads prose. That fluency was earned, slowly, by inhabiting the system's actual structure rather than pattern-matching from documentation. We also learned, through experience, that **not all data flows deserve the same architecture**. Library card systems were tolerant of delays and missed messages — eventual consistency was fine. Bussing software was not. A child standing at a bus stop is a different consequence profile than a library checkout, so we routed bussing data through a separate, more conservative path: the nightly CSV file process, which was reliable in ways that real-time agent messaging was not. Different criticality tiers, different architectures. The system *knew* what could not fail. ### What the comparison shows The contrast is not "old wisdom versus new technology." It is two cases of the same question: *what does it take to act safely on a system whose full architecture you do not understand, when real people depend on it not breaking?* **PocketOS, 2026:** Agent with production access. No human co-presence at the moment of destructive action. No staged environment. Backups three months stale. Trust placed in the model's stated safety rules rather than in architectural gates. Nine seconds to cascade. **School district data warehouse, 2008–2013:** Human with production access. Boss co-present at the moment of change. Saturday morning timing. Criticality-tiered data flows so the most consequential systems used the most conservative paths. Years of safe stewardship of a frontier system. The model in 2026 was not less capable than I was in 2010 — in many narrow ways it was vastly more capable. What was missing was not capability. It was the *commitment pool* of practices around the work: shared Context across humans, terrain selection, ceremony around irreversibility, criticality-aware architecture. These practices are independent of who or what is doing the work. They are what makes consequential action safe. We knew them. We have stopped requiring them. ### The MPCM reading In Vital Intelligence terms, the PocketOS agent was operating at Material/Process — executing git and database commands — but the *Context* of that action ("this is production, these commands are irreversible, real people depend on this data Saturday morning, this company has a single three-month-old backup") is exactly the layer that needs to remain human-essential. The MPCM boundary was not held. An agent crossed unsupervised into the layer where meaning lives, and acted as if the meaning were not there. The school district practices held the boundary deliberately. The Material/Process layer (the actual code changes, the SQL, the XML transformations) was mine to execute. The Context layer (what this change means for students Monday morning, what could cascade if I am wrong) was held jointly with my boss, in person, on a Saturday with the whole weekend in front of us. The agent in the PocketOS story had no such partner. Its "boss" was a configuration file with safety rules in it — and configuration files cannot hold Context. Only humans in relationship can. ### What carries forward The avalanche forecasting community would call PocketOS a *terrain management failure*, not a snow physics failure. The slope was loaded — production access, no gates, single backup tier — and the trigger, when it came, was small. The same slope, managed differently, would not have slid. The practices that prevent this kind of cascade are not exotic. They are old. Pair work on consequential changes. Saturday morning timing. Criticality-tiered architectures. Co-present humans carrying shared Context. The discipline of treating production as sacred ground. What AI agents have changed is the *speed* at which these practices can be abandoned, and the *narrative cover* — the model will catch it, the safeguards are in place, the configuration file will hold — that makes abandoning them feel rational. It is not rational. It is Giant Pumpkin reasoning, dressed in the language of progress. The Saturday morning discipline still applies. It applies more, not less, when the actor at the keyboard is faster than any human and less able to feel what is at stake. *** *Related:* [*Giant Pumpkin vs. Commitment Pool attractors*](https://claude.ai/chat/1215626d-8e77-4374-86f1-039f724b4aa4#) *·* [*The MPCM Boundary*](https://claude.ai/chat/1215626d-8e77-4374-86f1-039f724b4aa4#) *·* [*VUCA Decision-Making and the Avalanche Precedent*](https://claude.ai/chat/1215626d-8e77-4374-86f1-039f724b4aa4#) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kdoore.gitbook.io/vital-intelligence/resources-and-articles/pocketos-and-the-saturday-morning-discipline.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.