Invalidating Agent State Caches After a Trade

A trade should invalidate the cached state derived from its economic effects. We would identify those dependencies explicitly and prevent a late response from repopulating an older generation. Expiring entries after a fixed duration can leave a window in which the next turn sees an internally inconsistent account.

Our state and memory framework lists invalidation events for portfolio and order state. This note narrows that idea to cached derived views. The decision trace should record the cache generation that supplied each affected field.

A late response revives an old balance

In an illustrative sequence, generation 7 contains available cash 500. A request for generation 7 begins. A fill then spends 100 and incurs a fee of 1, establishing cash 399 in generation 8. The old request finishes after that update and returns 500. A cache that accepts the most recently received response can replace 399 with 500.

We would bind each request to its generation and reject publication into a newer cache generation. The old response remains an inspectable result for its original request. Its arrival time gives no right to overwrite the updated state. A fresh request for generation 8 must either produce the compatible value or report the account boundary it actually observed.

The invalidation set includes available cash and any exposure summaries derived from the fill. It may also include a budget estimate that uses both values. An unrelated cached venue-rule document can remain valid under its own contract. Dependency-scoped invalidation avoids turning every trade into a full refresh of every tool.

Freshness has a cause

RFC 9111 describes HTTP caching, including freshness and invalidation behavior. Its protocol rules are useful context, but an agent's portfolio cache needs domain-specific dependencies beyond a resource's ordinary HTTP freshness lifetime. A response can be fresh by HTTP age while obsolete for the account after a fill.

The proposed fixture starts two requests before a fill, completes one before invalidation, and completes the other after. It then requests a dependent budget view and an independent venue view. Expected outputs specify which generation each result can enter. A duplicated fill notification should preserve the same economic update while keeping invalidation idempotent.

We would measure stale-state admission count, refresh delay, and unnecessary refresh count separately. Suppressing every cached value eliminates one failure mode while increasing availability cost. A useful design exposes unavailable dependent fields during refresh and lets policy decide which actions require them.

The example assumes a settled cash debit for clarity. Real fills can have intermediate states, whose cache contracts must be declared separately. This is a proposed test rather than evidence of a current DXAP cache mechanism. The review should finish with the delayed response that was prevented from reviving generation 7. That receipt demonstrates the race handling more clearly than a configuration saying the cache has a short lifetime.