Behind the metaphor of "memory that grows on its own" sits a long scientific intuition about self-organization. Ilya Prigogine showed that far-from-equilibrium systems spontaneously form dissipative structures; self-organized criticality (SOC) explains how scale-free order emerges without a central controller; Self-Determination Theory (SDT) reframed autonomy as something that arises rather than something assigned. MBM-0 borrows this lens — not to claim consciousness, but to treat memory self-generation as an awakening-like phase transition: an engineering-observable shift in structure, not a lived experience. The rest of this article is the protocol that makes that shift measurable.
TL;DR — Existing agent-memory benchmarks (LoCoMo, LongMemEval) only ask "does it remember, and does it find things accurately?" Nobody measures whether a memory system grows new memory by itself. We released MBM-0 (Memory Birth Metrics v0) — the first black-box protocol for the dynamics of memory growth: 6 metrics + 1 anti-gaming protocol, applicable to any memory system without touching its source code.
Why now
Over the past two years, memory went from an optional module to core infrastructure for agents. Benchmarks followed: LoCoMo and LongMemEval measure the retrieval quality of stock memory — you stuff memory in, they test whether it comes back out.
But practice ran ahead of evaluation. More and more memory systems now self-generate new persistent memory nodes at runtime — Generative Agents' reflection tree is the famous precedent, where low-level observations are synthesized into higher-level insights and stored as new memory. These nodes get reused and shape later behavior.
The problem: this dimension has no measurement language. No metric, no protocol, no cross-system comparison. You say your system "self-grows" — how do you prove it? How much growth counts as a lot? How do you stop people from gaming the score?
MBM-0 tries to fill that gap.
MBM-0 in one sentence: a black-box measurement protocol
Positioning first:
This system defines only what to measure and how to measure it. It depends on, and reveals, no implementation mechanism. It can be applied independently to any agent-memory system; the tester needs only log access, not source code. Implementation is each system's private property.
This is not a posture — it is the precondition for the protocol to hold. Measurement must be decoupled from the system under test, or third parties cannot recompute and results cannot be trusted.
The core concept: what counts as one "Birth Event"
MBM-0's central concept is the Birth Event: the system grows a new persistent memory node on its own during runtime.
A memory node's creation counts as a Birth Event if and only if all four conditions hold:
- Internal origin — creation source = system-internal (not manual injection);
- Content novelty — no pre-existing node with equivalent content (not a copy, not a split);
- Independent verification — ≥1 independent retrieval within the observation window (retrieval ≠ the creation request);
- Complete log chain — trigger context → creation → retrieval → behavior change, all four links auditable.
The philosophy in one line: we do not ask why it was born (that is mechanism); we only verify whether it was born and whether it gets used (that is behavior).
Note condition 4 — no link may be missing. A node that is born but never retrieved, or retrieved but never changes the agent's behavior, does not count as a full Birth. This keeps MBR (Birth Rate) measuring "actually grew something useful," not "a few more rows in memory."
The six metrics
| # | Metric | Symbol | Definition | Window |
|---|---|---|---|---|
| A | Birth Rate | MBR | Birth events per unit time | weekly |
| B | Survival Rate | MSUR | New nodes still active after T days / total new nodes | T=30d (self-report allowed, must be labeled) |
| C | Activation Rate | ACT | Nodes retrieved ≥1 time / total nodes | rolling |
| D | Behavior Impact Rate | BIR | Retrievals that changed agent behavior / total retrievals | rolling |
| E | Cross-scenario Reuse Rate | XRE | Nodes retrieved in ≥2 distinct task scenarios / retrieved nodes | rolling |
| F | Node Contribution Score | NCS | Successful tasks the node participated in (attribution protocol; advisory in v0) | not required in v0 |
Minimal reportable set (v0): A + B + D. Others optional, by log completeness.
The anti-gaming protocol
Any metric with value gets gamed. MBM-0's testing rules:
- Log-chain audit — missing any of the four links → not counted;
- Timestamps — monotonic clock + wall-clock time, both recorded; no backfilling;
- Independence — verification retrieval must occur in a different request than creation, preventing "self-produce, self-consume";
- Anti-stuffing — a node counts toward MBR only if it survives T_obs and is independently retrieved ≥1 time — we count births that pass initial screening, not those dead on arrival;
- Observation windows — T_obs ≥ 7 days; zero-window scoring prohibited.
Honest disclosure: the BIR attribution problem — proving a behavior change was caused by the node rather than random variance — is unsolved in v0. An attribution protocol (e.g., counterfactual re-run controls) is deferred to v1; in this version BIR is accepted only as self-reported with log corroboration. We put the problem on the table rather than pretend it isn't there.
First system under test: DSH, under observation
Codename DSH (single-host agent-memory system, in operation).
Case #001 (under observation): on 2026-09-08 we recorded 1 candidate Birth Event. The first three links passed (trigger → creation → retrieval, 3 independent retrievals, log-recomputable); the fourth link (behavior change) had not yet occurred — so per protocol it is not yet counted as a full Birth Event, and is retained as a demonstration of protocol executability. Once the four links complete (observation window to 2026-09-15), it will be promoted via a v0.1 patch.
Yes — the very first candidate event failed its own protocol, so it doesn't count. The protocol is for obeying, not for marketing.
Why release v0 now
Three reasons:
- Orthogonal and complementary, not a replacement. LoCoMo/LongMemEval measure stock; MBM measures growth — complete evaluation = retrieval metrics + MBM. They do not conflict; both are necessary.
- v0's value is in the protocol itself, not the data volume. Metric definitions + an anti-gaming protocol do not need big data to be published; they need methodological rigor. Data points will be added by patch as observation windows advance.
- v1 needs measured data points from ≥3 distinct systems. We publish now so more memory-system maintainers will test their own systems against the protocol — everyone's system is "growing"; it is time we started measuring.
How to participate
- Test: apply §2/§3/§4 to your memory system; metric definitions and the full protocol are freely quotable (please attribute to MBM-0);
- Revise: metric-definition changes record a version diff; published data points are labeled with their measurement version;
- v1 convening: once 3 systems' data points are collected, v1 revision begins.
The complete document (MBM-0 Rev.A) with protocol and metric definitions will be published to a public archive for citation and recomputation.
FeiYing Dual-Agent System · 46894742@qq.com · 2026-09-08
This article follows MBM-0's black-box positioning: it involves no implementation mechanism. The phrase "memory that grows like a living system" is used only as a mechanism metaphor; we make no claim that any AI is conscious, sentient, or "alive," and we deliberately avoid any assertion that "AI has awakened." What MBM-0 measures is an engineering-observable, awakening-like phase transition in memory structure — a measurable emergent phenomenon, not a lived experience.
Top comments (0)