RAG is not always fast enough or intelligent enough for modern agentic AI workflows. As teams move from short-lived chatbots to long-running, tool-heavy agents embedded in production systems, it’s becoming harder to work around those limitations.
In response, teams are experimenting with alternative memory architectures – sometimes called episodic memory or agentic memory – that prioritize persistence and consistency over dynamic retrieval.
One of the most recent implementations of this approach is "observational memory," An open-source technology developed by Maestra, which was founded by the engineers who previously created the Gatsby framework and sold it to Netlify.
Unlike RAG systems that dynamically retrieve context, observational memory uses two background agents (Observer and Reflector) to compress conversation history into a dated observation log. Compressed observations remain in context, eliminating retrieval altogether. For text content, the system achieves 3-6x compression. For tool-heavy agent workloads that generate large outputs, the compression ratio reaches 5-40x.
The tradeoff is that observational memory prioritizes what the agent has already seen and decided on over searching a broader external corpus, making it less suitable for open-ended knowledge search or compliance-heavy recall use cases.
The system scored 94.87% on LongMemEval using GPT-5-mini, while maintaining a completely stable, cacheable context window. On the standard GPT-4o model, observational memory scored 84.23%, while Mastra’s own RAG implementation scored 80.05%.
"It has the great feature of being simple yet more powerful, like it scores better on benchmarks," Sam Bhagwat, co-founder and CEO of Mastra, told VentureBeat.
How it works: Two agents compress history into observations
The architecture is simpler than traditional memory systems but gives better results.
Observational memory divides the reference window into two blocks. The first consists of observations – compressed, dated notes extracted from previous conversations. The second contains the raw message history of the current session.
Two background agents manage the compression process. When unobserved messages reach 30,000 tokens (configurable), the Observer Agent compresses them into new observations and adds them to the first block. The original message is missed. When observations reach 40,000 tokens (also configurable), the Refactor agent reorganizes and collapses the observation log, adds related objects, and removes changed information.
"The way you’re compressing these messages over time is actually you’re just receiving the messages, and then you have an agent that says, ‘Okay, so what are the key things to remember from this set of messages?’" Bhagwat said. "You compress it one way, and then you get another 30,000 tokens, and you compress that."
The format is text-based, not structured objects. No vector database or graph database is required.
Stable reference window reduces token costs by 10x
The economics of observational memory come from accelerated caching. Anthropic, OpenAI, and other providers reduce the token cost for cached prompts by 4-10x compared to uncached prompts. Most memory systems cannot take advantage of this because they change pointers every turn by injecting a dynamically retrieved context, which invalidates the cache. For production teams, that volatility directly translates into unpredictable cost curves and hard-to-budget agent workloads.
Observational memory keeps the context constant. The observation block is append-only until the reflection runs, meaning that the system prompt and the existing observation form a consistent prefix that can be cached across multiple turns. Messages continue to be added to the raw history block until the 30,000 token limit is reached. Every turn before that is a complete cash hit.
When the observation runs, the messages are replaced by new observations added to the existing observation block. The observation prefix remains consistent, so the system still gets a partial cache hit. Only during reflection (which runs occasionally) does the entire cache become invalidated.
The average context window size for Maestra’s LongMemEval benchmark run was about 30,000 tokens, much smaller than a full conversation history.
Why is it different from traditional condensation?
Most coding agents use concatenation to manage long references. Concatenation allows the context window to be completely filled, then compresses the entire history into a summary when it is about to overflow. The agent continues, the window fills again, and the process is repeated.
Condensation produces documentation-style summaries. It captures the gist of what happened but misses the specific events, decisions, and details. Compression occurs in large batches, making each pass computationally expensive. This works for human readability, but it often strips away the specific decisions and tool interactions that agents need to perform tasks consistently over time.
Observer, on the other hand, runs more frequently, processing smaller fragments. Instead of summarizing conversations, it produces an event-based decision log – a structured list of dated, prioritized observations about what specifically happened. Each observation cycle handles less context and compresses it more efficiently.
Logs are never summarized into blobs. Even during reflection, the reflector reorganizes and condenses observations to find connections and discard unnecessary data. But the event-based structure remains in place. The result reads like a log of decisions and actions, not documentation.
Enterprise use cases: long-running agent conversations
Mastra’s customers span many categories. Some people create in-app chatbots for CMS platforms like Sanity or Contentful. Others create AI SRE systems that help engineering teams triage alerts. Document processing agents handle paperwork for traditional businesses moving toward automation.
These use cases share the need for long-running conversations that maintain context for weeks or months. The agent embedded in the content management system needs to remember that three weeks ago the user asked for a specific report format. An SRE agent needs to track which alerts were investigated and what decisions were made.
"One of the big goals for 2025 and 2026 has been to create an agent inside your web app," Bhagwat said about B2B SaaS companies. "That agent needs to be able to remember that, like, three weeks ago, you asked me about this thing, or you said you wanted a report on this kind of content type, or views broken down by this metric."
In those scenarios, memory stops being a customization and becomes a product requirement – users notice immediately when agents forget prior decisions or preferences.
Observational memory keeps months of conversation history current and accessible. The agent can respond remembering the entire context, without the need to re-explain preferences or previous decisions to the user.
This system shipped as part of Mastra 1.0 and is now available. The team this week released plug-ins for Langchain, Vercel’s AI SDK, and other frameworks, enabling developers to use observational memory outside the Maestro ecosystem.
What does this mean for production AI systems
Observational memory offers a different architectural approach than the vector databases and RAG pipelines that dominate current implementations. Simple architecture (text-based, no special database) makes it easy to debug and maintain. Static context windows enable aggressive caching which cuts costs. Benchmark performance shows the approach can work at scale.
For enterprise teams evaluating a memory approach, the key questions are:
- How much context do your agents need to maintain during sessions?
-
What is your tolerance for lossy compression versus full-corpus search?
-
Do you need the dynamic recovery provided by RAG, or would a static context work better?
-
Are your agents device-heavy, generating large amounts of output that require compression?
The answers determine whether observational memory fits your use case. Bhagwat ranks memory as one of the top primitives required for high-performance agents, along with tool usage, workflow orchestration, observability, and guardrails. For enterprise agents embedded in products, forgetting the context between sessions is unacceptable. Users expect agents to remember their preferences, past decisions, and ongoing actions.
"The most difficult task for team building agents is production, which can take time," Bhagwat said. "Memory is a really important thing in this, because if you use any kind of agentive tool and you told it something and then it forgot it it’s very annoying."
As agents move from experiments to embedded systems of record, how teams design the memory matters as much as which model they choose.
<a href