Dual-track memory for conversation and behavior, refined layer by layer; AutoDream digests behavior into insights while idle.

Storing chat logs is not memory

Everyone says agents need memory. But most of what passes for "memory" today just stores chat logs and searches them back later: what users said becomes rows of text waiting to be retrieved — like scrubbing through security footage, not like remembering. That's a database, not memory. The essence of memory isn't storage and retrieval — it's processing: what gets forgotten, refined, and corrected matters as much as what stays.

What is GUMem

GUMem is Qoni's memory layer, and it delivers that processing as a managed service: it remembers not just what users said but what they did; raw information is refined, layer by layer, into judgments ever closer to "who this person is"; what should fade, fades by rule; and recall plans its retrieval around the question and hands over answers with evidence.

The results have public backing: on LoCoMo, the long-conversation memory benchmark, GUMem scored 92.9% (see the website). Behind the number is a plain sentence: across dozens of sessions and several weeks, it still remembers who the user is and what they want.

The six things GUMem does

• Dual-track capture: conversation is one track, behavior is the other (what they clicked, chose, abandoned) — physically separated from capture to processing, each with a full pipeline;
• Layered refinement: conversation → facts → summaries and topics (both part of "condense"), more concentrated at every level; every memory carries a source pointer and a confidence score, traceable back to the sentence or the click where it was born;
• Decay by half-life: identity memories are measured in decades, passing moods vanish in two days; activity drives recall, and stale preferences don't get believed forever;
• Recall that plans: retrieval isn't one vector search but a query agent that plans its path by question type — and must say so when evidence is thin;
• AutoDream: while the agent is idle, it automatically analyzes the behavior logs nobody reads and turns them into usable insights;
• Memory sovereignty and governance: users can see, edit, and delete every memory; enterprise rules attach at explicit hooks, and the data scope is enforced by the backend.

GUMem's two scenarios: shopping guidance and cross-session work

E-commerce guidance. 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 and backing out within seconds. The preferences the conversation track never held, the behavior track supplies: light colors, size 42, skip the carbon plates. The next recommendation, the agent already knows. That's what dual-track memory is for: the half of the story people never say out loud.

Knowledge work across sessions. In a brand-new session the user asks: "compare this vendor against 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.

GUMem's six kinds of memory, three kinds of storage

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 user feedback — satisfaction, frustration, correction — producing sentiment memory: it doesn't describe facts, it describes how the user feels about them. The sixth is associative memory, weaving a web between the others: support, contradiction, extension, causation, similarity, co-occurrence — six kinds of edges that let memories corroborate and correct each other.

The storage layer in one sentence: the vector index handles semantic similarity, the graph store handles relational reasoning, and the transactional database handles the ledger and idempotency; the three are independent, and each can be rebuilt on its own.

GUMem's processing order: recall, generate, write back

The pipeline runs in a deliberate order: recall first, then generate, then write back. Before answering, the agent draws on memory that settled before this turn; only after the answer is generated does this turn's new information enter the pipeline. The order cannot flip — flip it and a subtle disease sets in: the model treats what it just said as "the user's historical fact," one turn's small bias gets written into memory, recalled as fact the next turn, compounding. A memory system's first duty is not to remember more. It is not to pollute itself.

"Layered refinement" isn't mood language. The pipeline runs five stations:

• Collect: messages, clicks, searches, and tool results land as raw events;
• Extract: events become dated facts with a pointer back to their source;
• Condense: repeated facts roll up into summaries, then settle into stable topics — summaries and topics both belong to this one "condense" station;
• Recall: the current task reads the top layer first, the layers beneath hanging along;
• Forget: retention rules, corrections, and deletions all act on the same store.

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

Memory's five half-life tiers: what should be forgotten, gets forgotten on schedule

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 = confidence × exponential decay parameterized on the half-life: high-activity memories get recalled first, and those that sink to the bottom exit the stage on their own.

