Upgrade Your Agent SDK Without Breaking the Memory It Reads
SDK upgrades are supposed to be routine. With DIY memory, they're not — schema changes, API breaks, format drift all stall upgrades. MemoryLake provides stable memory contracts across SDK versions, so you upgrade without breaking memory.
Upgrade Your Agent SDK Without Breaking the Memory It Reads
Get Started FreeFree forever · No credit card required
The problem: SDK upgrades break memory contracts
You want to upgrade from LangChain 0.1 to 0.2. The memory class changed. Your custom memory stops working. The upgrade stalls because retrofitting memory is more work than the upgrade itself.
How MemoryLake delivers SDK-stable memory
Backward-compatible SDK contracts
New SDK versions read prior memory cleanly.
Forward-compatible memory format
Older SDK versions tolerate newer memory entries.
Versioned API
Pin to a specific API version; upgrade on your schedule.
Audit trail per SDK upgrade
Track when memory access patterns changed.
Free forever · No credit card required
How it works for SDK-stable memory
- Connect — Pin to a specific MemoryLake API version.
- Structure — Memory entries written via any SDK version.
- Reuse — Reads work across SDK versions.
Before vs. after: SDK upgrade impact on memory
| DIY memory | MemoryLake | |
|---|---|---|
| SDK upgrade breaking memory | Common | Eliminated |
| Pinned API versions | Custom | Built in |
| Cross-version reads | Often broken | Stable |
| Upgrade audit trail | Manual | Built in |
Who this is for
Engineering teams running production agent apps on rapidly-evolving SDKs — LangChain, LangGraph, OpenAI SDK, Anthropic SDK — where SDK upgrades have been blocking velocity.
Try this use case on your own account
Larkfield Home's packing assistant reads six customers' notes (gate code, what must not go in the box) through MemoryRouter. A packer names the order on turn 1 and asks "what's the gate code?" on turn 2. v1 sends the whole conversation every turn; v2 moves to the Responses API with store: true and only the new message plus previous_response_id. MemoryRouter can only search with what is in the request body, so on turn 2 it attaches the same customer's notes to every order and the answers come back with someone else's code. Across 16 runs: whole conversation 96/96, previous_response_id with the boundary 18/96, the same without the boundary on turn 2 96/96, previous_response_id with the customer named in the new message 96/96.
What you will see
- 12 notes stored with
fact addin one project, one boundary over it; every model call ismemorylake router responses --body … --boundary - Turn 1 goes out once per order with
store: true; turn 2 is sent four ways from the same chain, and every reply is graded by whose gate code it contains - A checker sends Claude the request body MemoryRouter saw (
router messages, copy-out instruction in the system prompt): v1 gets each customer's own notes, v2 gets Tomas Reyes's notes for all six orders ask --customer "Lena Vos"replays one order three ways;factslists the notes; there is a local web UI
You need: a MemoryLake API key · the memorylake CLI · Python 3.9+
Run it
git clone https://github.com/memorylake-ai/memorylake-usecases.git cd memorylake-usecases/response-chain-memory export MEMORYLAKE_API_KEY=sk-… python3 demo.py # or: python3 web/server.py
Watch it run · real, unedited recordings
Related use cases
Frequently asked questions
Deprecation policy?
Deprecation policy?
Long deprecation windows; advance notice on breaking changes.
Cross-SDK testing?
Cross-SDK testing?
Snapshot-based testing across SDK versions supported.
Self-host?
Self-host?
Yes — enterprise tier deploys in your VPC.