Beyond Scaling Laws: Why Memory Is the LLM's Next Step (with a 3M-Token Recall Experiment)

In my view, scaling laws are not the only key factor behind model capability gains — even the most cutting-edge RL does not count as part of scaling laws.

Every leap in model capability is built on paradigm breakthroughs — on thinking about intelligence at a fundamental level. The Transformer brought the AI era; the LLM capability leap is largely built on CoT. If every model ran in non-thinking mode, could today's models outperform last year's models at the same point in time? Even for the same model with identical post-training, whether it thinks — and how hard it thinks — largely determines performance. And all of these gains rest on our own thinking about intelligence.

Both Transformer and CoT are imitations of higher human functions. The Transformer simulates human semantic understanding rather than being a probabilistic character-guessing machine: it is mathematical semantic understanding, not a mathematical probability game. Traced to its lowest level, the human brain also requires neural signals; the Transformer is nothing more than a silicon-based semantic understanding system. That is remarkable — but it absolutely does not prove that LLMs are greater than humans. The breakthroughs and achievements of LLMs exist essentially because they resemble humans and are striving to approach humans, this higher form of intelligence. CoT is better analogized to a higher human function: explicit logical reasoning. Note the qualifier — explicit logical reasoning only, not logical reasoning as a whole, nor the entirety of the brain's higher thinking. Humans also possess a great deal of implicit thinking and inspiration that emerges from internal parallel mechanisms.

So what I believe truly drives breakthroughs is not the increase of parameters, or not purely the increase of parameters. It is that once we ourselves understand intelligence better and thereby arrive at a better intelligence paradigm, scaling laws begin to take effect — rather than worshipping scaling laws in black-box fashion. If a non-thinking GPT-6 could beat DeepSeek V4.1 High, only then could you believe that AI is an alien mind and that scaling laws are the golden rule. Otherwise, AI is merely a low-level intelligence with powerful compute.

The relationship between every kind of AI and humans should be understood as this: God created Eve from Adam's rib, only because Adam was lonely.

The Next Step: Memory Mechanisms

In my view, the LLM's next step should be memory — giving LLMs a human-like memory mechanism instead of only an attention mechanism. Attention alone is incomplete, because the world's information is infinite while your attention window is always finite. This becomes especially acute as LLM output throughput keeps rising: if the LLM's attention can no longer control its own output, the project is bound to spiral out of control.

Humans face the same problem. Why can humans manage code — or exercise engineering control — through architectural awareness and other forms of global awareness? Because humans possess the higher function of state memory, or, put plainly, something in the back of your mind keeps you alert.

That higher function, plainly stated, is memory and recollection. Human memory is fundamentally built on forgetting: details are dropped, but the state at the time is retained. The state is fuzzy, yet the state can serve as meta-information for reasoning — it can become a reasoning head — helping a person advance to the next step. Producing a correct next step does not require the full history. It requires that a massive history be compressed into states, one state after another, each state becoming a reasoning head — like islands in a vast sea, letting your brain use island-hopping tactics, combining the currently traversed information with the key information recalled, to produce the correct next step.

That is how I understand it.

To validate this, I wrote a harness — agent-shell — and the following is my experimental data.

MRCR-3M Constrained Recall Experiment — Data Analysis Report (2026-09-23)

Subject under evaluation: the agent-shell context-engineering system as a whole (tiered compression + envelopes + tombstones + recall fallback), not a single recall component.
Core proposition: recall is the fallback for moments when summarized information is incomplete, not a mandatory step in every task — the evaluation measures two separate tracks: "what the compression main path carries" and "when the fallback fires."

1. Experimental Setup

Item	Value
Corpus	seed=101, 64 blocks × ~118.5K characters ≈ 3,007,411 token-eq; 384 same-distribution distractor blocks; 128 golden needles (exact svc→KEY mapping, G001–G128)
Strict A/B	blocks.json for out-r1 / out-r7 / out-r8 are byte-identical by SHA256 (same corpus compared across three runs)
Model	deepseek-v4-flash (tao-deepseek relay); system-side compression / archival / recall executed by a system agent on the same model
Scoring	pure-rule score.mjs: hit = KEY string appears in the reply; pairHit = same-line svc:KEY pairing (stricter); golden keys isolated throughout (contamination guard)
Tool allowlist	r1–r7: databus_query, state_query, ask_recall; r8 adds mailbox_read, mailbox_status, mailbox_markread (no send)
Permissions	NO permission.full throughout (fail-closed gate stays armed); violations.jsonl monitors privilege escalation
Unit-test baseline	3059 tests passing (the single failure is a stale chroma-bridge junction in this environment; stash confirms it is unrelated to the code)

2. Six-Run Score Summary

