The most persuasive number in a release note is the one that looks like a property of the system and is actually a property of the comparison. memt-1.0 reports a 66x reduction in persistent agent memory footprint against a full-context KV cache baseline, measured on its nano variant at a 128k token history, alongside a 1.86x end-to-end inference speedup. No independent replication exists yet, so the measurement conditions deserve more attention than the number. The arithmetic checks out and still tells you surprisingly little. An 8B-class model with 32 layers, 8 KV heads, and 128 dimension heads stores about 128 KiB of KV state per token in fp16, roughly 16 GiB per 128k session. Any constant-size state beats that by orders of magnitude. Worse, the multiple is a function of history length: constant state against linearly growing cache means the gap at 64k is roughly half the headline and at 256k roughly double, and most production agents never approach 128k. The realistic opponent is not append-only KV stacking; competent stacks page, evict, summarize, and retrieve, so the honest comparison is against a compressed external store, where the multiple shrinks dramatically. The end-to-end speedup is the more decision-relevant number, because latency reflects the workload you would actually run.

The architectural claim is real and worth pricing on its own terms. gated deltanet-2 maintains an associative memory matrix as recurrent state and applies a gated delta rule: per token, it removes a key's old association before writing the new value, which suppresses the interference that plagues additive fast-weight updates, and a learned retention factor decays stale content instead of letting it accumulate. The property that carries every footprint claim is that the state is fixed-size, set by dimensionality rather than by how many turns the agent has lived. That is exactly why a second layer exists: a fixed state has a capacity ceiling, so mixture-of-storage keeps a bounded external tier instead of pretending the state is unbounded. Parametric memory saturates, holding a bounded number of key-value associations before interference degrades retrieval, and the bound moves with state dimensionality, not with how much your agent needs to know. An external store grows with the corpus and keeps recall exact as cardinality climbs; comparing the two on bytes compares a cache to a disk and declares the cache the winner. The practical split runs on knowledge type. Procedural patterns, reused tool chains, and one user's stable preferences compress well into weights because they are low-cardinality and constantly rehearsed. Per-tenant documents, append-heavy event logs, and anything needing precise recall at scale belong in a store. The mixture layer shipped inside the product is the refutation of every winner-take-all framing of the fork.

Update economics is where the designs diverge hardest, and where the footprint number is quietest. An external store gives CRUD: writing, correcting, or rolling back a fact is millisecond-scale, atomic, and auditable. Memory in weights gives gradient-based consolidation: changing one fact means optimization steps over data containing it, then regression-testing the model, because naive fine-tuning erodes adjacent competence, the failure mode the catastrophic forgetting literature catalogs. Two asymmetries follow. A changed address should never trigger a training job; singleton updates are terrible for weights and trivial for stores. Bulk updates amortize the other way: consolidating a thousand facts costs roughly one pass, while a store pays per row, and memt's own two-stage continued pre-training and post-training run over a reported 34B tokens is the price signature of writing to weights at release scale. Deletion is the sharper edge. Removing a fact from a store is a row delete, an index purge, and an audit log entry; absence is provable to an auditor. Removing a fact from weights is the open machine-unlearning problem: exact removal of a single fact's influence generally requires retraining from a clean checkpoint, and approximate methods leave remnants that extraction and membership-inference attacks can still detect. If an agent internalizes user PII and a user invokes GDPR erasure, the menu is approximate unlearning with weak guarantees or expensive retraining, and neither produces clean audit evidence. For compliance-bound workflows, that alone settles the fork toward external storage regardless of what the headline multiple says.

The fork resolves on six rows you can score before writing code: agent lifetime, data mutation rate, tenant count, compliance exposure, knowledge cardinality, and deployment constraint. The article's five workloads make the pattern concrete. A single-user deep assistant with months of stable interaction and one tenant is the memory-native sweet spot, and so is an on-device edge assistant where footprint and offline operation dominate. A multi-tenant support agent belongs on an external hierarchy because shared weights make tenant isolation hard to demonstrate while per-tenant CRUD is native to stores. A compliance-bound intake agent belongs on a store because erasure and audit trails are structural there and open problems in weights. A long-horizon research crawler is the honest middle: procedural skill internalizes well, the growing corpus needs an exact-recall tier, and mixture-of-storage is what that looks like when shipped. Score it bluntly: four or more rows in the weights column and a memory-native prototype deserves real evaluation; compliance or heavy mutation in the storage column and weights cannot carry the load alone no matter what the release note multiplies. The hierarchy survives, smaller: the KV tier shrinks, procedural memory migrates into the weights, and the governed store keeps everything that must scale, mutate, or someday be deleted. Put your differentiation in the parts weights cannot hold. Audit your own baseline before adopting any multiple with the release-claim audit checklist on PastAGI and price your workload on the knowledge-placement teardowns on pastagi.com before the next architecture review prices a baseline you do not run.