AutoDream, layered memory, and what it means to remember you.

Stored chat logs only let an agent replay the past; refining, forgetting, and correcting make a memory

Computer science perfected storage: databases keep a record intact for decades, search engines answer across trillions of pages in milliseconds, cloud drives hold every photo you've ever taken. Thirty years of infrastructure, all answering one question: how do we store information exactly as it was, and retrieve it exactly as it was?

But memory was never that.

People don't remember each other that way. You can't recall every sentence a friend has said, yet you remember they won't touch cilantro. You can't replay last month's meetings, yet you've concluded they hate any meeting that runs past thirty minutes. Memory isn't storage and retrieval — it's processing. What gets forgotten, distilled, and corrected matters as much as what stays.

Everyone says agents need memory. But most of what ships as "memory" today is chat logs in storage, retrieved on demand. Everything you've said becomes rows of text waiting to be searched — less like remembering, more like scrubbing through security footage.

That's a database, not a memory.

GUMem is modeled on human memory: it refines, it forgets, it stays traceable

GUMem is Qoni's memory layer. Its overall shape comes down to three decisions:

• It remembers not just what you said, but what you did. Conversation is one track; behavior is another — what you clicked, what you chose, what you abandoned. The two tracks are physically separated from ingestion to processing, each with a complete pipeline of its own;
• Raw information is refined layer by layer: conversation → facts → summaries → topics. The higher you go, the denser it gets — and the closer to who this person is;
• Every memory carries a source pointer, a confidence score, and time decay, traceable all the way back to the sentence or the click where it was born.

Let's take those three decisions apart, one at a time.

Six memory types, linked by six relation types, corroborate and correct one another

Human memory isn't one pool, and neither is GUMem's. Raw input first lands in working memory, the starting point of all processing. It then aggregates into episodic memory: what happened, and in what context. Episodes settle upward along two paths: semantic memory answers "who this person is, what they prefer," and procedural memory answers "how this task gets done."

The fifth kind comes from a different source: user feedback — satisfaction, frustration, correction — produces sentiment memory. It doesn't describe facts; it describes how the user feels about them.

The sixth is the most distinctive: associative memory weaves the web between the others. Supports, contradicts, extends, causes, resembles, co-occurs — six kinds of relation edges that let memories corroborate and correct one another.

Every layer's output carries fields and anchors, so any memory can be traced to its source

"Refined layer by layer" isn't just atmosphere. Each layer's output is a structured object with fields:

• The extraction layer produces facts and observations: the smallest reusable units of information, carrying entity, source, time range, and processing status;
• The compression layer produces summaries and propositions: topic tags, confidence, a decay factor, retrieval weight — and an anchor pointing back to the original evidence;
• The recall layer produces a five-layer ready context: recent messages, session context, the user's long-term memory, the session's long-term memory, and formatted injection text. Each layer has a quota, tunable per task (how many recent messages, how many long-term memories to inject).

The fields exist for verifiability: any recalled memory can trace through its anchor back to the original event; any confidence score can explain what reinforced it and what weakened it. A memory system that can't explain where its beliefs came from is a liability inside an enterprise, not an asset.

Recall first, then generate, then write back: flip the order and memory pollutes itself

The pipeline runs in a deliberate order: recall first, then generate, then write back.

Before the agent answers you, it recalls the memories that had already settled before this turn began. Only after the answer is generated does this turn's new information enter the pipeline. The order must not flip. Flip it, and you get a subtle disease: the model treats what it just said as "the user's historical facts," growing more confident and more wrong with every turn.

In a long-term memory system this self-pollution is especially dangerous because it compounds: one turn's small bias gets written into memory, recalled as fact the next turn, generating a more biased answer that writes back an even more biased memory. A memory system's first duty is not to remember more. It is not to pollute itself.

Decay by half-life, revise on evidence: stale preferences don't get believed forever

A real memory system must answer three questions no database ever answers.

