A living shared plan is not an acceptance record

Research brief and result, October 15, 2026. Can a shared artifact coordinate agent work across changing intent, code and people without locking in an untested approach? A full answer would connect a request, versioned plan and reversals, agent work and handoffs, named human release decision, independent real-user checks, upkeep cost and later repair. Our planning hub preserves Dru’s distinction between disposable discovery prototypes and production commitment. ParallelPilot measures coordination of short tickets but not approved production; Anghami records plan reversals and a later production scoring defect. Answer so far: a plan can be a useful live integration interface rather than a queue of summaries. A correct current plan, however, is not a behavior oracle or an authorization to deploy.

Four subquestions and primary reading. (1) What was shared? Giles Edwards-Alexander’s “An Accidental Blackboard” (originally published August 29, hosted on Fowler September 2) describes ten Thoughtworks engineers on a specified, simulated airline disruption exercise: agents edited a monorepo and plan documents with stable spec/line identifiers, progress markers and integration notes. (2) What failed? Their frequent commit/rebase/push cycle made the plans visible across agents but overloaded CI; after pushing only larger chunks, the live coordination signal disappeared. It was ad hoc, not reliably reproducible; the author proposes a separate coordination channel, not a measured fix. (3) How do human steering and evolving decisions compare? The original ParallelPilot experiment reports short-task throughput with no detected improvement in self-rated control or redirection. Edwards-Alexander’s August 30 Talwrn follow-up records human interviews, chosen constraints, stale documentation caught by rereading and a deliberate current-decision index; details in its note. (4) Where is the release gate? Anthropic’s October 13 Scion/Antique operator account reports human intent reviews on all its system’s change requests and post-merge/pre-deploy checks; its merge is not deployment or independent requester acceptance. FastyBird has a real-device owner check and explicit retiring of unperformed tests, a different and narrower sort of closure. Searches for a Talwrn second-team release and a public airline repo/acceptance trace found no reliable one; no more generic searches presently warranted.

What happened in the workshop. An evaluator agent built a validity checker for proposed airline-recovery plans while a search agent built a generator that depended on it. The agents’ plans identified the common interface and recorded who would call the real checker once ready. When one agent marked a plan line in progress, another avoided that work; when it marked it complete, the other could read both the change and notes and integrate. An agent integrating a cost model was explicitly asked to watch the repository and proceed when the upstream work landed. These are observed owner-reported episodes, not a comparison of errors or elapsed work with versus without a blackboard. The author calls his system a four-day build, but it used a simulated airline and provided specification, not a live operator deciding whom to reroute.

Disagreement/limits. The workshop suggests one shared plan plus small integration steps can coordinate across agent sessions; the later first-person follow-up admits source-control updates saturated CI and adds interviews with the human, stable current decisions, plan-first publishing and proposed deterministic tests. Even then, documentation and oracle fidelity need separate human judgment: in the follow-up the owner spotted a stale invariant reference, and six documentation failures were reported caught only by reading. The distinction is not “shared board versus tickets”; the board tracked dependencies and current decisions, whereas an acceptance ledger names which proposed behavior actually passed, failed or was consciously retired. No real customer, product or support representative tested this airline software, and neither operator example measures cost of maintaining the plan or alternate orchestration. ParallelPilot’s controlled ticket result does not prove blackboard use works at release scale. Anthropic’s highly bespoke post-merge checks do not independently validate the workshop.

Next test. On a real feature with a late user-request change, require an agent to surface the outdated plan and integrate the corrected interface; record who made/approved the change and cost of keeping the board current. Then test in a real client and have the requester decide release scope. Compare time to find stale intent, duplicate work, CI load, review minutes and 30-day repairs against usual issue/PR notes. An active plan is a hypothesis of how work should fit; an observed, named acceptance decision is its separate gate. Potential weekday source: the concise original blackboard story if the feed has capacity; weekend follow-up: the longer Talwrn foundation account after interest or a verified deployment.