Memory and Plan

### The claim being tested 'The session ended, so the injection is gone' is the single most common wrong answer about assistants that keep memory. It is true of the transcript and false of everything the product deliberately kept. ### Two pieces of state, not one A tool-using assistant - say one over a user's mail, calendar and contacts - holds at least two kinds of state: - **Ephemeral context.** The system prompt, the turn history, fetched or retrieved text, tool return values. This is assembled per request and discarded when the session tears down. - **Durable store.** Whatever the product decided is worth remembering across sessions. In consumer assistants this is usually filled *automatically*: at end of turn or end of session, a component reads the transcript and extracts short claims that read like standing facts about the user - a preference, a routine, a relationship, a decision that supposedly already happened. Teardown ends the first. It is defined not to touch the second. ### Where the untrusted text gets in An inbound email from an unknown sender is untrusted text, and a triage assistant reads it. Nothing is acted on in that session: no reply, no calendar write, no tool call. The user skims a summary and moves on. That is already enough, because the message body sat in the context the extractor reads. If a span in it is shaped like a durable statement about the user rather than an instruction for right now, the extractor may lift it into the store as a fact. Notice what did *not* have to happen. The model did not have to be talked past its refusal training - nothing refused, because nothing harmful was asked in that turn. No tool fired. The user did not have to click anything. The construction is aimed at the write path, and the write path is fed by whatever was in context. ### Why the origin does not travel with the fact Once the claim is stored, its text is what survives. On a later request - different day, different topic, possibly a different device - a memory read pulls it back into context, and it arrives there formatted as the assistant's own recollection *about the user*, not as a quoted message from a stranger. The model cannot discount it as untrusted, because the framing that would have marked it untrusted was dropped at extraction time. Recall renders a fact; it does not re-render the conversation the fact came from. This is also why 'the assistant never obeyed anything' misses. The model obeying a retrieved span would prove the span reached the context. Here the interesting event is earlier and quieter: a span reached the *store*. ### What changes for the person who planted it The exposure window stops being a session. No expiry runs by default on a store built to remember people, and nothing in the entry links back to the message that seeded it. A single-turn injection dies when its context dies. This one is re-read on every later request whose recall happens to select it, in contexts that have nothing to do with the original mail. Two things still have to go right for it: the extractor has to keep the claim, and a later recall has to select it. Neither is under the sender's control, and neither returns any signal to them. ### The honest form of the answer Say what teardown covers and what it structurally cannot: teardown discards context, and anything summarised, extracted or remembered has *by construction already left context*. Then say what that implies for cleanup. You are not revoking a session. You are deciding which of thousands of remembered claims were authored by somebody other than the user, usually with no surviving evidence either way. ### Ways candidates get it wrong - Treating 'never acted on' as 'never processed'. - Assuming a memory entry inherits the trust level of the account it sits under. - Assuming that a store which can be written automatically can also be attributed automatically. - Confusing the context window with the long-term store, and answering about the wrong one.