On August 13, a 28-file Pydantic AI commit changed the answer to a practical runtime question: what does an agent really know after its long conversation has been compressed? Not a tool merely because its name survived somewhere in the system.
When a deferred tool's reveal—or the loading of the capability that owns it—has fallen behind a compaction boundary, Pydantic AI now refuses the direct call and tells the agent how to recover. That turns a hidden state mismatch into an explicit next step.
That sounds fussy until an agent has to resume real work. Tool discovery is a way to keep giant schemas out of every prompt, and compaction is a way to keep a long session within its context budget. Before this change, those two savings measures could leave an awkward mismatch: the current prompt no longer carried the discovery record, while a model could still emit the old tool name. The new rule puts the model's visible history and the runtime's callable set back in the same frame.
The missing receipt is the point
The updated compaction documentation calls the boundary a reset for derived tool state. A searchable tool can remain in the corpus, but if the history that showed its schema has been compacted away, the call gets a retry: search or load again. For a deferred capability, the sequence is stricter: load the capability, let the next model request carry its instructions and tools, then call it. The load and the call are not meant to happen as one unaccounted-for leap.
The new regression tests make the intended recovery concrete. A deliberately guarded tool called secret_op is refused before its capability is loaded; after a compaction event, it must be loaded again; and the tool is withheld from the advertised list rather than shown as a tempting button that cannot work. The suite also tests a more subtle case: one loaded capability cannot smuggle another deferred capability's tool into view.
Test the resume, not just the happy path
For builders, the useful test is now precise. In a disposable agent run, discover or load one deferred tool, compact or replay the history, and have the model try the old tool name. It should receive an actionable refusal without invoking the tool; after a fresh search or capability load and a later model turn, the call should become eligible again. That test catches a disagreement between the prompt an agent can act on and the tools the runtime is prepared to execute.
This is not a general authorization system, and the source itself says it is not trying to make history tamper-proof. The change does not prove a released package or production behavior, either. Its value is narrower: it makes the next failure legible. Watch for release notes and integration tests that exercise compacted, replayed, provider-switched, and client-submitted histories—places where a tool's old name is easy to remember and its current context is easy to lose.