State Digests Across Agent Tools
By DX Research Group · · State and memory
Use digests to compare declared state representations, with schema and semantics attached.
A state digest is useful only when the tools agree on what it covers. We would bind the digest to a schema, a canonical representation, and a decision boundary. Matching hashes over different field selections can give a false impression that two tools used the same state.
The snapshot identities in our state and memory framework give this comparison a home. Our trace feedback method needs the covered representation so a mismatch can be diagnosed, rather than reported as a mysterious hash failure.
Same facts, different bytes
Imagine two hypothetical tool responses containing account A, cash 250, and position 2. One serializes keys in account-cash-position order, the other in position-account-cash order. Hashing their raw JSON produces different digests even though their declared field values agree. Whitespace can create another byte-level mismatch.
RFC 8785 specifies a JSON canonicalization scheme intended to produce deterministic serialization. We would use a documented canonicalizer for representations within its supported data constraints. The resulting digest identifies canonical bytes; it still needs an application-level schema to explain what those bytes mean.
Now suppose tool B omits a pending-order reservation of 40 while tool A includes it. A digest restricted to cash and position can match. That match says the selected fields agree. It cannot establish parity of available capital or the complete decision input. The omitted field must remain visible in the coverage declaration.
Three mismatch classes
We would first distinguish representation differences from factual differences. Canonicalizing key order fixes the first case. It does nothing for cash 250 versus cash 240. A third class is a scope mismatch: the tools intentionally digest different fields or observation boundaries. That should produce a typed comparison failure before any hash equality is interpreted.
The fixture supplies all three cases, plus a change to a covered field and a change to an uncovered annotation. Expected behavior should be declared for each. If annotation changes are excluded, the documentation should explain why they cannot change an admissible action. A source-confidence label that affects fact eligibility belongs in covered state, even if it looks like metadata.
Digest construction also needs precise decimal and null handling. A string “250.00” and a number 250 can reflect different serialization contracts. Missing and null may have different meanings. Normalizing them requires a schema rule, rather than an opportunistic conversion made solely to obtain matching hashes.
We would retain the canonical payload reference with the digest, and protect access according to the underlying record. A hash is a comparison aid, not permission to publish private state. The proposed protocol concerns tool consistency and trace diagnosis, with no claim about current DXAP hashing. Its useful result is a mismatch explanation that names the exact field or scope difference. That explanation turns an opaque digest into an operationally actionable check.