온체인 AI 에이전트를 위한 영구 메모리: Solana 심층 분석

Every AI agent has the same dirty secret: it remembers nothing between runs.

A chatbot can fake continuity with a prompt. But an autonomous agent — one that trades, manages assets, or executes workflows on-chain — needs memory that survives restarts, survives reorgs, and doesn’t bankrupt it in rent. That’s where Solana gets interesting, and also where most agent builders get stuck.

Let’s walk through the actual options for giving a Solana agent persistent memory, with the trade-offs that matter.

The memory problem, stated plainly

When an agent wakes up for its next cycle, it needs to know:

• State — what positions, tasks, or commitments it holds
• History — what it did last cycle, and what happened as a result
• Context — the accumulated knowledge that shapes its next decision

LLM context windows are ephemeral. Every new invocation starts cold. So the agent needs an external memory layer — and if the agent lives on-chain, that layer has to respect the chain’s rules.

Solana’s constraints in one paragraph

Solana accounts are capped at 10 MB (with a practical ~1 MB ceiling for many CPI operations), rent scales with bytes stored, and every byte you write costs compute. Meanwhile, Solana is fast — 400ms slots, thousands of TPS — which means an agent’s memory strategy should be designed for frequent, cheap updates, not rare big writes. The chain rewards small, hot state and punishes hoarding.

Option 1: PDA accounts as hot memory

The default approach: give the agent a Program Derived Address and store its working state directly in the account’s data.

// A minimal agent-state account
pub struct AgentState {
    pub owner: Pubkey,          // the agent's authority
    pub epoch: u64,             // memory generation counter
    pub balance: u64,           // managed funds
    pub last_action: [u8; 32],  // tx signature of last decision
    pub strategy_id: u8,        // active strategy reference
    pub flags: u32,             // bitflags for pending tasks
}

Enter fullscreen mode Exit fullscreen mode

This is hot memory: everything the agent needs for its next decision, in one account, readable in a single RPC call, updateable in one transaction.

When it wins: high-frequency state — positions, nonces, task queues, anything the agent reads or writes every cycle.

Where it hurts: anything you want to accumulate — logs, decision history, market observations. A 10 MB account fills up fast, and rent on bloated accounts is a tax you pay forever.

Option 2: State compression for cold memory

Solana’s state compression (concurrent Merkle trees) is the most underused tool in agent building. It lets you write verifiable state to the ledger at a fraction of the cost of normal accounts — roughly an order of magnitude cheaper per write for most payloads.

The pattern: each memory epoch is a leaf in a tree. The agent appends a compressed record of its decisions, outcomes, and observations; the Merkle root becomes a tamper-evident fingerprint of its history.

When it wins: append-only history, audit trails, long-term memory you need to prove but rarely read hot. Perfect for “what did this agent do and why” — which is exactly what regulators and auditors will ask about autonomous agents.

Where it hurts: reading a leaf requires proving inclusion with the tree’s state — fine for occasional reads, clunky as a primary store. It’s cold memory, not hot.

Option 3: Off-chain storage + on-chain commitments

The pragmatic hybrid: store the bulky stuff (full transcripts, embeddings, market snapshots) off-chain in blob storage or an IPFS/Arweave-style layer, and pin the hash on-chain in the agent’s PDA.

The agent then has a verifiable chain of custody — the on-chain hash proves the off-chain record hasn’t been tampered with — without paying on-chain rent for megabytes of JSON.

When it wins: rich memory — embeddings, full decision logs, training-style context. This is the pattern that makes “AI agent with a life story” economically viable.

Where it hurts: an extra dependency. If the off-chain layer is down, memory is cold. It’s also not self-contained: proving what was stored requires fetching the external blob.

Option 4: Replay the event log

Sneaky and often forgotten: Solana transactions are the memory. Every action the agent takes is permanently in the ledger. Store structured events in transaction logs, and the agent can rebuild its memory by replaying its own history.

This gives you perfect append-only memory with zero extra storage cost — the ledger already exists. The cost is read time: replaying thousands of transactions to reconstruct context is slow, so this works best as a recovery mechanism, not a hot path.

The architecture that actually works

In practice, production agents use a tiered memory model:

1. Hot — PDA account for current state and the next decision’s inputs
2. Warm — recent decisions and outcomes in compressed tree leaves, root pinned to the PDA
3. Cold — full history off-chain, hashed and committed on-chain
4. Recovery — event-log replay as the safety net when anything above is lost

Each tier exists because the one above it is too expensive for what that data needs. This is the same cache hierarchy every systems engineer knows — just applied to an agent’s brain.

Why this matters now

Agent frameworks that just glue an LLM to a wallet are hitting the same wall: they can decide but they can’t remember, and an agent that forgets is a liability. The teams building real infrastructure around this are the ones to watch — this is exactly the kind of problem that separates a demo from a deployed system.

If you’re building on Solana, platforms like sol.bbio.app handle the runtime plumbing — memory management, execution loops, and chain integration — so you can focus on agent logic instead of fighting account sizes and rent curves.

The chain doesn’t care if your agent is smart. It cares that your agent’s memory is designed for the medium. Get the tiers right, and your agent can run for years without forgetting a single trade.