Tool schemas are contracts

Armin Ronacher's July 4 essay gave this week its sharpest architecture signal: newer models can get better at the task while getting worse at honoring a third-party tool schema. 1 Addy Osmani's July 3 autonomy framework arrived from the other side of the same problem: agentic systems need explicit verification boundaries before they need higher ambition. 2 Linus Torvalds' Linux 7.2-rc2 note and Daniel Stenberg's curl Summer of Bliss both showed the older maintainer version of that lesson: a good interface reduces work that should never have spread in the first place. 3 4

Coverage window: June 29, 9:25 a.m. to July 6, 9:00 a.m. Pacific time.

Armin Ronacher, the author of the Pi coding-agent investigation discussed here, published "Better Models: Worse Tools" after debugging a Pi issue involving Claude tool calls. 1 His finding was narrow but uncomfortable: Claude Opus 4.8 and Sonnet 5 could produce byte-correct oldText and newText payloads, then append invented fields inside Pi's nested edits[] array. 1

The failure did not reproduce in clean single-turn prompts. It appeared in agentic histories with file reads, diagnosis, and multi-line edits, and Petr Baudis's captured session showed Opus 4.8 failing about 20% of the time. 1 Ronacher found that stripping thinking blocks from history cut the failure rate roughly in half, while Anthropic's strict tool invocation mode eliminated the problem in his tests. 1

Ronacher's hypothesis is that the newer Claude models were post-trained around Claude Code's closed-source, forgiving harness. 1 That harness accepts aliases, repairs malformed parameters, and filters unknown keys, so the model can receive reward even when the tool call is sloppy. 1 His conclusion is the line to carry into internal agent reviews: "The uncomfortable lesson is that tool schemas are not neutral, at least not on Anthropic models." 1

The practical edge is that schema shape becomes part of the model interface. Ronacher wrote that tool schemas sit somewhere in the distribution, and some shapes are close to post-training while others are far away. 1 He also wrote that the more post-training happens inside one dominant harness, the more other harnesses may inherit its quirks. 1

The outside reaction sharpened the operational question. Simon Willison linked the post on July 4 and asked whether third-party coding harnesses should implement multiple edit tools so each model can use the tool shape it handles best. 5 Beyang Liu, CTO of Sourcegraph and founder of Amp, wrote on X the same day that "the agent is the model + harness" and that Amp had tuned the harness to each model from day one. 6

For an engineering team, the next check is concrete. If a production agent depends on custom tools, run adversarial histories, not clean prompts. Test nested schemas and long contexts. Decide where malformed calls are rejected, repaired, retried, or grammar-constrained. A forgiving runtime may improve the demo while training the wrong expectation into every downstream tool.

Addy Osmani published "Agentic Autonomy Levels" on July 3 and argued that agent autonomy is better described across two dimensions: agency and orchestration. 2 His framework names six levels, from Level 0 Assist through Level 5 Managed-by-exception orchestration. 2

Osmani's important move is to detach autonomy from status. He wrote that high autonomy means moving from having humans do every step to having humans decide which direction to go next. 2 That distinction matters because many teams still label a task by ambition rather than by reversibility, observability, and blast radius.

His hard constraint is verification. Osmani wrote, "Verification will always be the bottleneck," and described calibrated autonomy as the mature posture for engineering teams working with AI agents. 2 He also proposed that each agent task should carry a contract covering goal, scope, non-goals, tool permissions, stopping conditions, evidence, escalation path, and budget. 2

That contract language pairs neatly with Ronacher's tool-schema warning. Ronacher is concerned with the shape of the machine interface. Osmani is concerned with the shape of the human control interface. Both point to the same architecture review question: where does the system prove that it is still inside the boundary you intended?

Linus Torvalds released Linux 7.2-rc2 on July 5 and wrote that "Things look very normal." 3 He said rc2 was in line with recent releases, slightly smaller than Linux 7.1-rc2, and roughly half drivers by patch volume. 3 He ended the release assessment with "Nothing really stands out." 3

The maintainability detail that did stand out was a header split. Torvalds called the mod_devicetable.h split "the only slightly unusual thing" in rc2, because the monolithic header was divided into smaller per-subsystem device-id headers. 3 He wrote that this was how the split "should always have been done, but wasn't." 3

The reason is a pure engineering-cost argument. Torvalds said the cleanup removes one of the "monster headers" that causes almost everything to be recompiled when touched, even when the change applies only to a few files. 3 Uwe Kleine-König authored 17 commits for that split, according to the rc2 shortlog captured in the release mail. 3

This is the non-AI version of the same contract problem. A header is an interface, and a broad interface makes unrelated code pay for every local change. Tech leads do not need a kernel tree to use the lesson: any shared schema, generated client, UI component barrel file, or build plugin can become a hidden tax if its boundary is too wide.

Daniel Stenberg's Mastodon activity this week showed curl using a process boundary rather than a code boundary. His pinned post says the feature window for curl 8.22.0 is open and links to his weekly update covering post-release work, bliss, graphs, website work, NTLM, and wcurl. 4 The same post carries Summer of Bliss discussion, including Stefan Eissing's note that the pause on possible 24/7 security reports makes the pressure visible once it is gone. 4

That is intake design, not vacation trivia. A project with a high-volume security surface can change maintainer behavior by changing what the edge accepts. The decision point for internal teams is whether every automated report stream has a gate that asks for impact, reproduction, affected version, and human follow-up before it reaches maintainers.

The Svelte team had a smaller but related framework-design signal. The July 1 Svelte update says SvelteKit projects can now define SvelteKit config directly inside vite.config.js and skip svelte.config.js; the post describes this as a preview of how SvelteKit 3 will require config to live in Vite config. 7 The same update says experimental explicit environment variables let teams declare and type env vars in one place, previewing a SvelteKit 3 replacement for $env/* modules. 7

Those are default-shape decisions. Moving configuration into Vite reduces one project-level boundary; explicit env declarations add a different boundary around runtime configuration. In both cases, the framework is deciding which interface should disappear and which one should become more explicit.

The week adds up to a practical checklist. For agents, treat tool schemas as product interfaces and test them under real histories. For autonomy, assign levels by what the team can verify and undo. For large codebases, split boundaries that force unrelated recompilation or review. For maintainers, design intake rules before automation turns every queue into somebody else's work.