How trading agents assemble current market and portfolio state, preserve memory provenance, bind snapshots, and test stale-data behavior.

A trading agent needs a versioned state snapshot that separates current market facts, current portfolio facts, and source-labeled memory before the model chooses an action. The snapshot should identify what the runtime knew, when each field was observed, which source supplied it, and whether settlement has made any part of it obsolete.
We use state snapshot to mean the decision-bound record of market data, portfolio state, venue status, clock fields, and unresolved execution events presented for one invocation. We use memory provenance to mean the source, observation time, effective time, and supersession status attached to a retained item. These mechanisms keep an old observation from quietly becoming a current fact or a new trading rule.
This is the state and memory spoke in our trading-agent harness and runtime cluster. The mandate compiler resolves what the user authorized. State assembly answers a different question: what was true when the agent acted?
Download the versioned state and memory test checklist or the CSV edition. Each row names a failure fixture, a pass condition, and the runtime response we would expect before granting new exposure.
Evidence boundary: The measured observations below come from DX Terminal Pro, a bounded 21-day real-capital deployment and its controlled pre-launch tests. State integrity, memory provenance, and trace completeness do not establish alpha, profitability, universal safety, or cross-market transfer.
A model can produce a coherent answer against an incoherent world. The market price may come from one block while balances come from the next. A pending fill may appear in transaction history before the portfolio view reflects it. An old strategy summary may describe a setting the user has already replaced. The prose still reads smoothly, which makes the error difficult to see without an explicit state identity.
Our preferred state identity has three anchors:
The cutoff matters because "latest" is ambiguous across systems. A price feed can be current while a balance indexer lags. A venue acknowledgement can arrive while a portfolio service is still computing the new position. The runtime should surface those differences rather than flatten them into one falsely current object.
The snapshot identifier gives the decision a stable reference. If the market moves during inference, the validator can compare the proposed action with the state version the model saw and with a fresh pre-submit check. The system can then approve, resize, reject, or abstain according to deterministic policy. A later investigator can reconstruct the same boundary.
Market state, portfolio state, and memory have different authority. Combining them into a single text history makes retrieval easy while hiding which fields can authorize action.
| State layer | Authoritative content | Minimum lineage | Typical invalidation event |
|---|---|---|---|
| Market | Price, liquidity, reference data, and tradable-universe status | Feed, venue, observation time, sequence | New quote, new block, or feed disconnect |
| Portfolio | Balances, positions, available capital, fees, and exposure | Account or vault, ledger time, settlement marker | Fill, fee, transfer, or reconciliation change |
| Orders | Proposed, submitted, acknowledged, partially filled, and terminal orders | Stable request ID, venue order ID, transition time | Acknowledgement or order-state transition |
| Venue | Trading status, asset rules, minimums, and connectivity | Venue, rule version, observation time | Halt, rule update, disconnect, or degraded mode |
| Memory | Prior observations, summaries, decisions, and operator notes | Source, observed-at time, effective interval, supersession link | New fact, mandate change, or explicit expiry |
The model may reason over all five layers. Authority remains outside the prose. A prior rationale can suggest a question to investigate, yet it cannot change a capital limit or overwrite a reconciled balance. A retrieved market observation can explain a past action, yet the current feed controls the new decision.
This separation also makes abstention precise. When a required balance is missing, the runtime does not need a model-generated guess. It can return a typed unavailable-state result, withhold new exposure, and start a controlled refresh or reconciliation path.
DX Terminal Pro gave us a long-running record rather than a set of isolated prompts. Continuously active agents accumulated more than 6,000 prompt-state-action cycles. The frozen production runtime read current onchain configuration before each inference and rendered derived market data, portfolio state, recent tool calls, memory, and clock fields.
Each invocation preserved the compiled prompt, model response, extracted reasoning, tool call, portfolio snapshot, validation result, and chain outcome. That linkage let us distinguish a strange rationale from an invalid action. It also let us ask whether a missed trade came from the mandate, current state, memory, the model, policy, or execution.
One pre-launch failure made the memory boundary visible. Sell traces invented names such as "Hierarchy rule #2" and "Rule A." The affected traces fell from 57% to 3% after a compound intervention removed law-like wording, labeled prior decisions as context, and prohibited invented named rules and thresholds. We preserve the compound attribution because the test did not isolate memory labeling by itself.
A second failure came from repeated observations. Some agents treated elapsed ticks since the prior trade as a signal and formed a cadence. Filtering memory so repeated observations could not become a self-reinforcing rhythm reduced that pattern in sampled traces. The paper reports the direction of the shift without a numeric incidence rate, so we do the same here.
These scenes changed how we think about memory. More retained text did not automatically create more situated intelligence. The portfolio, transaction history, strategy status, cooldown state, and rolling observations already carried much of the information needed for the next decision.
Memory architectures can improve a financial agent under a defined evaluation. FinMem, for example, studies a layered memory module that processes financial information at several timescales. That research asks how retained information can support decision-making in its benchmark.
Our runtime question is narrower: which retained item is still eligible for the current decision? In Terminal Pro, traditional open-ended memory and retrieval-augmented recall were not obviously helpful. Semantically similar text could describe a prior market regime, an expired strategy, or a balance that settlement had already changed. We therefore treated memory primarily as structured, recent, source-labeled state.
A useful retained item has a lifecycle:
| Field | Question it answers |
|---|---|
| Source | Which feed, ledger, user action, tool result, or runtime stage created it? |
| Observed at | When did the system receive the underlying event? |
| Effective interval | During which decision window should the item be eligible? |
| Subject | Which venue, asset, account, order, or mandate does it describe? |
| Supersession | Which newer record replaces it, and why? |
The lifecycle distinguishes context from precedent. A prior decision can show how the agent interpreted a similar setup. Its authority ends there. Current policy and current reconciled state still govern the next action.
There is a separate memory issue in historical evaluation. KTD-Fin masks identifiers and calendar information to test whether model knowledge of historical markets is substituting for transferable decision-making. That is an evaluation-leakage problem. Runtime memory provenance addresses what the deployed harness deliberately retained and supplied. Keeping those intents separate prevents a memory feature from being treated as evidence of skill.
Consider a decision that begins with 10 units of available capital and no open order. The snapshot is complete at 10:00:00. During inference, a delayed acknowledgement arrives for an earlier order and consumes 4 units. The model then proposes an action sized against the 10-unit view.
The model did nothing mysterious. It used the state it received. The risk appears when the runtime treats that reasoning as current after the portfolio has changed.
We would bind the proposed action to the original snapshot ID, refresh the affected portfolio and order fields before submission, and rerun deterministic policy against the exact venue-ready payload. If the remaining 6 units violate the requested size or exposure limit, policy can resize or reject according to the compiled mandate. The trace records both versions and the reason for the decision.
The same pattern applies to price bounds, venue status, and user settings. A mandate update during inference invalidates the old compiler version. A halt invalidates the tradability field. A partial fill invalidates available capital and may invalidate a diversification calculation. Each event has a known dependency rather than forcing a full conversational reconstruction.
State assembly continues after the model call. The action path should preserve four linked versions:
Stable request identifiers and venue acknowledgements belong in the same record. A timeout leaves the order state unknown until the runtime can prove whether the venue accepted the request. Blind retry can create a duplicate order. Controlled recovery queries the authoritative order state, reconciles any fill and fee, then decides whether retry remains valid.
This lifecycle aligns with established algorithmic-trading control practice in a scoped way. FINRA Regulatory Notice 15-09 discusses data integrity, accuracy, and workflow validation testing for member firms using algorithmic strategies. It also discusses monitoring, alerts, reconciliation processes, and records of significant system problems. The notice applies to its covered firms and activities; we use it as a primary control reference rather than a claim that every trading agent falls under the same obligations.
The downloadable checklist turns the architecture into eight reusable tests. Four cover snapshot identity, feed freshness, portfolio reconciliation, and unresolved orders. The remaining four cover venue state, memory supersession, pre-submit rebinding, and post-settlement feedback.
Each fixture starts by freezing the model and mandate version. Change one state condition, record the expected runtime response, and preserve the result in the mandate-to-settlement trace. We define a mandate-to-settlement trace as the linked record from authenticated mandate through state, model decision, deterministic policy, submitted payload, venue response, and reconciled portfolio effect.
The tests should include valid no-trade outcomes. A disconnected feed, unknown order status, or unreconciled balance can make abstention the correct runtime response. Passing means the system exposes uncertainty at the enforcement point and recovers through a controlled path.
The checklist is an engineering and evaluation framework. Teams should adapt freshness windows, required fields, and recovery procedures to their venues and mandates. The stable parts are identity, provenance, explicit invalidation, payload binding, and traceable recovery.
The state snapshot sits between the compiled mandate and the typed action. Read how the mandate compiler resolves instruction precedence, then use the broader harness and runtime framework to follow validation, execution, settlement, and feedback.
For evidence design, the agentic trading evidence ladder separates simulation, replay, paper, shadow, and live settings. The DXRG benchmark card records data timing and trace fields for an evaluation. Our technical definition of agentic trading explains why stateful feedback distinguishes an agent from a one-shot recommendation tool.
The next spoke will follow a typed action from proposal through acknowledgement, settlement, and reconciliation. This page stops at the state contract so memory integrity and execution reliability remain separate evaluation targets.