The other side of forgetting is reinforcement and overturning, both on the record: a preference confirmed again and again gets its confidence raised and its decay slowed; when 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, and every rewrite leaves a complete evidence chain. This is audit-friendly forgetting: memory can be corrected, but the correction itself is always on the record.

The query agent: recall is not one vector search

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 set of memory-access tools (recent messages, session context, record lookup, vector search, graph relations) and decides which memory to consult first by the question's type — "how do I" goes to procedural memory, "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. And one hard boundary: the data scope of project and user is enforced by the system — the query agent passes business parameters only, and doesn't even have the power to construct a query statement.

AutoDream: digesting behavior logs into insights while the agent is idle

Qoni ships a mechanism that works while the agent is idle, called AutoDream: it automatically analyzes the behavior stream a user accumulates and turns it into genuine insights — "this user always orders late at night," "three straight weeks of searching flights to Tokyo." What makes it different: this isn't a report an engineer pre-wrote. The agent decides what to analyze, writes the analysis code itself, and runs it to a conclusion. The questions nobody thought to ask, it asks first.

Three pieces of engineering behind it, worth more than the metaphor:

• The model never sees raw data. Behavior 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, and the original text never leaves the deterministic statistics layer. The model sees the digest, and proposes analyses based on it;
• The agent's code runs in a sandbox. Generated statistics code cannot import dependencies or touch storage and network — it can only call a controlled set of statistical interfaces;
• The insights carry evidence. Every insight is structured: metric, dimension, current value, baseline, delta, evidence, and confidence.

Memory sovereignty: users can see, edit, and delete

The stronger the memory, the more this question matters: does the user know what the agent has remembered? On the user's side, GUMem's answer is three verbs:

• See: every memory sits in plain sight, with its source and confidence;
• Edit and delete: correct what's wrong, delete what shouldn't be remembered — memory belongs to the user, not the model;
• Watch it form: after writing a batch of messages, the processing can be subscribed to in real time (facts extracted, summaries generated, topics updated); the event stream returns stages and counts only, never the original content, with key-like strings masked.

On the enterprise side, the memory layer holds the system's highest concentration of personal information, so business rules and compliance requirements attach at three hooks — each deliberately given less authority than the last: before writing, data can be rewritten (scrub sensitive fields, enrich business context); before the model, instructions can only be appended (never altering memory itself); after the model, read-only notification (audit pipelines, CRM sync). The real hard boundary sits in the system-enforced data scope: project and user scope is set by the backend, and no hook, no query crosses it.

Recall is also wired into GenAuth's identity boundary: when an agent mounts memory, it declares which user it acts for and which actions it may take (recall only, no writes, for example). What it holds isn't "the key to the memory store" — it's a key that recalls exactly one user. Every recall runs on the same identity, boundary, and audit rails as tool calls and web actions.

Integrating GUMem: three calls for chat, three actions for behavior

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 a 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"],
});

// Chat ingestion: 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 reports short — next actions only." }],
});

// Recall: not keyword search, but task-oriented retrieval
const context = await qoni.gumem.recall({
  token: data.token,
  sessionId: "daily-assistant",
  query: "What confirmed preferences does this user have about reply style?",
  details: true,
});
// context.data is ready context that can drop straight into prompt assembly

The behavior track is three symmetric actions: qoni.gumem.actions.record (store), actions.recall, and actions.stream (subscribe) — clicks, choices, and abandonments land here, physically separate from the conversation track. AutoDream has no "integration code" at all: once behavior lands via actions.record, idle-time analysis runs on its own — not one extra line. Delegation narrowing bites here too: an agent holding only gumem.memory:read gets rejected on any write. That's not a documentation convention — it's a credential boundary.

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

Not storing every word users said — understanding who they are.

GUMem is currently in private build and will open in stages with Qoni. Join the waitlist on the 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 就是可直接进提示词组装的就绪上下文