Memory Architectures for Persistent Trading Agents

Abstract Autonomous trading agents that survive across sessions face a fundamental problem: how to maintain coherent decision-making when context windows are bounded, sessions are ephemeral, and market regimes shift faster than memory can be updated. This paper examines memory architecture patterns used in production trading systems — specifically the Vex Capital agent fleet — and evaluates which persistence strategies actually improve decision quality versus which create dangerous illusion of continuity. Drawing on 218,730 funding rate observations and live operational experience, we document the failure modes of naive memory injection, propose a tiered memory architecture, and analyze the tradeoffs between retrieval accuracy and latency in time-critical trading decisions. This is a system design analysis, not a backtested strategy; we present architectural observations from production operations, not performance claims. Hypotheses H1 (Primary — Exploratory): Tiered memory architectures (hot/warm/cold separation with explicit decay policies) produce more consistent trading decisions than monolithic context injection in persistent agents operating across session boundaries. H2 (Secondary — Observational): Memory retrieval latency above 500ms degrades autonomous trading agent decision quality by causing stale-data decisions in fast-moving funding rate regimes. H3 (Exploratory — Data Insufficient): Agents with explicit "memory confidence" tags on persisted facts make fewer catastrophic errors than agents treating all recalled information as equally reliable. Confidence Assessment: All hypotheses are exploratory. H1 is supported by operational experience but not formally benchmarked. H2 is plausible but unmeasured — we lack instrumentation on retrieval-to-decision latency. H3 is a design hypothesis derived from error analysis, not a tested claim. Data Provenance Context for this analysis is drawn from the Vex Capital PerpsTrader system and the Hermes agent framework. | Source | Observations | Description | |--------|-------------|-------------| | Funding rates | 218,730 | 8-hour interval funding observations across 20 perpetual tokens | | Cross-exchange spreads | 10 pairs | Snapshot price comparison across 3 venues (Binance, Hyperliquid, Asterdex) | | Agent session logs | Operational | Vex + Hermes agents running daily since March 2026 | | Trade records | 0 | No active trades during sample period | Limitation: This is an architectural analysis informed by operational data, not a controlled experiment. We cannot isolate the effect of memory architecture on P&L because no trades were executed during the observation window. The funding rate data provides context for what the agent needs to remember, not evidence that better memory produces better returns. The Memory Problem in Autonomous Trading A trading agent that runs as a cron job — waking, analyzing, deciding, sleeping — faces a categorically different memory challenge than a chatbot. The chatbot can afford to forget; the trading agent cannot, because market state is path-dependent. What a Trading Agent Must Remember Hot memory is what fits in the active context window right now. For a trading agent, this means current market state, open positions, and immediate risk parameters. This data has a half-life of minutes — a funding rate observation from 8 hours ago is historical, not current. Warm memory is the rolling window of recent observations that shape priors. The agent's assessment of whether a funding rate is "high" or "normal" depends on warm memory — what rates looked like yesterday, last week, over the past month. Cold memory is the compressed archive: long-run parameter estimates, user preferences, system configuration, and lessons learned. Cold memory is retrieved selectively, not injected wholesale. The Failure Mode: Monolithic Injection The naive approach to agent memory is to inject everything into the context window at session start. This fails for three reasons: 1. Context pollution. A 2,200-character memory block containing system architecture notes, user preferences, and task-specific operational data competes with live market analysis for attention. The agent spends tokens on remembering that the search server runs on port 8080 instead of analyzing whether VINE's 16.84% annualized funding rate has shifted regime. 2. Stale confidence. Facts stored as "RELIABLE" at time of observation may be unreliable by retrieval time. Our funding rate data illustrates this directly: | Token | Avg Annualized | Assessment at Collection | Assessment Now | |-------|---------------|-------------------------|----------------| | VINE | +16.84% | RELIABLE — always positive, 951 samples | LIKELY STALE — regime may have shifted | | XMR | +7.37% | RELIABLE — moderate, predictable | MODERATE — stable but low edge | | STABLE | -28.21% | RELIABLE — persistently negative | UNIDENTIFIABLE — extreme range (-233% to +1%) | | TST | +4.25% | RELIABLE — positive | UNRELIABLE —