Does memory forget? Yes — and it forgets by physical law. GUMem assigns every memory a half-life: identity memories (he's an engineer) are measured in decades, stable relationships in years, preferences and habits in quarters, temporary plans fade in two weeks, passing moods vanish in two days. A memory's activity is set by a decay function: confidence multiplied by exponential decay parameterized on the half-life. High-activity memories get recalled first; those that sink to the bottom exit the stage on their own. Not all memories are born equal, nor should they be equally immortal.

Does memory harden? Yes. A preference confirmed again and again gets its confidence raised and its decay slowed — like an impression a person keeps deepening.

Can memory be overturned? Yes — and overturning has its own discipline. The user says "I've stopped drinking americanos, I drink lattes now": the old memory isn't physically deleted, it's marked invalidated and pointed at the new memory that overturned it; an old preference narrowed by conditions gets down-weighted and decays faster, but stays present. Every rewrite leaves a complete evidence chain. We call this audit-friendly forgetting: memory can be corrected, but the correction itself is always on the record.

Vector, graph, and transactional stores each do one job, and any failed layer can be rebuilt independently

This memory physics lands on a storage layer with equally clean separation: the vector index handles semantic similarity ("find the memories most like this sentence"), the graph store handles relational reasoning (who supports whom, who overturned whom, what caused what), and the transactional database handles the ledger and idempotency (which message has been processed, which is in flight).

The three stores don't depend on each other; any layer can be rebuilt independently if it breaks.

A query agent plans recall by question type and cross-checks evidence: precise context, never out of scope

Storing well is half the job. Recalling precisely is the other half.

In most memory systems, "recall" is one vector search: take the question, compare against the store, hand over the closest matches. GUMem's recall is a query agent that plans. It carries a toolbox of memory access (recent messages, session context, record lookup, vector search, graph relations) and decides which memory to consult first based on the question's type: "how do I" goes to procedural memory first, "what happened" goes to episodic, relationship questions walk the graph, preference questions check the sentiment track first. Evidence is cross-checked across types, then assembled into exactly the context this task needs. No more, no less.

It also obeys an honesty protocol hard-coded into the system: only memories actually retrieved count as evidence — fabrication is forbidden; when evidence is thin, it must say so instead of guessing; when evidence conflicts, it resolves by a fixed priority (the user's explicit correction beats an inferred preference, the current session beats old memory, a specific constraint beats a broad liking), and what can't be resolved gets laid out on the table: "there's a disagreement here."

And one hard boundary: the data scope of project and user is enforced by the system. The query agent passes business parameters only — it doesn't even have the power to construct a query statement. Clever is welcome. Crossing the line is not.

AutoDream digests behavior logs while the agent idles, asking what you didn't think to ask

When people rest, the brain keeps working.

Inside Qoni there's a mechanism that works while the agent idles, and its name says it: AutoDream. It digests the user's accumulated behavioral logs into genuine insights. Things like: "this user tends to order late at night," or "for three weeks they've been looking at flights to Tokyo."

Dreaming is a metaphor. What it does is concrete: it turns piles of logs nobody reads into judgments someone can use. And here's what makes it different: this is not a pre-written statistics report. The agent decides what to analyze, writes the analysis code itself, and runs the analysis to produce its own findings. The question you didn't think to ask — it asks for you.

The engineering underneath is worth more than the metaphor:

• The model never sees your raw data. Behavioral logs first pass through a deterministic statistics layer that involves no model at all, compressed into a "data digest"; natural-language content keeps only statistical features like length — the original text never leaves. The model sees only this digest, and proposes its analyses on top of it.
• The code the agent writes runs in a sandbox. Generated statistical code may not import dependencies and may not touch storage or the network; it can only call a controlled set of statistical interfaces. The data scope is enforced by the backend — however clever the code, it cannot reach one line of logs beyond the boundary.
• The insights ship with evidence. Every insight is structured: metric, dimension, current value, baseline, delta, evidence and confidence — verifiable, not just a nice sentence.

Memory sovereignty belongs to the user: see, fix, and delete what the agent remembers

The stronger the memory, the more urgent the other question: do you know what the agent remembers about you?

In GUMem, the answer is three capabilities:

• You can see it. Every memory sits in the open, with its source and its confidence: why it believes what it believes, and how sure it is, at a glance.
• You can fix it, and delete it. Wrong? Correct it. Don't want it remembered? Delete it. Memory belongs to the user, not to the model.
• You can watch it grow. After writing in a batch of messages, you can subscribe to its processing in real time: facts extracted, summaries generated, topics updated — one event per stage, pushed to you. The stream returns stages and counts only, never the content itself, and secret-like strings are always masked: observable, never leaky.

We call this memory sovereignty: not an agent quietly remembering you, but you deciding what it may remember.

Enterprise rules attach at three hooks with shrinking authority, never crossing the data boundary

When an enterprise adopts a memory layer, the first question is usually: "where do my business rules and compliance requirements attach?" GUMem leaves three hooks on the pipeline — and deliberately gives each one less authority than the last:

• Before write: may rewrite data. Scrubbing sensitive fields, enriching business context, normalizing formats — all before anything lands in memory;
• Before the model: may only append instructions. Business rules and compliance constraints are injected as directives, but the memory itself cannot be tampered with;
• After the model: read-only notification. Audit pipelines, CRM or recommender sync — they see the results and can change nothing.

Rewrite, append-only, read-only: the shrinking sequence is itself the governance philosophy. And the real hard boundary isn't on the hooks at all: it's the system-enforced data scope. Project and user scope is set by the backend, and no hook, no query crosses it.

Users say "just browsing"; the behavior track recovers the preferences their clicks reveal

A typical deployment scenario: an e-commerce shopping agent.

The user says "just browsing." But the behavior track tells another story: repeatedly opening light-colored sneakers, filtering size 42, clicking into carbon-plate runners again and again — and backing out within seconds. The preferences the conversation track never carried, the behavior track spoke for them: light colors, size 42, skip the carbon plates. Next recommendation, the agent already knows.

That's what dual-track memory is for: not one more log to store, but the half of the story people never say out loud.

Recall across sessions: in a brand-new chat, it still knows what you cared about last week

Now a knowledge-work scene. In a brand-new session, the user asks: "compare this vendor with the one I liked last week."

No pasted context, no re-briefing. The query agent recalls across sessions: what last week's vendor was called, that the user cared most about deployment risk, that he prefers concise answers. So the answer lands in one step: "cheaper than last week's, but weaker on audit export and deployment controls." Every supporting memory carries its source pointer — some from conversation, some from the click stream.

To the user, this is "it remembers me." To the engineer, it's a verifiable evidence chain.

Memory access runs on GenAuth delegation: a key to one user, not the whole store

Inside an enterprise, the memory layer is never an island. GUMem shares its identity boundary with GenAuth: when an agent mounts memory, it must declare which user it acts for and which actions it's allowed — recall only, no writes, for instance. That declaration is itself a narrowed delegation: the agent doesn't get "the keys to the memory store" — it gets a key that can only recall this one user. Every memory access, like every tool call and every web operation, runs through the same identity, boundary, and audit.

A few lines store and recall chat and behavior; once behavior is recorded, AutoDream needs no extra code

Everything so far has been the machine's insides. Developers care about a different question: how many lines to plug in.

The SDK ships as @qoniai/qoni (Node 18+, ESM / CommonJS dual build, full TypeScript types), initialized with the AK / SK from Qoni Console. Step one is, again, delegation: GUMem's scopes are fine-grained (gumem.memory:read / gumem.memory:write / gumem.message:write), and the common session / write / recall path has a preset bundle, QoniScopeBundles.GUMEM_SESSION_RECALL.

Storing and recalling the conversation track takes three calls:

import { Qoni } from "@qoniai/qoni";

const qoni = new Qoni({ accessKey, secretKey });

const { data } = await qoni.delegateToken({
  user: { id: userId },
  scopes: ["gumem.memory:read", "gumem.memory:write", "gumem.message:write"],
});

// Store chat: open a session, write messages
await qoni.gumem.createSession({
  token: data.token,
  userId,
  sessionId: "daily-assistant",
  title: "Daily assistant memory",
});
await qoni.gumem.addMessages({
  token: data.token,
  sessionId: "daily-assistant",
  messages: [{ role: "user", content: "Keep daily planning suggestions concise — next action only." }],
});

// Recall: not a keyword search, but retrieval aimed at the task at hand
const context = await qoni.gumem.recall({
  token: data.token,
  sessionId: "daily-assistant",
  query: "What confirmed preferences should I consider for this user's reply style?",
  details: true,
});
// context.data is the ready context from earlier sections — feed it straight into your prompt assembly

The behavior track is a symmetric trio: qoni.gumem.actions.record (store), actions.recall (recall), and actions.stream (subscribe). Click streams, choices, abandonments land here — physically separate from the conversation track.

AutoDream has no "integration code" to speak of: once behavior lands through actions.record, idle-time analysis runs on its own — not one extra line from you. The insights it produces are the structured objects described earlier, with metric, baseline, delta, evidence, and confidence.

Delegation narrowing takes effect right here, too: an agent holding only gumem.memory:read gets rejected on any write. That's not a documentation convention — it's the credential boundary.

Don't trust a black-box memory: verify recall, correction, and scope item by item

Everything above lands as checkable items on a POC acceptance sheet:

• Any recalled memory can trace through its anchor back to the original event;
• After the user corrects or deletes a memory, subsequent recalls stop returning the old value;
• Overturn an old preference with an explicit correction: the old memory is marked invalidated and points to the new one, with a complete, queryable evidence chain;
• Subscribe to the memory-formation event stream: stages and counts only, no original content, secret-like strings masked;
• Ask a question the memory store has no grounds for: the query agent says the evidence is thin instead of fabricating;
• An answer generated this turn is not recalled within the same turn as "the user's historical fact";
• Queries beyond the scope are rejected, no matter how clever the query agent is;
• Take a recall-only delegation and attempt a write: rejected, and the rejection is on the record.

One quick-reference table to gather everything this piece covered:

92.9% on LoCoMo: weeks later, it still remembers you

On LoCoMo, the long-conversation memory benchmark, GUMem scored 92.9% (verifiable on our website).

Behind that number is a plain sentence: across dozens of sessions and weeks of silence, it still remembers who you are and what you want.

Memory is the line between a tool and a companion: a companion remembers where you left off

Memory isn't an item on a feature list. It's where agents and "tools" part ways: a tool meets you for the first time every time; a companion remembers where the conversation left off.

Not storing every sentence you've said — understanding who you are.

GUMem is currently in private build and will roll out in stages as part of Qoni. You can join the waitlist on our website.

import { Qoni } from "@qoniai/qoni";

const qoni = new Qoni({ accessKey, secretKey });

const { data } = await qoni.delegateToken({
  user: { id: userId },
  scopes: ["gumem.memory:read", "gumem.memory:write", "gumem.message:write"],
});

// Chat 存入：开一个会话，写入消息
await qoni.gumem.createSession({
  token: data.token,
  userId,
  sessionId: "daily-assistant",
  title: "日常助理记忆",
});
await qoni.gumem.addMessages({
  token: data.token,
  sessionId: "daily-assistant",
  messages: [{ role: "user", content: "日报建议尽量简短，只给下一步行动。" }],
});

// 召回：不是关键词搜索，是面向当前任务的取用
const context = await qoni.gumem.recall({
  token: data.token,
  sessionId: "daily-assistant",
  query: "这个用户对回复风格有什么已确认的偏好？",
  details: true,
});
// context.data 就是前文说的就绪上下文，直接进你的提示词组装