Concepts
Memory architecture
Six layers and the active learning loop.
4 min read
Memory architecture
AIBOS started out with a passive record — a list of what exists, a decision log, folders that describe themselves. What was missing was something active: an agent that actually remembers while it's working, not just a trail somebody might review later if they think to look. That's what the memory architecture adds. All of it runs on plain text files. No special database is needed to make it work.
Six kinds of memory, in everyday terms
| Kind of memory | The question it answers | Where it stands |
|---|---|---|
| What exists, and where | "What files and folders do we actually have?" | Built and working |
| Why we decided things | "Why did we choose this, and not the alternative?" | Built and working |
| What past sessions did | "What did we already do last time?" — searchable, so you never have to ask twice | Built and working |
| Reusable how-tos | "How do I do this kind of task?" | Not built yet — planned for a later phase |
| What the agent has learned here | "What have I figured out that's specific to this sphere?" | Built and working |
| Who you are and how you work | Written by you, about you | Built and working |
The "who you are" layer has one rule enforced deliberately: no scheduled job, no background task, is ever allowed to write to it (a written rule, checked every night). Only a real conversation with you can update who you are, because letting an automated process quietly rewrite the record of who the operator is would poison the one layer everything else defers to.
The loop: capture, review, route, recall
The active side of memory runs in a fixed order, every time:
- Capture happens during the work itself — nothing that happens in a session is deliberately hidden from being noticed.
- Review runs only after an agent finishes delivering something — a quiet background pass that asks one question: did I learn anything here worth keeping? Your actual conversation is never interrupted for this.
- Route sends whatever is worth keeping to the right memory file, written safely so two sessions working at once can't corrupt each other's work.
- Recall happens automatically at the start of the next session — memory is read once and carried into everything that follows — and again on demand, whenever an agent searches back through what happened before. Results come back clearly marked as background reference, and anything sensitive is stripped out before reuse.
The memory rules, and an honest note about which ones are actually enforced
A handful of rules govern how memory gets written. The two that matter most in daily use: there's a hard size limit of 3,000 characters on each memory file, which rejects anything over the cap rather than quietly cutting it short, and only the actual fix gets captured when something goes wrong — the mistake itself doesn't get written down, because an agent that reads its own record of a mistake risks learning to repeat it.
Here's the honest part: only the size limit carries a hard, code-enforced gate — the tool itself refuses an oversized write, full stop. The rest of the memory rules — one active memory system at a time, treating recalled content as reference rather than instruction, protecting what a human wrote from automated cleanup, never letting a memory outage block a response — are enforced by a written rule plus a nightly check that catches violations after the fact. That's a real difference, and AIBOS is upfront about which kind of guarantee applies where, rather than implying everything is bulletproof.
The size limit is worth understanding by feel: it's the mechanism that keeps memory useful. When a file hits 3,000 characters, the agent has to tidy up and consolidate before it can add anything new, instead of letting the file quietly grow forever into something nobody reads anymore.
The five-session stress test
To find out what would actually happen, five AI sessions were pointed at the same memory file at once, all trying to write to it simultaneously. With the size limit and the one-writer-at-a-time rule in place: 75 writes went through, 125 were turned away, and nothing broke. Run the same test with those protections turned off, and that same file exploded into 1.2 million characters of garbage — half-finished sentences from different sessions tangled together, unreadable and unrecoverable.
The limit that annoys you in the moment is the same limit that keeps the file from becoming useless.
Plain text, nothing exotic underneath
Every one of these six memory files is ordinary text you can open and read yourself, with full version history behind it. Searching past sessions works by literally searching the text — nothing fancier than that. It's a deliberate starting point rather than a permanent ceiling: a more powerful memory backend for very long-running work is a real possibility later, waiting on an actual need to show up, not a date on a calendar. For now, everything that matters is a file you can open yourself.