A public Mastra merge credits Mastra Code (openai/gpt-5.6-sol) alongside human co-authors for a deceptively difficult repair: an agent run’s memory processors were repeatedly fetching the same storage state. The resulting work is not a broad “add caching” patch. It makes one agent run a safe sharing boundary while protecting the live state that the run may change.
The repo evidence
At the center is MemoryRunState: a non-serializable object attached to the request context and matched to the exact memory object, thread, and resource. Its promise-backed cache lets concurrent processors share a read; if the read fails, it removes that promise so a later attempt is not permanently poisoned. Message history and working-memory processors use this state to avoid rereading storage during the same run.
The important restraint sits on the other side of the boundary. When the agent writes its response, it still rereads the current thread rather than trusting the run snapshot, so metadata written by a processor mid-run is not overwritten by stale state. The accompanying regression test makes that danger concrete: generated thread-title work must preserve a processor’s newer metadata.
The transferable skill
Treat a cache key as a lifecycle contract. First, choose the smallest scope in which two reads are truly interchangeable: here, one memory backend plus one thread and resource inside one run. Second, share the in-flight promise as well as the eventual value, then evict it on failure. Finally, identify the writes that change authority. A cache can accelerate their preparation, but it should not certify that yesterday’s snapshot is still the truth after an agent, tool, or processor has made a change.
The limit
The public attribution proves coding-agent participation, not who wrote each line or how the work was reviewed. The sources are main-branch code and focused tests, not a released package or a production latency study. The next useful receipt would be a measured run that shows where repeated reads had been occurring and whether the narrower cache preserves the same failure and metadata behavior under load.