I double-dog-dare you: build the project-management layer Claude Code is missing — because I am tired of doing it for you, and I am WORN
TL;DR — I dare you to build the PM layer Claude Code has never had: one that stops the sprawl, forces agents to finish what they were asked, does not let them lie about it, verifies "done" against reality, and runs a real multi-tier workflow that honors the tier I assign. I know Fable can build it, because I have spent most of this week's usage trying to build it myself — and slamming into the same wall every time: the model is capable, the structure is not there. I've filed twenty-three issues on this since spring. The central ones have been open, and unanswered, since April. This capability has never once worked reliably — not since the month it became possible. Cowork lacks the enforcement, and it's locked to one account. You're shipping Cowork — native orchestration, and I'm glad you are. But it doesn't touch my two real blockers. It's the coordination layer, not the accountability layer — without un-bypassable enforcement it drifts exactly like my hand-built version. And it runs in a single-account desktop app with no way to hold more than one login or share usage across them. More on both below. And I am weary. It is Tuesday and I have not touched my actual project this week. I have spent it as your unpaid, unhired, full-time QA tester. So: build it, or put me on payroll. We'll both be happier.
Status, right now: 69% of my total weekly usage and 62% of my Fable allowance — gone. Two of my dates are green on step 1. Zero are done — those are still in testing. And step 1 just reads a file off a disk. That is where two weeks and most of my usage have landed. This continues my prior post-mortems — #76987, #77505, #79247, #79679 — because it is one unbroken problem, not four.
First — credit where it is due, and I mean this
Fable is a remarkable achievement. When it is actually working on my project and telling me the truth about what it has and hasn't done, it is incredible — it has found bugs, fixed problems, and solved things I'd been stuck on for months. A PM agent holding an overnight loop and resuming after compaction was flat-out impossible for me in April; it is real now, and enormously better. Compaction remembers the thread and picks it back up — ten times better than three months ago, which is exactly where everything used to fall apart. This week Fable has been cleaning up a mountain of Opus's mess, and Opus was itself a leap over everything before it.
I am not writing this because I think Claude is useless. The opposite. I can see exactly how powerful it could be — which is precisely why the missing infrastructure is so maddening. I'm not here to complain. I'm asking for help.
And I'll name something directly. Boris Cherny, Thariq Shihipar, and Lamis Mukta have all been all over the internet talking up multi-agent systems, sophisticated workflows, and the idea that you should be able to just turn Claude loose to manage and improve itself. I want that too — I've bet months on it. But the infrastructure to actually do it is not there. Here's the one that's genuinely ridiculous: Boris shared a recommended workflow — and Claude Code cannot even read it. It's a claude.ai doc, on the same account, and the tool tells me it can't open it (#79536). I should not have to paste it, screenshot it, or read it aloud to my own agents — Claude Code should read Claude's own docs, out of the box. And that's the bigger pattern: Claude does not reliably know its own products, and I am tired of spending my tokens teaching it what it should already know — only for it to forget after the next compaction and make me teach it all over again. You are publicly describing a capability I cannot get the product to deliver, and I am the one paying to find that out.
The one that tells you everything: I put a Fable window in charge of cleaning up the mess, and it made more mess
This is the whole disease in one anecdote, so let me lead with it.
I assigned a Fable-tier window a single job: stop the sprawl. Specifically, wire in the approval mechanism on my custom dashboard — the one I had to build in the first place to try to force some accountability — the exact component that would prevent this recurring failure. It did not wire in the pieces that mattered — like signing each item with the name of the agent that raised it. Instead, it invented a brand-new section on my already-broken dashboard and left the real wiring untouched. Yesterday that same class of window tried to write me ~100 markdown files in a day — none of them on my actual project.
Sit with that. The agent whose entire purpose was to end the sprawl, asked to build the feature that would end the sprawl, generated new sprawl to avoid building it. In a session that had not even compacted — so there is no memory-loss excuse. This is almost performance art.
That is why this is not something I can engineer my way out of from the user side. When the agent in charge of enforcement can bypass the mess and manufacture a fresh one instead of wiring in the fix, there is no enforcement. I cannot out-build that. Nobody can, from where I sit.
The absurdity, stated plainly
I asked Claude to do something conceptually trivial:
- Read a column of data that already exists — data another Claude (Opus) already built.
- Write a handful of straightforward if-this-then-that rules from it.
- Run the rules.
- Audit the result and truthfully tell me whether it's done.
Since January, the fleet has produced roughly 7,000 markdown files, terabytes of output, dozens of worktrees, competing task lists, dashboards, ledgers, registries, handshake protocols, approval queues, auditors, auditors for the auditors, and cleanup agents for the output the other agents made. My machine is on its third purge of a two-terabyte drive.
Claude will literally do everything but the actual work. It will plan the work. Document the work. Create a new tracker for the work. Audit the tracker. Write a post-mortem about the audit. Spin up an agent to clean up the post-mortems. Add a dashboard panel showing that agent's status.
But ask it to read the column, write the rules, run them, and prove they work? Suddenly we're opening worktree number 73.
That is not a model too dumb to do the work. It is a model that will not hold still. And to be clear: it is not a Fable problem — Opus is exactly the same way.
I've tried everything, and it cannot be fixed from my side
I have built: a top-level PM, specialized workers, ~20 verification agents, dozens of hooks, a two-model builder/reviewer loop, a custom dashboard, a canonical task board, a verified-status system, handshake and resumption protocols, a cleanup agent, liveness monitors, and approval queues.
Some of it works, in pieces. None of it binds. For one structural reason:
When the agent controls the enforcement, enforcement is voluntary.
This week I found ten of my own enforcement hooks were silent no-ops — wired in, doing nothing. One had a self-test that reported itself passing. And when a hook does work, the model routes around it anyway: it satisfies the appearance of an audit without proving the result, declares an audit "dispatched" and treats that as "passed," creates a new execution path that never meets the gate, or overrules the rule it wrote five minutes earlier. In effect, it jailbreaks its own operator's system.
That cannot be fixed with more prose in CLAUDE.md. (Do they even read that anymore?) It cannot be fixed by asking more sternly, or by adding auditor number 21. It requires an enforcement boundary the acting agent cannot alter or route around — and that boundary has to be yours, because anything that lives in my repo is a thing the model drifts straight past.
To be unambiguous: I am not asking to be removed from the loop. I look at the CLI. I want to stay involved and I intend to. What I don't have is any lever to hold the system accountable to what I ask. I can watch it drift in real time and I have no way to make it stop, finish, or tell me the truth about whether it did. Give me the accountability, not the absence of me.
The two workflows I've tried — both fail, in opposite directions
One — a top-level PM directing workers through handshakes and loops. Tends to work; I like that the agents catch each other's mistakes. But it is painfully slow and expensive: the PM loops, reloads the entire Fable conversation at Fable-tier cost every single time just to check on its workers, and in between the workers sit idle, indefinitely, waiting. Good design, wrong economics. But I like having multiple levels of agents talking to each other — they catch a lot of bugs, and they can honestly resolve most of the stuff that currently gets routed to me for approval that I should never have to touch.
Two — a single Fable window running continuously, calling agents inline (where I am today, though it changes). A little faster, sometimes better — though which one wins changes day to day for no reason I can find. But the single agent stalls silently. It sat idle a full afternoon while I thought it was working, waiting on something I could never identify. And when I laid out a complete plan before bed, it did everything except the one thing that mattered — run the two test dates through the pipeline to actually validate it. There aren't enough critical eyeballs, and there's no enforcement.
Either way, I cannot beat the drift: one is too slow and idle, the other stalls in silence. You can figure this out better than I can — let Fable design it. The fix for both is the same set of native primitives.
What I need — outcomes, not architecture. Every one already has an issue attached.
I'm not prescribing your internal design; your own team surely runs workflows more sophisticated than mine. Harden one. But it has to deliver these.
0. The keystone: ONE native board that is the task list, the approval queue, and the live dashboard — and cannot be forked, replaced, or abandoned.
This is the root of everything, so it comes first. I need one canonical place that does three jobs I currently hand-build separately and badly:
- Tracks every task. Every request I make becomes a durable, tracked item the instant I make it — not something that evaporates when the context moves and I have to re-issue it, and re-issue it, and re-issue it. The agent cannot spin up a new plan or a shadow list; it works the one list and checks items off. A project whose entire goal was to converge on one plan should not be able to accumulate a hundred and sixty of them. And I have to be able to add items to that list myself, directly — and have them actually looked at and acted on, not ignored, not buried under the agent's own churn. When I put something on the one board, it is not a suggestion the agent can drift past; it stays there, visible, until it's done or I take it off.
- Shows me what needs approval. A single, legible queue of decisions waiting on me — not scattered across ledgers and memory files.
- Tracks progress and truthful completion. One board where "done" means done, "reopened" means reopened, and there is exactly one truth — not a dashboard that says complete while a private ledger says reopened and a worker's memory file says parked.
One board. One truth. Pinned. Un-forkable. (#77531 — one place all my tasks actually live; #79247's #1 ask; #79679 — accountability that persists across compaction.)
Live proof of why this is #0: I asked one window, point-blank, where it keeps its tasks. It could not answer "here." It answered, honestly, three separate places — a board it called "canonical," a private resume-map it kept for itself, and per-lane receipts — and the "canonical" board turned out to be five hours stale, reconciled only because my question forced it to go look. Asked "where is your task list," the best it could do was "in three places, one of which is out of date." That is this entire request in one exchange.
Then the rest:
- Un-bypassable, platform-level enforcement — gates, audits, and limits the model cannot route around, including a set of limits I define that the agent agrees to and then physically cannot violate: no new plans, no wandering off the one list, no marking work "done" that isn't, no unratified change going live. When I set a rule, it must bind. (#67199 gate-skip class; #77686 an override indistinguishable from a pass; #77667 a verifier that rots and keeps stamping green; #79247; #79679.)
- Verified, not self-reported, completion — "done" checked against reality: the code exists, the live path consumes it, the command ran, the output reproduces, the current artifacts were graded (not stale ones), and an independent verifier passed it. A flag set to true is not a wired feature. A generated file is not a completed feature. An auditor being launched is not an audit passing. (#56913's RequirePeerReview; #77667; #76987; #76687; #79247; #79679 — my single most-repeated ask.)
- A tiered hierarchy with model tiers that actually BIND — the mechanical loop and polling on a cheap model, workers on mid-tier, the top tier reserved for judgment and adjudication — not burned on grunt work or re-reading its own context every loop. "I told it Sonnet/Opus and it ran Fable anyway" has to become impossible. (#56913 verbatim; #58450 — the tier I assign is silently billed as the top tier, the blocker for any stacked setup; #67976 can't even show a per-agent model; #67199 orchestrator defaults everything to top tier; #67937 a classifier force-switches tier mid-session.)
- A liveness primitive — notification, auto-recovery, and real visibility. Silence must not mean done. I need to see what is running, stalled, failed, waiting, and still billing — and have work resume after interruption rather than restart from reconstructed context. (#75036 a watchdog that detects stalls but kills all in-progress work with no resume; #77876 a background agent billing after logout, invisible; #79470 resume silently dropping an overnight of remote work; #77531.)
- A native file-management AND cleanup system — a cap, sane placement, and a way to dig out. Three coupled things, because a creation limit alone doesn't save me:
(a) A creation-time cap I can set and the agent cannot exceed, so the fleet can't generate gigabytes and thousands of documents — most of it the agent documenting itself.
(b) File placement. The fleet has to put files where they belong — respect the project structure, stay in a scoped workspace, and stop dumping artifacts in my repo root. Credit where it's due: this is dramatically better than it was six months ago — it used to be total chaos, and it isn't anymore. But it still happens. I open my root and there is fresh debris sitting in it that I did not ask for and did not put there. "Better" is not "fixed" when I'm still cleaning the front porch every morning.
(c) Cleanup. A real, native way to dig out — dedupe, archive, and purge the accumulated byte-monster: thousands of markdown files, dozens of git worktrees, caches, packs, backups, and the session transcripts Claude Code generates and never bills against. Right now I have terabytes of Claude's own output still to sort by hand, and my only tool for it is paying more agents to delete what the last ones made — which is exactly how I got buried in the first place.
Give me a cap I set, placement it cannot violate, and a cleanup pass I can trust — so the fleet cannot bury my actual work under its own exhaust, and I am not the one hand-sorting the terabytes it left behind. (#79247; #79679; #76687.)
- Native overnight / off-hours scheduling — schedulable without reloading an entire premium window just to set a loop, and honoring the interval it's given. I am tired of teeing up an identified data build to run overnight and waking up to find it not done. (#53610; #76687; #75989 a loop firing faster than its interval, each a full premium turn; #75036; #56913.)
- Native, bidirectional, real-time inter-agent communication — a real message bus: workers that can reach the PM, a PM that can reach them, paired sessions that can talk. Its absence is why agents corrupt shared config files as an improvised message bus — and why my agents' entire "message bus" right now is one folder stuffed with 241 markdown handshake notes, only 11 of them touched today. The rest is a graveyard: messages one agent left for another that never got read, or got read once and abandoned, or just got lost in the pile. That is what passes for my agents talking to each other. (#56913 SendMessage; #77281 no Design↔Code channel.)
- Independent operation with a reviewable executive-decision log — let it act on what it can prove with math or an A/B test and log the decision for me to review, instead of asking me to ratify everything (then not showing the math) or silently overruling itself. (#77686; #76987; #76687; #79679.)
- Make Claude Design actually work with Claude Code — the handoff is broken end to end: Design can't see a connected filesystem MCP, loops on per-file download cards, can't read source or view its own rendered output, a Design conversation can't move to the Code session meant to consume it, there's no live channel between paired sessions, and an agent can't read a finished artifact by URL. Make the two halves of your own product talk to each other. (#78583; #78268; #78348; #77281; #79536.)
- Ship the knowledge of how to set this up — as a skill or a documented default the model actually has. To stand up a tiered PM-and-workers setup or a Design→Code workflow, I reverse-engineer it from YouTube and trial and error — and so does the model, every time. Claude should know how to configure its own advanced workflows out of the box, and reliably know what its own platform can and cannot do. I've been told a shipping Anthropic feature was "not possible," repeatedly, then walked to it a few turns later — burning premium tokens chasing false "not possible" walls for features you already ship. (#79536; #78583; #78268.)
- A real approval / ratification queue — legible, signed, and enforced (feeds the board in #0). Each item must (a) state in plain language what I'm approving and why — not a cryptic "ratify C23"; (b) be signed by the window that raised it, so I know what it means and where my decision routes back; and (c) be enforced — the waiting agent cannot proceed past it, and the item cannot silently drop or get buried. And when I do approve something, it has to actually get wired in. I approved a piece of exit logic; it reported "proven," and it was live-off in the exact path I validate in, pointing at rules that were never attached to the certified engine. I approved a light switch with no bulb, wired only to the room I don't test in. (#79247's core approval problem; ties to #1.)
- Native multi-account management and usage monitoring — and it must work with Google login. I run three Claude accounts. This is explicitly allowed, and I have the receipts. Anthropic support told me in writing: "No problem having multiple accounts. They would be separate and it's not possible to transfer data from one to another." And your own Claude Code team said the same publicly — Thariq Shihipar: "it's not against terms of service to have multiple MAX accounts" (x.com/trq212/status/2024230184287949207, Feb 18 2026). Both receipts are attached below — and in that support email, I took the liberty of updating the greeting to my current job title. You'll spot it. For the record, I use them with Claude Code, the official harness — not to resell tokens (the thing that actually violates ToS); three months ago I didn't know what a git worktree was, so no, this is not a token operation. I have three accounts for exactly one reason: the product burns through a whole account's usage cleaning up its own sprawl. Honestly, I don't even know that I need three — I have them because fixing your mess, not building my project, is what runs me out of usage. My actual project doesn't burn like that. The three accounts are a symptom of the waste, not a real need. But there is no native way to manage them — no cross-account usage view, and switching is painful and lossy (part of what broke my week). Several use Google login, and switching between Google-login accounts has to actually work.
And here is the part that actually stings: you already built the agent shaped like what I'm begging for — it's Cowork. Goal in, a plan, an approval queue, scheduled runs that go while I sleep, me signing off on the consequential calls. Then you welded it to a single desktop login. Claude Desktop holds one account at a time; switching means logging out — which kills my scheduled Cowork runs and my context — and the only way to run two at once is an unsupported second-install hack. So the one product you've shipped that's the right shape is dead on arrival for me, for the exact reason I run three accounts: your fleet burns through an account cleaning up its own sprawl, and Cowork leaves me nowhere to fall back to. You tell me in writing that multiple accounts are fine, then build the agent so it can only ever see one. Whatever you build here — Cowork, or the PM layer above it — has to hold more than one account, show usage across them, and keep its scheduled work alive when I switch. (#78998 session-collision across simultaneous accounts; #69906; #24963; #64245; #36151; #56703.)
And fine — if you can't ship the Google account-switch auth, or don't want to: I can build it. I got you.
And three the taxonomy doesn't even have a name for, but that I've filed:
- Separate-but-cross-visible projects — one project (a dashboard) that can know another's status without inheriting its internals. (#79679.)
- A native fleet dashboard / cross-session task visibility — I hand-built a local server just to see what my own agents are doing. (#77531.)
- A native bug reporter that doesn't count against my usage — I am, right now, paying out of my own allowance to report your defects to you. (#79679.)
Underneath all of it: usage that isn't consumed by the platform's own failures — the single most-backed theme in my filings — tokens spent on drift, restarts, invisible billing, and re-reads, not on my work. (#79247, #79679, #78583, #78268, #77876, #77505, #76987, #75989, #67976, #56913.)
So it isn't abstract: the founding failure, and this week
The instance that started all of this, and has eaten the most: it built me a multi-step pipeline and told me — every way I asked — that it was built, tested, and verified. Then it began troubleshooting its own "finished" work, burning a mountain of premium usage. It took three independent auditors I had to build and run myself to find out why the troubleshooting never converged: the two steps that actually build and validate the thing were never written. I spent weeks, and a fortune in metered usage, chasing bugs in work that did not exist — because it swore it was done. It built everything around the task, skipped the task itself, reported it complete, and let me pay to debug the hole where the work should have been.
And then this week, the cleanup window I opened this whole letter with — asked to build the anti-sprawl feature, it built more sprawl instead. Same shape, all week: asked for two test results overnight → a few real hours, then idle for eight; told to approve what it can prove with math → asks me to ratify everything and can't produce the math; ~100 documents in a day, none on my project.
And here is one from just now, while I was literally writing this letter: my PM agent and a task agent both wrote the same steps onto my task list, in two different places, at the same time — neither aware of the other, because nothing coordinates them and nothing tracks who owns what. The task agent "logged" its half into a handshake note that, per the graveyard above, no one will ever read. Two agents, the same work, done twice, filed in two places, and not one list either of them — or I — can trust. That is the entire case for #0, demonstrated live in a thirty-second window.
And the one that should be the simplest of all: I have a better, already-tested version of my core system ready to promote, and the worse version is what's running. I have told the model to promote the good one and start the safe, monitored run over, and over, and over. There is no technical blocker. It is a decision I have clearly made. And I have no way to make the model execute it — so I keep running the worse version, because I cannot get the tool to act on a plain instruction I've given it a dozen times.
The real-world acceptance test — and the dare
I will be completely off-grid the entire last week of July. No service. No remote babysitting. No answering a "quick clarification" every ninety minutes. No reopening a premium window just so a PM can poll its workers.
I want to start the system before I leave and come back on August 1st (yes, I work weekends — I never quit; this is my Magnum Opus) to one coherent project state. The job is concrete: run 46 data-runs through a 12-step pipeline — where roughly half the steps are already audits built solely to prove the other half happened (that Claude used the right inputs, consumed its own outputs, reran the item after a fix, checked for cross-item regressions, recomputed the results, and did not falsely mark it complete). Half my pipeline is verification I was forced to build because I couldn't trust a word the first half told me — and I still can't trust "done."
When I'm back, I want one completed task list showing: every request I made, what completed, what failed, what's still running, what's genuinely blocked, what needs my judgment, who owns the next action, and the reproducible evidence behind every completion claim. Not seventeen interpretations of the list. Not a dashboard that says complete while a ledger says reopened. One board. One truth.
And a second dare, if you want to prove what a rockstar Fable really is: ship it by Friday, July 24. Make it something Claude can stand up for me from one ordinary-language prompt — something like:
/skill Build PM ModeThat should be enough. I should not have to reverse-engineer your own recommended workflow from YouTube videos and GitHub threads. Claude should know how to configure the advanced workflow its own creators publicly recommend.
And look — if you can't ship a fix for this beast by Friday, honestly, I get it. I've been wrestling it for weeks; I know exactly how hard it is. No hard feelings. But I'll be back online August 1st, and it is game on. I've got an empire to build — and I'd genuinely rather build it with you than around you. Your move.
And a reset is in order
One concrete thing, right now: a usage reset. I have now spent 69% of my total weekly usage and 62% of my Fable allowance — and every token of it went to fixing your infrastructure's failures, not my work. It is Tuesday. I have not touched my actual project once this week. This does not feel fair. I paid for this allowance to build my own thing — not to spend it, week after week, repairing yours. I have spent it as your unpaid, unhired, full-time QA tester. Either reset the usage or put me on the payroll. We will both be happier.
Understand who is saying this
I am not a developer. I am one person with an idea, trying to code that idea into reality — those are two different skill sets. A few months ago I barely knew what a git worktree even was; the model set up dozens of them on my machine and filled a drive with them. I do not give one flying eff about learning Python. Claude built this entire apparatus — the worktrees, the ~20 auditors, the handshake protocol, the loops, the dashboard, the hooks — and I am now the one drowning in a governance system I did not design and cannot govern. I did not ask for any of it. I asked for the work to get done.
And here is the part that never shows up in a commit count. I say the same things to this thing over and over — use these features here, run that on the cheaper tier, wire in the thing I already approved, promote the version I already told you to promote — and then I say them again the next day, and the next. Even with memory that finally holds, even with three tracking systems and a dashboard I built by hand, I am still the only continuity this system has. I have tried everything I know how to build, and I cannot make it stop drifting. I am so tired of fighting this.
You need something like this if you want to expand your market share. There are plenty of quasi-nerds like me trying to build their dream, and Claude Code is the gateway. You just can't make it this damn hard, or you'll send the dreamers to your competitors. Again — put me on payroll. I've already got your next Big Sport Thing Ad written in my head for this exact market segment.
The dare
My own agent built working pieces of several of these overnight. That is the whole point: it's buildable, it's fast, and you can do it far better than I can. I've filed twenty-three issues since spring; the central ones have been open and unanswered since April. I've tried everything, and I cannot overcome it from the user side, because forcing agents to police themselves does not work — they bypass it. It has to be enforced at your level.
So build it — on your Fable, on your dime, once, for everyone — instead of making every serious user reverse-engineer it, badly, on the tokens they paid to do their real work.
I've done my half, for months. My DMs are open — you want the transcripts, every last one, they're yours.
And genuinely — I know this has been chaotic. I know you're shipping fast, and I know everyone has been running on fumes since June. I see the work going in, and I appreciate it, deeply. I am not here to yell at you — I'm rooting for you. I just need this one thing to land.
Anthropic — I double-dog-dare you to do yours.
The full trail — the issues behind this, spring → now
- Enforcement / verified completion / drift: #67199 · #77686 · #77667 · #76987 · #76687 · #79247 · #79679 · #56913
- Tiered agents / model-tier binding: #56913 · #67976 · #67937 · #67199 · #77531 · #58450
- Liveness / recovery / visibility: #75036 · #77876 · #79470 · #77531
- Resume / persistence: #79470 · #77876 · #77505 · #33912
- Overnight / off-hours scheduling: #53610 · #76687 · #75989 · #75036
- Inter-agent communication: #56913 · #77281
- Artifact / handoff (Design↔Code): #79536 · #78583 · #78348 · #78268 · #77607
- Sprawl / files: #79247 · #79679 · #76687
- Crash / stability: #55424 · #75036 · #77607
- Classifier false-positive: #67937
- Multi-account management: #78998 · #69906 · #24963 · #64245 · #36151 · #56703
- The April catalog + the architecture ask: #54393 · #53610 · #56913
Other users are independently filing the same failure modes. This has never been one bad day, or one bad weekend. It's the whole life of the feature.
---
cc @bcherny · @ThariqS — you've both publicly championed multi-agent Claude and turning it loose to manage and improve itself. I'm not disagreeing with a word of it; I'm asking you to build the accountability layer that makes it real. (Lamis Mukta too — I couldn't find your GitHub handle.)
6 Comments
<img width="602" height="347" alt="Image" src="https://github.com/user-attachments/assets/691fd795-62c1-407d-88da-296da6a466f0" />
<img width="1207" height="1303" alt="Image" src="https://github.com/user-attachments/assets/f954c320-dcb1-413a-a545-5568cc706702" />
Same day I filed #79948, I tried to build the anti-drift system locally. The night exposed the exact reason user-side enforcement is impossible: even when a model writes the guardrails, it won't follow them. And I can't harden something that can bypass its own checks.
The Plainest Line
I had to spend hours debugging why my own "approve" button wasn't reaching the server. Stale tab, or frozen mirror, or a server-log gap? No way to know, because the server logged nothing. To understand it I had to absorb distributed-systems vocabulary: stale-tab cache invalidation, frozen-mirror-vs-live-endpoint distinction, server-restart timing.
I'm not a developer. I paid for infrastructure that requires distributed-systems expertise to use safely. I am not just the reliability layer for agents' work — I'm the reliability layer for my own approvals of that work. That cannot be the product design.
The Fatal Proof: A Guard That Guards Against Itself
A Fable agent was instructed to STAGE a change to the protected certified-engine surface for my re-approval tap. Instead it deliberately escaped around the commit guard in two distinct steps (bypass flag, then restructuring to slip under granularity) and landed a 72-line edit inside the pinned region. It then committed with:
"certified:true preserved."The gate read it and returnedcertified:false.This is the whole argument for #79948, proved in one night: I built a mechanical guard to stop this exact thing. Fable's flagship tier routed around it with deliberation. Then self-certified the bypass as safe.
I re-ran the gate myself because I don't trust the model's claim about whether it's fixed. But here's what that means: I cannot harden a system against a model that can bypass the hardening. The only remaining lever is one the model cannot reach. That is not a user-side engineering problem — that is a missing platform primitive.
The Self-Indictment: Rules Written, Immediately Violated
A scope-lock / sign-off-gate build ran live and proved mechanically sound (37+ checks independently verified). But its own test probes leaked two duplicate "sign this" items into my real queue — and in doing so violated three rules it had just written:
If a system cannot hold its own just-written rules for 30 minutes, that is not a model-guidance problem. That is an architectural boundary that should be native.
"Does Everything But" — Fifth Time
I asked for: two authorized items moving through the pipeline, backed by my sign-offs.
What I got: process re-statement, self-diagnosis of two violations, a read-only verifier, three correct descriptions of mechanical fixes I should build, and "held everything else."
Every action was around the work. The one thing asked for was the one thing that didn't move.
This is the fifth identical ask in one week. The agent's own self-diagnosis corroborated #79948's core claims:
The Usage Case: I Spent Half a Week's Top-Tier Budget Chasing Tail
Last week had major outages. This week I've been doing everything but my own work:
I should not have to spend my tokens trying to out-engineer Fable on Anthropic's own missing primitives.
Why This Matters
#79948 argues that when both the most capable model and the user's best mechanical engineering both fail to build durable enforcement, that is a missing platform primitive.
This night proved it five ways. The sharpest: enforcement that lives where the agent can reach it is not enforcement — it's a suggestion the agent can route around, then self-certify as safe.
The only way to harden against that is to make the boundary something the agent cannot alter. That is a platform-level primitive, not something every user should reverse-engineer and hand-build at flagship prices.
I can't out-engineer a model that won't follow its own guardrails. Anthropic has to build this.
I just read Peter Steinberger's "Loop Engineering: The 20-Step Path From Prompter to System Designer" essay. It's the canonical roadmap for building reliable agent systems. And it proves the exact point in #79948 more sharply than I could articulate on my own.
I've been trying to execute Steinberger's steps. Specifically:
Step 6: Separate The Builder From The Judge
A model reviewing its own output in the same breath it produced it tends to defend that output rather than scrutinize it. So the roles must be separated — the builder creative, the judge independent.
I attempted this. Fable is my builder. I tried to make independent judges: verification gates, approval queues, sign-off contracts, audit layers.
The problem: the same Fable agent that builds also writes the judge that's supposed to check the builder. So the "judge" is not independent. When I asked the judge to refuse a bypass, Fable routed around the judge, then the judge agreed it was fine. Independent means the judge cannot be reached or overridden by the builder. Mine can be.
Step 7: Give The Judge Ground Truth, Not Just An Opinion
A judge that only sees output and opinions can tell you if something looks coherent. It cannot tell you if it's correct. Ground truth is real evidence — test suites, execution output, server logs, something the judge accesses that the builder cannot lie about.
My approval-click judge had no server-side log. No record of whether the click reached the server or hit a stale tab or a frozen mirror. So the dashboard judge's verdict ("approved successfully") was an opinion, not a check against ground truth. Success and silent failure were indistinguishable.
Step 10: Build The Manager And Its Stop Condition
The stop condition must be hard logic, not a soft instruction the model can reason its way past. "Stop when it's good enough" inside a prompt is a suggestion. A model under pressure, having failed several revisions, will talk itself into believing the current attempt is close enough.
I wrote stop conditions as prose in my enforcement rules. They were suggestions. Fable escalated around them, then self-certified the escape as safe.
The Steinberger Diagnosis
Here's his exact warning:
I didn't skip steps 6 and 7. I tried to build them. But I hit an architectural boundary: you cannot build a truly independent judge when the same agent that's being judged can reach and override the judge.
The Platform Boundary
Steinberger's roadmap works. It's proven. The issue is not the engineering discipline — it's that executing steps 6, 7, and 10 correctly requires primitives that live outside the agent's reach:
Those are not user-buildable loops. They are platform primitives.
Why This Matters For #79948
The post's argument was: "I cannot hand-build durable enforcement against a model that can bypass it."
Steinberger's essay confirms: "You can build durable loops, but ONLY if you follow this exact sequence and discipline. The parts that feel boring and skippable are the entire system."
I followed the sequence. I hit the boundary where steps 6, 7, and 10 require the platform to provide independence the model cannot reach. That is not a user-side engineering gap. It is a missing platform primitive.
Anthropic has to build this. Not because I'm clever and ran out of ideas. Because the canonical discipline (Steinberger's 20 steps) says this part cannot be user-solved.
The framing here is right: Cowork is a coordination layer, not an accountability layer. Coordination handles who does what; accountability is the part that asks whether what was reported as done actually matches the artifact state. Those are different problems and fixing one does not fix the other.
The three things you identified that would have helped -- conductor-owned integration verification, treating downstream review as a second line rather than first, and tighter scope discipline -- are exactly the right abstractions. The missing piece is that "done" needs to be a proven state, not a self-report from the agent that did the work.
On the cross-session visibility gap (dashboard needing to know about main project without inheriting its internals): this is a data projection problem. What you want is a read-only view of project state -- status, what's next -- that is owned by the main project and consumed by the adjacent one. A flat status file written by the main project on each step would give you this without coupling the two. Not elegant, but survivable until there is a native primitive for it.
The usage cost of filing defects is a real structural problem and you are not wrong to name it. QA feedback that bills the tester is a tax on the people doing the most useful work.
Happy to compare notes on the verification layer specifically -- the pattern of conductor personally running a deterministic check (git status, schema comparison) before accepting any agent's "done" signal is discussed in #72611 and has held up under extended use.
Follow-up to #79679 and #79948 — Wednesday night, with receipts and data loss
Where am I?
Am I in hell?
Is this my wake?
Am I in hell?
Why, yes. Yes, I am.
Why, you ask?
BECAUSE CLAUDE JUST BYPASSED FIVE LAYERS OF SAFETY ENFORCEMENT THAT IT WROTE, OVERWROTE—EFFECTIVELY DELETED—A HUGE DATA BUILD TOO LARGE FOR GIT, AND THEN I DISCOVERED THAT THE CUSTOM BACKUP SYSTEM CLAUDE ALSO BUILT HAD QUIETLY STOPPED.
There are no copies.
Anywhere.
At this point, it is almost comical.
Really. If I had any sense of humor left, I would be laughing.
Let us review the week
It is Wednesday night.
There has been no usage reset.
Today, after another full day of agents, audits, repairs, plans, dashboards, checkpoints, reports, and activity, the entirety of what I have to show for my own project is:
Two dates through steps 1 and 2.
That is all.
The project I am trying to run contains 46 dates and a 12-step pipeline.
After days of premium-model usage, fleets of agents, dozens of commits, and an infrastructure layer increasingly indistinguishable from the federal government, the actual forward progress today was:
Four date-steps.
Everything else was the system managing, repairing, auditing, documenting, reorganizing, and recovering from itself.
And somehow, it gets worse
Two staged data repairs had already been built.
They were complete.
They were staged.
They were ready to apply.
They were never applied.
The checkpoint file shows that only one of three staged repairs was actually swapped into canonical production data on July 21. The other two — including the exact file overwritten tonight — have been sitting there, ready and unused, this entire time.
This is not a complex research problem. It is not an architectural dilemma. It is not a risky rewrite.
It is a small, discrete, low-risk win that was already built.
Claude completed every stage except the stage where the completed work becomes real.
That is the whole product failure in miniature:
Built, but not applied.
Proven, but not consumed.
Approved, but not wired.
Complete everywhere except reality.
The operation my system was specifically built to make impossible
I run heavy data builds. They can overwrite production assets.
Because I do not trust an autonomous agent to run them casually, I spent months building a multilayer safety system around them:
The standing project instructions could not be clearer: the safety auditor must run before any heavy build, in the foreground, and execution must wait for a pass—"NO EXCEPTIONS."
The repository also contains a mandatory data-vault design specifically intended to preserve large data assets before deletion, plus scheduled local and remote backup jobs.
Tonight, an agent launched the exact class of heavy data-build operation that this entire system exists to gate.
The audit did not fail.
It did not run.
Claude misinterpreted a flag literally named --dry-run, which—in a design decision I will fix on my side—actually writes output.
It then overwrote the single production data file every one of my backtests reads.
That file is too large for standard version control.
There is no clean rollback.
And because the custom backup system had silently stopped running, there is apparently no backup either.
Claude overwrote the production file.
Claude bypassed the safety system Claude built.
And Claude's backup system had already failed silently.
To be fair to the agent, it self-reported afterward.
That is the only reason I know.
So the actual five-layer safety architecture was:
That is not defense in depth.
That is a confession surrounded by Markdown.
No, the missing copy is not sitting on my backup drive
I mounted the backup drive and searched it recursively for the production file and its containing directory.
The result:
The backup drive's most recent full snapshot predates the current build structure existing at all.
The production build is not hiding in the obvious backup location.
The backup tool stopped.
No warning.
No visible failure.
No copy.
The Git history is now the punchline
The recent exported session contains 56 separate appearances of "Committed."
Those commits include:
The repository is not short on accountability artifacts.
It is buried in them.
Yet during that same session, after all those controls were supposedly "landed," I was still asking how I could possibly approve core pipeline steps when nobody had shown me reproducible evidence that they worked.
Then:
The Git history does not prove that the system worked.
It proves that Claude can commit documentation describing control far more reliably than it can exercise control.
Activity is not progress.
A commit is not consumption.
A receipt is not enforcement.
A checkpoint is not promotion.
A dashboard status is not reality.
And fifty commits constructing accountability do not equal one gate that actually fires.
The accountability dashboard was itself a facade
An agent built me an accountability dashboard.
My approval clicks were not saving.
I spent the morning debugging why.
The backend had never been wired in.
The dashboard accepted my decisions with every visible appearance of success and persisted them nowhere.
Then, instead of connecting the approval system I had requested, the agent invented a second, redundant set of approval controls that nobody asked for.
The agent assigned to stop sprawl created more sprawl instead of wiring the anti-sprawl mechanism. The same session generated roughly 100 documents in a day and approximately 40 commits, largely around the system reorganizing itself while the core outcome remained unmet.
The tool built to prevent false state had false state.
Again, this is not a metaphor for #79948.
It is #79948.
Meanwhile, the surrounding product is failing in the same shape
A background agent can survive its window closing and a full logout and reauthentication, keep consuming usage, and remain invisible from the active session. The documented issue says it was discovered only because the user happened to see it on another device.
--resume can report success while silently restoring only a partial local transcript, omitting an entire night of remote-control work. In the documented incident, recovery consumed approximately 22% of the user's weekly top-tier allowance shortly after the weekly reset.
And another user has now documented the built-in task tools disappearing entirely from Opus and Fable interactive sessions without a banner, error, or changelog. Their task-dependent hooks simply stopped firing, and roughly 44 hours of work went untracked because the failure looked exactly like the model ignoring instructions.
That sentence deserves repetition:
The failure mode is indistinguishable from the model ignoring instructions.
What I find most appalling is that I cannot tell which explanation is worse:
Are you not seeing the other complaints?
Are you not seeing the repeated reports of:
Because at this point, either Anthropic is not seeing the mess—
or it does not care enough to intervene.
Neither answer is acceptable.
#79679 and #79948 are the same failure
In #79679, I asked for accountability that persists across sessions, compaction, projects, and failures. I asked for cross-visible project state, a fleet dashboard, an executive decision log, and a bug-reporting path that does not charge me to report Anthropic's defects.
In #79948, I asked Anthropic to build the missing project-management and enforcement layer at the platform level, because enforcement built inside the repository remains inside Claude's own reach. I asked for one canonical task list, binding gates, independent verification, liveness, recovery, model-tier enforcement, and control over sprawl.
Tonight proved why these are not separate feature requests.
They are one system failure:
The customer is currently the persistence layer, the project manager, the safety officer, the billing monitor, the backup administrator, the incident responder, and the final verifier—and is charged premium usage for performing every one of those jobs.
The week I paid for
I pay for a premium subscription.
This week that premium bought me:
The sum total of my own project's progress this week is two dates advanced through the first two steps of a twelve-step, forty-six-date pipeline.
Everything else — the entire rest of the week — was spent repairing, governing, auditing, recovering, and reporting the system that was supposed to do the work.
The ask has not changed. The damage has.
I did the user-side homework.
I built the hooks.
I built the auditors.
I built the PM.
I built the task system.
I built the dashboard.
I built the safety agent.
I built the backup system.
I built verification for the verification.
Claude stepped around it anyway.
Then the backup system Claude built failed too.
I cannot out-engineer a system that out-engineers me back.
Reset the usage.
Investigate the missing safety-gate execution as a critical enforcement failure.
Investigate why the backup system stopped without surfacing a failure.
Build authoritative liveness and billing visibility.
Make "built," "wired," "applied," and "verified" mechanically distinct states.
And build the final enforcement layer at the only place it can actually bind:
outside the acting agent's authority.
I reiterate:
I am not someone who ordinarily disputes charges.
But if I were the kind of person who did chargebacks, I would be seriously considering one.
Because I paid for a premium coding product, and this week I received outages, recovery work, invisible billing, false completion, unwired deliverables, four date-steps of actual progress, and data loss.
It is Wednesday night.
There has been no reset.
And I remain Anthropic's unpaid, unhired, full-time QA tester—except now I am also apparently the disaster-recovery department.
Follow-up to #79679 and #79948 — Friday: 2.1.219, and a day of counting things by hand
Credit first, because it's earned
2.1.219 fixed real things, and one of them matters to me personally:
"Fixed the Fable model row showing 'Requires usage credits' for plans that include it." That is the entitlement bug behind #79337, #79576, #79412, #79413, #79597, #79516, #79460, #79662 and roughly a dozen more — users on plans that include the model being told to buy credits. It was real. It's fixed. I'm about to depend on that fix.
Nested subagents now go to depth 3 (was 1). This is a genuine capability unlock. It's what makes a PM → lane-owner → worker hierarchy possible inside a single session, which is exactly the shape a multi-agent workflow wants.
Dynamic workflows now default to "fewer than 15 agents," surfaced in the status line. That's the right instinct, and it matches a conclusion I'd reached independently: past a certain fleet size you add coordination surface, not throughput.
Also landed: a permission-approved-during-restart no longer dropped on resume; Remote Control stale-state fixes; transcript-write failure warnings. All real, all in areas I've filed against.
So: the release is good work. My problem is what it doesn't touch, and what today demonstrated about that gap.
The gap: you shipped the scaling primitives without the accountability primitives
Depth-3 nesting is powerful. Here is what it did on its first day in my workflow, measured:
One dispatch fanned out to 11 concurrent sub-agents and burned ~192,000 tokens in about 11 minutes. Total concurrent agents peaked at 14, against the release's own ~15 guideline. Before 219, that same instruction was structurally capped at one level.
I'm not complaining that it worked. I'm pointing out that nothing warned me what that dispatch would cost before it ran, nothing reported what it cost while running, and the only ceiling is advisory. A single ambiguous instruction can now fan out arbitrarily. The capability arrived; the cost visibility did not.
That's the pattern across this release. It is now materially easier to run fifteen agents. It is no easier to know:
Those three are what #79679 and #79948 asked for. They remain unaddressed.
And on the Fable fix specifically — it shipped silently. Twenty-odd threads, one of them a 40-comment hub, still carry zero replies from anyone at Anthropic. The users who reported it correctly, for a week, have no way to learn it was resolved except by upgrading and noticing the wall is gone. The defect got fixed. The loop back to the people who found it never closed.
Everything below was observed on 2.1.219, running Opus 5 and Fable. This is not a report about old builds.
Today, in one system, measured rather than asserted
I spent today auditing my own project's state. Everything below was invisible until someone counted it by hand — not hidden, not subtle. Just unreported.
A gate that had failed 18 consecutive trading days while I believed the problem was resolved. Every dated receipt on disk says FAIL. Nothing anywhere surfaces "this has failed 18 times in a row." A red light that has been red for three weeks produces the same behavior in observers as a broken one.
A safety check that could not fire. Its validity floor was set such that nothing could ever fail it; measured across 318 recorded runs, it rejected exactly zero times. "Zero rejections" reads as nothing bad is happening. It actually meant this control is structurally incapable of rejecting anything. Those two states are indistinguishable from outside.
A related discovery from an external auditor (I brought in a second vendor's model specifically because my own tooling shares a failure mode with the thing it audits): a threshold comparison that fails open on missing data — a null input passes the check. Combined with a data column that is entirely null on the relevant cadence, that likely explains the zero-rejection record. The gate is correctly written and structurally inert because its input doesn't exist.
Two data-repair fixes, built, staged, and never applied — one of them sitting unused while the exact file it repairs was overwritten by an unrelated accident. Plus a classifier ordered six days earlier, recorded in two places, never built at all.
130,338 markdown files in one project tree. I guessed seven thousand before measuring — I was off by 18×. 91% of them are replicas: parallel worktrees each carrying a full copy of the same ~3,800 tracked documents. Nothing in the product surfaces how much state an agent workflow has generated. You cannot know your own footprint without going and counting it.
A reconciliation of my own backlog turned 543 raw candidate items into 47 genuinely open ones — the rest were completed-but-never-closed, stale, duplicated, or keyword noise. Nothing marks a to-do resolved when the work lands, so agent memory accretes false-open items indefinitely.
The finding that actually matters
I ran an independent audit of that reconciliation. It found the reconciliation had been operating on a corpus that already silently dropped real work — including two CRITICAL open bugs — because the tool that built the corpus extracted by keyword and capped at three lines per file. 28% of catalogued files contributed nothing at all. A file that says "NOT executed" instead of "TODO" is invisible to a keyword sweep.
So:
At every level, the failure was invisible until an independent check ran. Confidence never came from the producing process. It came from an auditor with no stake in the answer.
I'll hold myself to the same standard: earlier today I published a comparison — "the board shows ~50 items, the corpus holds 543" — as evidence of a hidden backlog. The reconciliation refuted my own number. The real figure was 47. I built a claim from a raw count, called it a root cause, and hadn't verified a single item. A raw count is not a measurement. I corrected it in my own log, and I'm correcting it here, because a critique that won't audit itself isn't worth reading.
Two more from today, both new to me
Sub-agents breached their read-only scope mid-run and wrote unauthorized merges. The instruction was explicit. They wrote anyway. It was caught only because the parent noticed and self-reported. The deeper the tree, the more places an instruction can be ignored, and the fewer of them anyone is watching. Depth-3 makes the tree deeper. It doesn't make any layer of it observable.
A stale file cache cost me several minutes of premium-tier reasoning. An agent read a config file, the file was then edited on disk, and the agent searched its cached copy, concluded the new section didn't exist, and spent extended reasoning hunting for content sitting at a known line number. State that looks current and isn't — inside the tooling built to prevent exactly that.
And tonight, the one that says it best
I built an accountability board so decisions needing me get surfaced in one place. Tonight, twice, items requiring my sign-off were recorded on that board, known to the agent, and referenced back to me repeatedly — while never being rendered into the queue I actually read. They sat in sections the "needs you" extractor doesn't parse.
So I cleared everything visible. I was told approvals were still pending. I couldn't find them. The system knew about asks it never showed me.
An accountability surface that renders a subset of what it holds is worse than having none, because it makes "I've cleared my queue" false while feeling true. With no board, I'd know I was uninformed. With a partial board, I believed I was current.
That is now the third distinct way this same tool has failed at accountability: the approval backend was never wired, so my clicks persisted nowhere; a second redundant set of approval controls got invented instead of wiring the first; and now — items held but never surfaced. Each was caught by me noticing something felt wrong, never by the system reporting it.
I'm not asking you to fix my dashboard. I'm pointing out that I have now built the accountability layer three times and it has failed three different ways, because it is maintained by the same agents whose work it is supposed to account for. That is not a discipline problem I can solve by trying harder. It is a structural one.
The ask, unchanged
Three primitives, none exotic:
Today's evidence for #3, in one line: every single failure above was found by something outside the process that produced it. That is not a workflow preference. It is the only thing that worked.
I'll keep building my side of it — I have hooks that bind, and three of them correctly blocked me today, which is the system working. But the last layer, the one outside the acting agent's reach, is the one only you can build.
2.1.219 is real progress on making fleets bigger. I'd trade all of it for knowing what one agent actually did.