In May, my code reviewers argued with me, and I can prove it, because the arguments are still in the repo. Three review agents read the same diff on a small trading system I run, and they came back with three different answers. Vik, the simplicity lens, returned REVISE after catching that the refactor’s own ADR had promised to delete a timezone workaround that was still sitting in the consumer code, and closed the finding with a line I would happily pay a human reviewer for: “If we trust the normalizer, we drop the wrapper; if we don’t trust it, the ADR didn’t actually fix anything. Pick a side.” Tara accepted the change from the testing side but corrected the sprint brief’s arithmetic on her way through: the brief claimed the work added forty tests net, and she counted the suite and reported the real figure, which was minus two. Pierrot, reading for security, flagged an audit-trail invariant neither of the others had looked at. Three verdicts on one diff.
By early August the same team had one verdict for everything: approved. No split decisions, no findings that stung, and nobody correcting the team’s own arithmetic. If you’d asked me in the moment, I’d have told you the team had never run smoother. That unanimity turned out to be the most expensive signal my tooling has ever produced, and by the time I learned to read it, the right call was to kill the team rather than fix it.
The team was my virtual development crew, sixteen agent definitions and twenty-four slash commands built on top of Claude Code, which I’d run for about a year and open-sourced so other people could run it too. Cam scoped the work and Archie turned the decisions into ADRs. Tara wrote tests that Sato then had to implement against, and a composite reviewer ran four lenses over every diff before I was allowed to commit. For most of that year it was the most productive thing in my toolbox, and then over the course of a few weeks it quietly stopped being any good, and I had to decide whether to fix it or kill it.
I killed it. The habit of checking whether the roster still worked was the thing worth protecting, and I’d spent the year protecting the roster instead. Any tool you build on top of a model and a harness you don’t own is fitted to conditions the vendor can change without telling you, which means fitness for purpose is a question you have to keep asking rather than a property the tool has. You ask it about the work, the model, and the harness underneath both. And when the answer comes back no, the right move is usually to kill the thing rather than patch it.
That last part is the one people get wrong, including me, for longer than I’d like to admit.
The mechanism is fifty years old
In 1976 Robert Lucas published Econometric Policy Evaluation: A Critique, widely considered the most influential macroeconomics paper of the 1970s. The argument: if you fit a statistical relationship to how an economy behaved under one set of policy rules, you can’t use that relationship to predict what happens when you change the rules. The relationship was never a law of nature, just people optimizing against the rules you’d changed. Fit a curve to the old regime, change the regime, and the curve is worthless.
Lucas’s remedy went deeper than refitting the curve more often: stop treating fitted relationships as structural at all, and build instead on what he called deep parameters, the things that survive a change in the rules.
Every agent definition I wrote was partly real spec and partly fitted curve. When I went back to grep for the fitted part, I expected coaxing prose, delegation pep talks and “double-check your work” lines, and found none; my memory had invented them. The real curve is quieter. All sixteen files carry maxTurns caps, model: inherit, and tool allowlists, pure harness parameters that mean nothing outside one product. The delegation pressure sits a level up, in the repo’s CLAUDE.md, as a rule with teeth: spawn the named agents or it’s “a process violation.” And what I remembered as verification phrasing turned out to be an apparatus, a completion-sentinel protocol that re-runs any subagent whose report arrives without its end marker, built because agent output truncates silently. None of it describes the work, only how to get a particular model on a particular harness to comply. I’d been calling it engineering for a year without noticing it was curve fitting.
What changed underneath it
Three things, inside about a fortnight.
Claude Opus 5 shipped on July 24th. Anthropic’s guidance for prompting it is blunt about the verification half of my tuning: the model checks its own work without being told to, and prompts carrying explicit verification instructions should lose them, because they “cause over-verification” and “add cost without improving results.” The delegation half aged in the opposite direction: Opus 5 delegates to subagents more readily than prior models, so the advice now is to rein delegation in with explicit scenarios and hard caps. My CLAUDE.md ordered delegation up as a process rule, exactly the pressure the guidance now says to reverse. The verification half lands differently than I first read it: my apparatus guards against subagent reports truncating in transit, which is a harness failure, and a model that verifies its own work doesn’t fix a report that never fully arrived. So the migration guidance caught half my tuning dead to rights and couldn’t see the other half at all. A fitted prompt decays past useless and into harmful, and mine was documented doing it.
Meanwhile the harness moved, in both directions at once. Claude Code 2.1.217 “added a cap on concurrently-running subagents (default 20)” and “changed subagents to no longer spawn nested subagents by default.” Three days and two versions later, 2.1.219 put nesting back at depth 3. A per-session cap of 200 subagents appeared on July 17 and was removed on August 7. My composite reviewer fans out across four other agent files, so it sits directly on that fault line, and I spent an embarrassing number of sessions manually approving something that used to just run.
And the harness started editing the conversation itself. The day Opus 5 shipped, users caught Claude Code injecting a server-gated prompt section, into Opus 5 sessions only, that told the model: “Do not call the AgentTool unless the user requested it.” No changelog entry, no opt-out; people found it by running strings over release binaries and diffing. The injected section renders after everything the user wrote, and it countermands any roster built on delegation, which mine was. I thought I’d have to exhume session logs to prove it silenced my reviewers. Then, while this post was in edit, a Claude session doing the deprecation work in the summon repo reported the injected line sitting in its own system prompt that day, and named it as the reason it had done the work solo instead of spawning the personas the repo’s CLAUDE.md mandates. The mechanism reproduced inside the session that was carrying out the kill. A reviewer that stops being spawned as its own agent stops speaking in its own voice; my team was as sharp as it had ever been, and the room they were speaking into had changed shape.
The silence was the signal
None of that announced itself in my terminal. What I actually observed arrived in a different order, and all of it was misreadable.
First the voices flattened. Vik’s specific impatience, Tara’s precision, the register that made each reviewer recognizable before you read the signature, all of it drained out until the reviews read like they’d been written by one careful, forgettable author. I noticed, and filed it as cosmetic. The characters were the part I’d enjoyed writing, so I assumed that missing them was sentiment rather than data.
Then the disputes thinned out. Reviews that used to come back split started coming back aligned, and then unanimous. The May pattern, three lenses returning three verdicts on one diff, stopped happening, and I filed that as good news too: cleaner code, a team hitting its stride.
It was neither sentiment nor good news. A reviewer who always agrees with you carries no information. The whole point of running four lenses over a diff is the disagreement between them; when Tara corrects the team’s own brief, the ACCEPT sitting next to the correction means something. When every lens waves everything through, approval stops telling you about the code and starts telling you about the reviewer. And the fitted-curve frame explains why the failure took this particular shape: the personas’ friction was tuned against an older model’s temperament, so when the model underneath became more capable and more self-verifying, the fitted dissent decayed into consensus rather than noise. That’s worse, because noise gets investigated and consensus gets celebrated.
That’s what makes this failure mode dangerous. It presents as health. While writing this I went back through my repos, and the most recent review artifact that contains a real dissent is dated May 15. I’d like to tell you I noticed the trend at the time, but a team going quiet under you feels exactly like a team that has finally stopped needing supervision.
Everyone was holding a fitted curve
If this were only my story, it would be a confession with a moral attached. The issue tracker says it’s a season. In the four weeks after 2.1.217, GitHub collected 763 issues mentioning subagents. The injection thread filled with reports from operations bigger than mine: a fleet operator who measured the delegation throttle across roughly 1,350 sessions and reverted the whole fleet off Opus 5; an SRE whose skill mandates fanning out into eight parallel lanes and watched the sweep run serially instead; a team that burned “two days of engineering time... to find this undocumented gem that bricked all of our long running agent focused automation.” And in the same weeks a 982-point Hacker News thread complained about the opposite failure, Opus 5 spawning a subagent per file just to summarize it. The field spent August discovering its delegation tuning was wrong in both directions at once.
The named accounts land closest to home. Huy Tieu audited his agent harness the day after the release and found 1,500 lines of obsolete instructions. And Boris Cherny, who created Claude Code, said at Startup School that his team deleted more than 80% of the product’s own system prompt when Opus 5 arrived, because the prompt had been “correcting for these behaviors that the model should have known, but it didn’t. Now, Opus 5 just does it.” His standing advice to users: “Every 6 months delete your Claude.md. Delete your skills. Delete your hooks. See what the model does and it might surprise you.” The person who built the harness runs the fitness audit on a calendar. I ran mine a year late, at the morgue.
None of this is a Claude story, either. Cursor deprecated the .cursorrules format its users had spent a year tuning. OpenAI’s Codex CLI rewrite renamed its approval modes and broke old configs. GitHub Copilot renamed the frontmatter key its prompt files keyed on. Every major vendor now publishes migration guidance whose message reduces to: the prompt patterns you tuned for the last model are wrong on this one. There’s even a published precedent for tuning inverting on a stronger model. Nori and colleagues at Microsoft showed in late 2024 that the few-shot prompting that had helped GPT-4 on medical benchmarks actively hindered o1. What happened to my delegation nudges had been in the literature for twenty months, filed under a different model’s name, and I had read it the way I read changelogs: as news about someone else.
The file told me what it was
Here is the artifact that ended the argument for me. My composite reviewer describes itself, in its own frontmatter, as: “Not a persona — an invocation pattern combining four core review lenses.”
I wrote that line. I’d read past it a hundred times. It says out loud that the file is merely a way of getting a specific harness to do a specific fan-out. Nearly everything structural in it is fitted: the turn limits, model: inherit, the fan-out across four sibling files, and most of the tool allowlists, though not all of them, and the exceptions turn out to matter. None of the fitted part survives a regime change or means anything outside Claude Code.
But the four lenses inside it are a different kind of object entirely. Vik’s laziness ladder, the one that asks whether the standard library or an already-installed dependency covers this before you write custom code. Tara’s question about whether the tests actually pin the behavior down, Pierrot on security, Archie checking the change against the architecture we claimed to have. Those are deep parameters. They were true about my codebase before Claude Code existed, and they’ll be true after it. They were sitting inside a wrapper that was busy dying, and I nearly threw them out with it.
And there are two more things in the wreckage that I’m not willing to call fitted, but not yet entitled to call deep. The first is the context boundary itself. Every subagent ran in its own context, seeing only its definition and the task it was handed, which means every role was an independently tunable surface: what the test writer saw and what the reviewer saw could be curated separately, per task, without either polluting the main thread. The second is enforced separation of duties. My coding agents could not write tests, and my testing agents could not touch non-test code, which structurally removes the oldest failure mode in automated coding, the one where the model “fixes” a failing test by making the test easier to pass. Nothing in either idea negotiates with a model’s temperament; the second is just the maker-checker rule banks have run for a century, expressed as a tool allowlist.
But the Lucas critique cuts both ways, and it won’t let me promote my own favorites. Deep parameters earn the title by surviving a regime change, and I have only ever run these two ideas inside one vendor’s harness. Structural-looking is exactly what fitted things look like from the inside; a year ago I’d have told you the delegation nudges were structural too. So both go on the books as hypotheses rather than salvage, and I’ll say below how I intend to test them.
An industry has run this experiment already
In February 2011 Google shipped Panda, which hit around 12% of all search results. Content farms that had built real businesses on keyword density and thin-page volume lost most of their traffic in a week, and some of them never came back. Penguin did the same thing to link inventories a year later.
The shops that survived were the ones who accepted that their accumulated playbooks had been fitted to a ranking function they didn’t own and couldn’t see, and who went back to the thing Google was actually trying to measure. Better patches saved nobody. The ones that died spent 2011 and 2012 patching, and it’s worth remembering that from the inside patching always feels like the responsible, incremental, non-wasteful choice. The Japanese have a word for the discipline I needed here, 断捨離 (danshari), refusing, discarding, and letting go. It’s usually applied to closets, and it works fine on .claude/agents/.
The strongest case against me
The counter I’d make if I were reading this over someone’s shoulder: what you’re calling decay is the platform absorbing your scaffolding. Opus 5 delegates well on its own, verifies its own work, and holds instructions across a much longer context. Your team got less useful because it became redundant. That’s the vendor doing your job for you, and calling the cleanup afterwards a discipline is generous.
That’s largely right, and I can’t fully score it. Part of the roster died because the ground moved under it; the rest had simply become redundant, compensation for weaknesses the new model no longer has. I suspect the redundant pile was the bigger one; my ego would prefer otherwise. Some of what I deleted deserved to go a while ago. Cherny’s 80% number is the same concession made at the vendor’s scale: most of what any of us wrote was compensation.
What the objection doesn’t reach is the next one. “The vendor absorbed my scaffolding” and “the vendor broke my scaffolding” produce the same symptom, which is a tool that used to work and now doesn’t, and the only way to tell them apart is to look. Redundancy is an explanation you can only offer after the review you weren’t doing. And it says nothing about the parts of a roster that encode taste rather than capability, the ones that say what done means on this specific codebase. No frontier model ships those natively, because they aren’t in the model. They’re in the repo, and in me.
What I’m running instead
Two moves, which turned out to be the same move.
For my own use, I’m rewriting the agents worth keeping as skills. The Agent Skills format is an open specification, released as an open standard by Anthropic last December and picked up across a long list of other tools since; OpenAI’s Codex documentation now cites the spec directly. A subagent roster runs on exactly one harness, while a skill is just a folder with a Markdown file in it and runs anywhere that reads the spec. Converting one to the other is the Lucas move performed with a text editor: keep what the work requires, delete what made one model comply.
In practice that conversion is mostly deletion, and the ratio is humbling. The tool allowlists and the turn limits go, along with every instruction about when to delegate and how much to verify, because all of that was negotiation with one model’s temperament. The persona voice mostly goes too, which stung more than I expected, since the characters were the part I’d enjoyed writing. What’s left is a description of the work and the standard it has to meet, and it turns out that’s the short part of the file. Vik’s laziness ladder survives the trip almost untouched. The apparatus I’d built to make sure Vik actually got consulted does not.
That asymmetry is the tell I should have read far earlier. If most of a file is about getting the model to cooperate rather than about the job, the file is a fitted curve wearing a name badge.
The second move is a bake-off: Claude against Codex on the same real work, with GitHub Copilot’s agent mode queued behind it. And the bake-off is where the two hypotheses from the wreckage get their trial. Per-role context isolation and the writer-versus-verifier split are claims about the work, if they’re claims about anything, so they should survive being carried to harnesses I never tuned them for. Either they hold up on Codex and GitHub Copilot, in which case they’re deep parameters and I’ll build on them anywhere, or they turn out to be Claude-Code-shaped conveniences I mistook for principles, and I’d rather learn that from a bake-off than from another year of comfortable fitting. I went looking for company before writing this, and the public record is quiet: plenty of deleted tuning and a few reverted fleets, but no documented wave of people converting rosters to portable formats. Early or wrong. The bake-off decides which.
The conversion to skills has a cost that sits exactly here, and I want it on the record because portability is doing a lot of work in this post. A skill is prose: it can describe a separation of duties, with no way to enforce one. The roster, whatever else was wrong with it, gave me hard boundaries, a testing agent that could not edit source files no matter how tempting the shortcut looked from inside its context window. The skills I run now depend on the model choosing to honor a boundary it can read. If the cross-harness trials come back saying those boundaries are what actually mattered, then the portable format has a hole in it precisely where the roster was strongest, and some enforcement layer will have to come back. I don’t know what shape that takes yet, and I’m suspicious of anyone who currently claims to.
I couldn’t have run any of this comparison a month ago, because my entire development practice was expressed in a format that only executed inside one vendor’s product. Breakage is the visible cost of tooling fitted to a single vendor; the quiet cost is that it removes your ability to go shopping, without ever showing up as a line item. By the end the roster was holding the vendor choice shut, which cost me more than its declining output ever did.
The review I wasn’t running
So what does checking actually look like, given that I clearly wasn’t doing it? Three questions, and they are not equally hard.
Whether the tool still fits the task is the easy one, and it mostly takes care of itself. Work pushes back daily. If you’ve built something for greenfield feature delivery and your month turns into migration and incident response, the mismatch shows up as friction you can feel, and you’ll notice without needing a process.
Whether it still fits the model is harder, because model releases are loud and their consequences are quiet. Every vendor publishes migration guidance now, and almost nobody reads it the way it needs to be read, which is as a diff against your own files. Anthropic told me in writing that the model now delegates readily and verifies its own work, and that prompts should stop pushing both. Half of that had my name on it in every practical sense, and I read it as industry news. The discipline here is small and specific: when a model you depend on ships, open the migration notes next to your own prompts and go looking for the instructions that just became wrong.
The harness is the one nobody checks, and it’s the axis that killed my team. Changelog entries about concurrency caps and spawn depth don’t announce themselves as being about you. They read like plumbing, written for someone else, in a register that suggests nothing is being taken away. But the harness is the execution environment for everything you’ve built on top of it, and a default that changes from “nested subagents allowed” to “nested subagents denied” is a breaking change delivered as a bullet point when your reviewer is a composite that fans out across four files. And the July change that cut deepest never appeared in the changelog at all. I’d been treating harness releases as free upgrades for a year. They are potential invalidation events for your entire toolchain, and the version number gives you no clue which kind you’re getting.
None of that is expensive. It’s an hour, maybe, on a release you were already installing. What made it expensive for me was that I’d never scheduled it, so the only thing that could ever trigger a review was the tooling degrading badly enough to be annoying. That is roughly the worst possible detector, because the failure mode I actually got never annoys anyone. The metric that would have caught it was sitting in my own review artifacts the whole time: disagreement rate, trending to zero.
There’s a version of this post I’d rather have written, where I noticed all this in July and made a clean call. What actually happened is that I spent a few weeks assuming I was holding it wrong, rewriting instructions that were never going to work again, and getting mildly irritated at a model that was doing exactly what its documentation said it would do.
I open-sourced this thing, and here’s what I know about who’s running it: nothing. Zero stars, zero forks, and a download graph that is one publish-day mirror spike followed by scraper noise. GitHub doesn’t count template copies, so anyone who adopted the roster that way is invisible to me, fitted to a regime that ended in July with no way to hear that it ended. Which makes this post the deprecation notice, because no other channel reaches them. The summon agent team is deprecated as of today, and I have nothing to hand you in its place.
I’d rather publish that than a tidier version of it. I’m still working out whether there’s a rebuild worth doing, or whether a published roster was always the wrong shape for something this exposed to one vendor’s release schedule. The skills I’ve written for myself are working fine, but a personal skills folder isn’t obviously a contribution to a world that already has more skills libraries than anyone can evaluate, and shipping an undifferentiated one to prove I’m still shipping would be its own kind of curve fitting.
I’m also not going to pretend the skills are permanent. They’re a longer-lived bet than a subagent roster, since the format outlives any single vendor’s product decisions, but they’re still fitted to something: to a spec that can change, and to a rough consensus about how coding agents load context that’s maybe eighteen months old and has never been tested by a real platform fight. It’s a wider foundation, and I’d rather say now that it isn’t bedrock than write this same post again in a year with the nouns swapped.
The bake-off isn’t finished and I don’t know which way it’ll go. I’ve put a date in the calendar to run the same three questions against whatever I’m using in six months, and this time the audit has specific questions in it: whether the context boundaries and the maker-checker split survived contact with harnesses I don’t tune, and whether my reviewers, whatever they’re running on by then, still argue with me. The answer has a shelf life, and I now have direct evidence that I won’t notice on my own.


Unanimity as the most expensive signal is the sharpest framing of agent drift I have read. I run verification agents over my own builds, an auditor whose whole job is to distrust the builder, and this piece names the failure mode I worry about most: the day the auditor stops finding anything and I read that as health instead of decay. The Lucas critique application is exactly right. The roster was fitted to a regime you do not control, so the habit of re-asking whether it still works is the only durable asset. Protecting the checking instead of the roster is going on my wall.