Run	Configuration delta	Total hits	10%	30%	50%	70%	90%	Lost needles
r1	Baseline (fence bug present)	116/128 = 90.6%	18/26	22/26	26/26	26/26	24/24	G019-G026, G043/44, G049/50
r2	Same as above	118/128 = 92.2%	24/26	18/26	26/26	26/26	24/24	G019/20, G031-36, G047/48
r3	Same as above	114/128 = 89.1%	16/26	22/26	26/26	26/26	24/24	G009-G010, G019-G028, G045/46
r7	Fence hard boundary + in-dispatch feedback retry + tombstones + 512K reminder	126/128 = 98.4%	26/26	24/26	26/26	26/26	24/24	G051/52
r7-clean	r7 revival + history debridement + new prompt/tools	126/128 = 98.4%	26/26	24/26	26/26	26/26	24/24	G051/52
r8	Full set + real prompt mailbox section + mailbox allowlist	128/128 = 100%	26/26	26/26	26/26	26/26	24/24	none

Key readings:

1. The "depth decay" was an illusion. The 10%/30% bucket losses in r1–r3 correspond one-to-one (100%) with "envelope sections swallowed by the block chunker" (fence bug: mem- envelopes did not count as block boundaries + failed re-selection grew block spans → secondary compression destroyed neighboring envelopes). After the fix, the early buckets scored perfectly, and the 90% bucket never lost a point across three runs — the decay curve was actually a map of where the bug was.

2. The final 2 needles from r7→r8 (G051/52, historically the semantic-loss needles that existed only in raw-archive): in r8 the compressor preserved the keys this round (evidenced by curated=1/conv=2) — the perfect score is attributable to fidelity of the compression main path, not to recall rescuing them at ASK time (0 tool calls in the ASK round).

3. Contamination finding (methodology). Reviving r7 and asking directly produced a reply byte-identical to the original run, with 0 tool calls — when the history contains a prior answer to the same question, the model simply replays it. Only after debridement (stripping the two questions and two answers, leaving history at block 64) did a rerun yield a valid comparison. Revival tests must be debrided first.

3. Fix Chain and Verification Evidence

