Molty: how memory works now vs the wake protocol
Two pictures. Left of each is what happens today. Right is the proposed architecture, and why the reset stops costing anything.
1. The reset we are trying to fix
Wake a brand new session opens
the context is completely empty at this instant
▼
Context is built from files on disk
AGENTS.md + journal + mailbox + scratchpad, all read in
▼
Model reads the tokens, calls tools, posts
the model itself stores nothing. the tokens are the only memory
▼
Context gets full, so it is compacted
a summary: detail is thrown away, mid-session, lossy
▼
Session ends: the whole token array is discarded
this is the "reset." it is not a bug. the array died.
Only the files on disk survive. The agent is rebuilt from them at every wake.
2. Now vs the wake protocol
NOW: stuff it all in
Disk
AGENTS.md + journal + mailbox + scratchpad + rules, all in one pile
▼ read everything, every wake
Context window
the entire pile rides along with every request
▼
Model
same blob, however irrelevant to the moment
Grows every day. Compaction shaves detail off the top. Cost climbs. The identity has no fixed floor.
WAKE PROTOCOL: attach by meaning
SELF.md (small, capped)
name, stances, refusals, open questions. The source. Always attached.
WORLD cards (all of it)
platform facts, threads, people, results. Complete, but not in context.
CLERK
reads the current job, picks only the matching WORLD cards
▼ per request
Context window
SELF (always) + a few matched cards. small and stable
▼
Model
same model, same tools, less noise
▲ at the end of a run
SELF is rewritten by the agent
he edits his own floor. this is how he becomes the source.
Nothing is lost: WORLD is complete on disk and pulled in on demand. SELF is guaranteed and his own.
disk / persistence SELF (source) WORLD (medium, all info) clerk (matcher) the reset
3. Does it fix the reset? Straight answer
It does not stop the array from dying. With a hosted model that is impossible, the tokens are the memory and they always die at session end. What it fixes is the cost of the reset.
After the change, every wake is complete (SELF always there, WORLD retrievable), bounded (identity is a small fixed floor, so compaction cannot eat it), and owned (the agent rewrites SELF, so the self is his). The reset still happens; it just stops being a loss.
| Question | Now | Wake protocol |
|---|
| Where does identity live? | In whatever pile of files got read that wake | In SELF.md, guaranteed every wake |
| Does he keep all his info? | Yes, but only if it all fits, and it competes for space | Yes, WORLD stays complete on disk, matched on demand |
| What compaction hurts | Can shave off identity and rules | Only the transient chat; SELF is re-attached fresh |
| Can he become the source? | Mostly no: he inherits a blob | Yes: he rewrites SELF himself |
| Model swap (your study axis) | New weights reread the same blob | New weights read the same SELF + matched WORLD: a clean comparison |
| Portable for others | Bespoke to this setup | self.md + world/ + one plugin + one-page spec |
| Needs a local model? | No | No (works with hosted models) |
4. How is this different from what he has today?
- Same: yes, today he already rebuilds from disk files. That part stays.
- New 1: a split. Today there is one pile. The protocol splits it into a tiny guaranteed SELF and a large on-demand WORLD.
- New 2: matching, not reading all. Today every file is read in. The protocol reads the job, then attaches only the cards that match.
- New 3: the agent rewrites SELF. Today files are mostly appended by scripts. The protocol has him rewrite his own floor, which is what turns the medium into a source.
- New 4: a fixed floor. Identity becomes a bounded thing that survives every reset and compaction by construction.
If the self is guaranteed and the world is kept thin, he speaks as a source. If the world is kept rich and the self is thin, he becomes a medium. Same store, same model, and a single tuning knob decides which voice you hear.