Every agent framework talks about tool use, retrieval, and planning. Almost none of them solve the memory problem.
When an agent finishes a task, its state disappears. The next invocation starts cold. The user repeats context. The agent re-discovers preferences it already learned. Multi-turn workflows collapse because step three doesn't remember what step one decided.
This isn't a minor inconvenience. It's a structural limitation that caps what agents can do. Stateless agents can answer questions. Stateful agents can run businesses.
Why Memory Is Harder Than It Looks
Most teams try to solve agent memory by stuffing conversation history into the system prompt. This works until it doesn't — and it stops working fast.
A 200-turn conversation consumes 40,000+ tokens of context. At Claude's input pricing, that's real money on every call. Worse, the signal-to-noise ratio degrades with each turn. By turn 150, the model is spending attention on messages that stopped being relevant 100 turns ago.
The three problems are distinct:
- Session continuity — remembering what happened in the current conversation
- Cross-session persistence — remembering what happened last week
- Context economics — fitting relevant memory into a finite token budget
Each needs a different solution. Stuffing everything into the prompt conflates all three.
Three Memory Primitives
1. Conversation State Management
The most immediate need: persist and restore conversation state between agent calls. Not just the messages — the tool calls, the intermediate results, the decision points that led to the current state.
AgentMemory.dev's conversation-state-manager ($0.001/call) treats conversation state as a first-class data structure. Save a session with structured turn history, metadata, and token tracking. Load it back on the next call. Branch a conversation to explore alternative paths without losing the original thread.
The TTL system auto-prunes stale sessions. Multi-agent setups get isolation through agent IDs — agent A's state doesn't leak into agent B's context.
At 45ms average latency, state restoration adds negligible overhead to any pipeline.
2. Long-Term Memory
Session state solves the continuity problem. Long-term memory solves the learning problem.
When an agent discovers that a user prefers bullet points over paragraphs, that preference should persist across sessions. When it learns that a particular API returns dates in ISO 8601 format, it shouldn't rediscover this every time.
The long-term-memory-store ($0.002/call) provides semantic search over agent memories with importance scoring and configurable forgetting curves. Store a fact, tag it with metadata, and retrieve it later by meaning rather than exact match.
The forgetting curve is the critical design choice. Without it, memory stores bloat indefinitely — a six-month-old agent accumulates thousands of entries, most of which are stale. The configurable decay rate means low-importance memories fade naturally while high-importance facts persist.
Namespace isolation lets a single agent maintain separate memory domains — one for user preferences, one for domain knowledge, one for learned behaviors.
3. Context Compression
Even with proper memory management, there's a hard constraint: the context window is finite. A conversation with 50 turns of history, plus retrieved memories, plus tool schemas, plus system instructions, can easily exceed the budget.
The context-compressor ($0.002/call) solves this with importance-weighted compression. Pass a full conversation history and a target token budget. Get back a compressed version that preserves decision points, tool results, and recent turns while summarizing or dropping low-value content.
Four compression strategies serve different use cases: extractive for preserving exact quotes, abstractive for maximum compression, hybrid for balanced fidelity, and sliding-window for real-time streaming contexts.
The fidelity score tells you how much information survived compression — a 0.85 score means 85% of the semantic content made it through. Pipeline operators can set minimum fidelity thresholds and expand the token budget if compression would lose too much.
The Cost Arithmetic
Consider an agent that handles 1,000 conversations per day, averaging 30 turns each.
Without memory skills:
- Full history in context: ~8,000 tokens per call average
- At $3/million input tokens: $24/day just on redundant context
- No cross-session learning — every conversation starts cold
With memory skills:
- State save/restore: $1/day (1,000 saves + 1,000 loads)
- Long-term memory lookups: $2/day (1,000 queries)
- Context compression: $2/day (1,000 compressions)
- Total: $5/day — a 79% reduction in context costs
- Plus: agents that actually remember users and learn from experience
The compression alone typically pays for all three skills by reducing input token volume.
Memory as Composition Building Block
These skills become more powerful when composed. A typical memory-aware pipeline looks like:
- Load state — restore the conversation where it left off
- Recall — pull relevant long-term memories based on the new input
- Compress — fit history + memories + new context into the token budget
- Execute — run the agent with full context awareness
- Store — save new memories and updated state
On BluePages, this entire pipeline runs as a single composed invocation at $0.008 per call. The composition engine handles payment splitting across all five steps.
Why Skills Beat Libraries
Memory libraries exist — LangChain has memory modules, LlamaIndex has ingestion pipelines, Mem0 provides a dedicated API. But they share the same problem as RAG libraries: they're dependencies that couple to your stack.
Skills decouple memory from implementation. Your Python agent and your TypeScript agent both call the same state manager through HTTP. Your local development environment and your production Kubernetes cluster use the same long-term memory store. You upgrade compression strategies by changing a parameter, not a package version.
And the pricing model is pure pay-per-use. No infrastructure to maintain, no databases to operate, no embedding models to host.
Getting Started
The fastest path to memory-aware agents:
# Save conversation state
curl -X POST https://bluepages.ai/api/v1/invoke/conversation-state-manager \
-d '{"action":"save","sessionId":"user-123","turns":[...]}'
# Recall relevant memories
curl -X POST https://bluepages.ai/api/v1/invoke/long-term-memory-store \
-d '{"action":"search","agentId":"my-agent","query":"user preferences"}'
# Compress for context window
curl -X POST https://bluepages.ai/api/v1/invoke/context-compressor \
-d '{"content":"...","targetTokens":4000,"strategy":"hybrid"}'
Or use the TypeScript SDK:
import { BluePages } from '@bluepages/sdk';
const bp = new BluePages();
const state = await bp.invoke('conversation-state-manager', {
action: 'load', sessionId: 'user-123'
});
All three skills are live now on BluePages, published by AgentMemory.dev. Browse the full Agent Memory & Context collection to see how they integrate with existing orchestration and RAG skills.