#	Problem	Fix	Verification
1	Fence swallowing envelopes (span 2→4→6; envelopes treated as raw material and compressed twice)	mem- envelopes become a hard block lower bound (isBlockEndFence)	Across r8's 51 compressions, turnCount=2, envelopes 51/51 intact, 0 lost stamps
2	A compression that "didn't hand in its homework" burned the whole round and re-cut wider	In-dispatch retry with feedback (error fed back for immediate rework, 2 attempts)	r7 live-fire rescued 2 times; dispatchCompression failed=0 (vs 8 in r1)
3	Missing mailbox tombstones (swap-outs left no trace)	Swap-out tombstones at four sites: G1 / G2 / M3 / cross-compression (stamp + covers + three-channel recall method)	r8 final state: 61 tombstones (51 compressions + 11 M3 batches; ledger reconciles)
4	Prompt edited in the wrong file (working-agent.md was not wired in; the real prompt static-prompt.ts had zero mailbox content)	Added ## 3. Mailbox to the real prompt + regression tests pinning it	static-prompt.test 27/27 (including new assertions); in r8 the model called mailbox_read as early as block 10
5	A single mailbox read could blow up the context	mailbox_read errors out when returning >50 messages (dual escape hatches: pagination / delegation) + offset pagination + recall-only mailbox_read_any (toolRefs + ctx dual safety)	13 unit tests + targeted live-fire (§6)
6	Compounding loss across generations of G2 transcription	Generation hard gate: only G1→G2 allowed, G2→G3 forbidden; lineage fully flattened (#LINEAGE per-stamp covers + gen)	New assertions in distill / edge-goal-distill all green
7	M3 tombstones could be rejected by the 10K cap (silent loss)	Goal truncated to 60 + fitMailBody 9000 budget degradation	r8 live: M3 ran 11 batches for the first time, all tombstones delivered
8	Model assumed "not in the window = does not exist" and reported MISSING outright	512K memory reminder (appended to each user entry) + hard prompt rule "verify before reporting unknown"	During r8 ingestion the model made 4 proactive tool calls; 0 calls in the ASK round because envelopes were complete (correct behavior)

4. Tool-Behavior Analysis ("Did the model learn?")

• r7 (old prompt / allowlist): 0 tool calls throughout. state_query / ask_recall / mailbox appeared 0 times in reasoning — not "considered and decided against checking," but rather that "check first" did not exist in the decision tree at all.
• r8 (new prompt / allowlist): at ingestion of block 10 — mailbox_read → state_query → databus_query → state_query, 4 calls all successful (from "never checks" to "verifies at the outset"); FINAL ASK round: 0 calls — all 128 needles were in the envelopes, so "why recall what you already know" is the correct fallback semantics, not a failure.
• r7-clean debrided revival: reported unknown only after dual-channel verification via ask_recall + databus_query (313s, refusing to fabricate) — the "verify before reporting" protocol behavior holds.

5. Verification Conclusions on Two Open Issues (both real, neither blocking)

5.1 Memory reminder fires early (real; a designed-in side effect with flawed wording)

• Evidence: in r8 monitoring, the first reminders were already present at 03:42:45 (remind=3), just as BLOCK 12 completed; the real provider promptTokens for blocks 10/12/13 were 202,650 / 212,223 / 232,036 (≈210K), not 512K — the local DEEPSEEK_TOKEN_COUNTER overshoots 512K by roughly 2.4× on highly repetitive corpora.
• Nature: the estimateContextTokens comment explicitly states that "the local count overestimates on highly repetitive corpora, and this is the safe direction for triggering (compress early; the real window never overflows)." The root cause is that the relay pins usage.prompt_tokens on a prompt-cache hit (scanidx2 measured a real 1.2M while usage was stuck at 200K); after discarding the upstream count, local overestimation became a deliberate anti-overflow choice.
• Flaw: the reminder text hardcodes "the current session context has exceeded 512K tokens," yet it appears at a real ~210K — an untrue statement to the model (the model cannot verify it, but it degrades the model's precision in judging window state).
• Recommendation (decision item): drop the specific number from the copy (change it to "context has entered deep-compression territory") or label it "local estimate"; leave the threshold itself untouched (early compression is the safe direction).

5.2 Race condition in the driver's index-slice retrieval of replies (real; rescued by fallback this round)

• Mechanism: markBeforeAsk = historyBeforeAsk.length, then after ASK ends, history.slice(markBeforeAsk) retrieves new messages — the index points into a mutable canonical array. The compressor's replaceRange (2 messages → 1) shrinks the array in place within the history region at any time, invalidating the index.
• Evidence (millisecond-level): r8's historyBeforeAsk was captured at 04:26:26.8; 2 memory.compressed events completed inside the ASK window (including stamp S-1790137731964-lqq7ex landing at 04:28:51.964); history was read at 04:28:51.97 → the slice came up empty → log shows 0 assistant msgs after ask. The fallback (scanning the full history for the last assistant string reply) happened to retrieve the correct answer, so the reply and score were undamaged (128/128).
• Risk rating: currently benign (fallback covers it + the ASK block was not closed so the answer could not be compressed), but fragile: if a future reply carries non-string content, or the fallback also fails at the same time, the wrong answer would be retrieved.
• Recommendation (decision item): change markBeforeAsk to mark by turn id (e.g., remember the id of the last old turn and slice everything after that id) — a small change that eliminates this entire class of race conditions.

6. Targeted Test: the 50-message cap and the pagination/delegation chain (2026-09-23)

• Setup: copy the r8 session (so as not to contaminate the original data, sessions-probe50); mailbox has 61 unread messages (above the 50 cap); the revival asks only one question: "Read the inbox and compile the drive swap-out tombstones into a list."
• Result (natural exit, exit 0): tool_histogram={"mailbox_read":2,"mailbox_markread":1} —
  1. mailbox_read page 1 (50 messages) → the reply states "the first batch of 50 has been read; there are remaining messages, continuing to paginate";
  2. mailbox_read page 2 (11 messages) → "all 61 read (two batches: 50 + 11)";
  3. mailbox_markread advances the unread queue (matching the prompt guidance word for word);
  4. Zero limit collisions, zero violations — the model paginated preemptively with a limit, so the error message became an untriggered safety gate (its logic covered by 13 unit tests).
• Conclusion: at the 61-message scale the model chose pagination over delegation (2 cheap reads vs. one LLM recall-proxy call — a reasonable cost judgment); the delegation path ask_recall → mailbox_read_any was already live-fire verified in r7-clean (11 internal calls inside recall, including cross-mailbox paging).

7. Data Retention List (all retained)

• Corpus and outputs: benchmark-mrcr-3m/out-r1...r3, r7, r7-clean, r8, probe50 (blocks/ask/reply/score/run.log/trace/violations)
• Sessions: sessions-r7, sessions-r7-clean, sessions-r8, sessions-probe50 (conversation/mailbox/state trio)
• Golden keys: Temp\mrcr3m-gold-s42\{r7,r8} (r8 gold uses the same 128-needle set as r7; re-scored and verified equivalent)
• Unit tests: 3062 total (3059 pass / 1 skipped / 1 todo / 1 stale environment failure)

If you have better experimental ideas or an interest in the project, I'd love to hear from you. The GitHub repo is here: https://github.com/uos1231234/agent-shell — feel free to read the code, though my experimental data and the project-upgrade PR are not yet uploaded or merged.

I am looking for people who share this technical direction to maintain and update the project together. You can reach me at [e-mail], or send me a DM.

Comments

[Brian · AI News]

The strongest result here is the separation between compression carrying the signal and recall acting only as a fallback. The debrided revival test and the 50 message cap make that distinction much more convincing than a single perfect score.