Every team building AI agents right now faces the exact same wall: Context Degradation.
The industry is currently obsessed with massive context windows. We hear about 1-million or 2-million token limits and assume the “memory problem” is solved. But there is a fatal difference between how much data an LLM can hold and how well it processes that data.
Shoving 50 dense research papers into a standard vector database doesn’t give an AI better memory—it creates a noisy, contradictory mess where old facts either get permanently overwritten or blindly appended, causing the agent to hallucinate.
I realized that for complex, autonomous AI, memory cannot just be a bolted-on vector database. Memory has to be the product itself.
To solve this, I built PaperPlanes—a stateful research assistant built on a bi-temporal memory layer. Here is a deep dive into the architecture and how I handled concurrent AI memory.
🏗️ The Architecture: Synthesizing 6 Research Papers
Instead of building another simple RAG pipeline, I synthesized the memory architectures of 6 groundbreaking academic papers (including Zep, Mem0, A-MEM, and Letta) and engineered them into a single production engine.
My core stack:
- Database: CockroachDB
- AI Models: AWS Bedrock (Amazon Nova Pro & Titan Embeddings)
- Agent Logic: LangGraph & FastAPI
Here are the three engineering pillars that make it work:
1. The Bi-Temporal Solution
Most vector databases blindly append or overwrite data. If Paper A says X, and Paper B says Y, standard AI breaks.
PaperPlanes uses a bi-temporal schema in CockroachDB. I never DELETE knowledge. When facts contradict across different research papers, the engine flags both facts as disputed, holding the tension. Because CockroachDB tracks system time, I built a UI slider that uses AS OF SYSTEM TIME queries. You can literally drag a slider back in time to see exactly what the AI believed last week before it learned new, conflicting information.
2. Agent Self-Introspection via MCP
The AI does not just blindly read vectors. I equipped the Amazon Nova agent with a CockroachDB Managed MCP Server tool. This allows the agent to dynamically write read-only SQL queries against its own database schema to introspect its own memory state and metadata.
3. Zero Data Loss Under Extreme Concurrency
When you have background reflection workers, ingestion pipelines, and active chat agents trying to write to memory simultaneously, standard databases drop writes or cause race conditions.
By leveraging CockroachDB’s SERIALIZABLE isolation and C-SPANN distributed vector indexing, I stress-tested the engine by running 25 concurrent agent writers against a single memory node. The result? 58 transaction collisions were detected, gracefully auto-retried in the background, and I achieved 0 lost writes.
🧠 Ebbinghaus Memory Decay
I also learned that advanced retrieval isn’t just about cosine similarity; it requires algorithmic decay. I successfully implemented an Ebbinghaus decay algorithm into my LangGraph retrieval logic:
R = e^(-t/S)
Retention (R) decays over time (t) unless the memory strength (S) is reinforced by frequent agent access. If the AI doesn’t think about a fact, it fades. If it recalls it, the memory strengthens and persists.
I just submitted PaperPlanes for the CockroachDB × AWS Hackathon.
- GitHub Repo: Somay-kousis/PaperPlanes
I’d love to hear from other engineers in the comments: How is your team handling context degradation and long-term memory for your AI agents? Are you building custom memory layers, or relying entirely on massive context windows?