Pip on Qwen 3.8 Max

Pip is the assistant in the satchel demo. It runs on Qwen 3.8 Max, and Qwen does more than answer: on every turn it decides which things you said are lasting facts about you, calls a tool to keep each one, and then answers using everything it already knows. Those facts end up sealed under a key that only your passkey can derive, and you can hand them to a second app on Monad and take them back later.

The agent loop

Pip gets one tool, remember, and up to three steps. Qwen reads the conversation plus the memories already unsealed in your browser, works out what is durable (a diet, a home airport, an allergy) and what is a one-off request, calls remember once per new fact, and only then writes the reply. A fact already in memory comes back from the tool as already remembered, so asking the same thing twice never fills the vault with duplicates.

// api/chat.ts: Pip is an agent with one tool. Qwen decides which facts are worth keeping.
const remember = tool({
  description: "Keep one durable fact about the person in their sealed memory.",
  inputSchema: factSchema,                              // { fact }: 2 to 200 characters
  execute: async ({ fact }) => (known(fact) ? "already remembered" : (remembered.push(fact), "remembered")),
});

const result = await generateText({
  model: openrouter("qwen/qwen3.8-max-0902"),
  system: withMemories(PIP_SYSTEM, input.memories),   // memories this browser unsealed itself
  messages: input.messages,
  tools: { remember },
  stopWhen: stepCountIs(3),                            // decide, call the tool, then answer
});
return json({ reply: result.text, remembered });

The function is stateless. It sees the memories for the length of one call, because your browser unsealed them and sent them along, and it returns the facts Qwen chose. Nothing is written server side.

What happens to a remembered fact

Back in the browser, each fact is sealed with the key for the memory/assistant namespace, which satchel derives from your passkey's PRF output. The store holds ciphertext rows with a plain epoch header. A second app such as Fern can read them only after Pip writes a grant to the registry on Monad at 0xd6c895f5c9254dc6eaafc335fff0930fd7012e6d, and a revoke rotates the epoch so the old grant opens nothing new.

// lib/memory.ts: every fact Qwen chose is sealed in the browser before it is stored.
const sealed = await s.seal(ns("memory/assistant"), { text, at });
store.add({ id, at, hex: toHex(sealed.toBytes()) });   // the store only ever sees ciphertext

One real turn

Sent to the live deployment on 14 October 2026, with an empty memory:

Why Qwen for this job

The hard part of an assistant with memory isn't storage; it's judgment about what deserves to be stored, because every kept fact becomes something the person may later grant to another app. Qwen 3.8 Max makes that call reliably inside a tool loop: it separates the request from the facts in the same sentence, phrases each fact as a short plain statement that reads well when Fern sees it, and confirms in one line what it kept so the person always knows what went into their vault. It also uses the existing memories without being asked, which is the whole point of a memory that travels.

Pip asks OpenRouter for Qwen first, and the deployment reads the answering model back from every response, so the reply above is attributable to Qwen and not to a fallback.

Try it

Open Pip, sign in with a passkey, and tell it something about yourself. Then allow Fern on the Sharing page and ask Fern to plan a weekend. The guide Fern on Kimi covers the other side.