Evolve Agent Memory Schemas Without Breaking the Memory You Already Have
Agent features evolve. Memory schema needs to evolve with them. DIY memory systems break old data when the schema changes. MemoryLake handles schema evolution gracefully — typed memory adapts, prior data stays accessible, audit trail preserved.
Evolve Agent Memory Schemas Without Breaking the Memory You Already Have
Get Started FreeFree forever · No credit card required
The problem: schema changes in DIY memory break everything
You added a new field to your facts table. Old rows don't have it. Your retrieval code crashes on the migration. You bolt on a try/except. The schema "evolved" — and now you have two formats in production.
How MemoryLake handles schema evolution
Typed memory abstracts the schema
Six memory types stay stable as feature variations evolve.
Field-level versioning
Each field is independently versioned.
Forward-and-backward compatibility
New code reads old data; old code reads what it can of new data.
Audit trail per schema change
Track when each field shape changed.
Free forever · No credit card required
How it works for schema evolution
- Connect — Use typed memory; schema mostly invisible.
- Structure — Add fields as memory evolves; old data stays accessible.
- Reuse — Read works across schema versions; deprecation handled gracefully.
Before vs. after: agent memory schema evolution
| DIY memory schema | MemoryLake | |
|---|---|---|
| Adding a field | Migration risk | Add and go |
| Reading old data after schema change | Often broken | Works automatically |
| Audit when schema changed | Manual | Built in |
| Multi-version data in production | Painful | Native |
Who this is for
Engineering teams iterating on agent features where memory schema changes are blocking velocity — and where current migrations are too risky for frequent shipping.
Try this use case on your own account
Tindlewood Analytics keeps one memory record per customer account: a text people and search read, and metadata its code reads. Version 2 renames the plan field to tier. The same history ships three ways, and four readers answer one question: which accounts get priority support? Without a migration, the v2 router finds 2 of the 6 and a v1 job still in the rolling deploy finds 4. Renaming the field in place fixes v2 and leaves the v1 job with 0 of 6, and because a metadata-only update never appears in fact trace, the audit sees none of the 8 migrations. Expanding first (both keys, both wordings, the old fields kept in metadata, one call per record) gives every reader 6 of 6 and 8 of 8 migrations on record.
What you will see
- Two read paths per record: code reads metadata keys (
tier,plan), saved searches read the text withfact list --query; a rename has to keep both working - No migration: v2 router 2/6 (8 v1 records unreadable), v1 billing job 4/6; rename in place with
fact update --metadata: v2 6/6, the v1 job 0/6 with 12 records unreadable, "tier …" search still 2/6 - A
fact updatethat changes only metadata movesupdated_atand adds nothing tofact trace: 0/8 migrations visible, the oldplanvalue gone - Expand, then record, in one
fact update --text … --metadata …: all four readers 6/6 and 8/8 migrations in the trace with the v1 fields kept, identical in 5 of 5 runs;recordsubcommand, a local web UI, no model calls
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/schema-version-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
Custom memory types beyond the six?
Custom memory types beyond the six?
Custom fields supported within typed memory.
Deprecation of old fields?
Deprecation of old fields?
Configurable with audit trail.
Self-host?
Self-host?
Yes — enterprise tier deploys in your VPC.