OpenCode has no memory subsystem. It has three mechanisms that fail differently

The three layers do not fail in the same way, and one word for all of them hides that.

The instruction layer fails by going stale. AGENTS.md, CLAUDE.md and configured instructions are read off disk and placed in the system prompt; the loader reads them and does not maintain them ^[7]. Nothing notices when a rule stops describing the code, because there is no service that updates facts when they change ^[5]. A rule that was accurate when it was written is injected with the same authority a year later.

The session layer fails by being read as recall. SQLite holds messages, tool calls, tool results and durable events, while streaming text, reasoning, tool-input and compaction deltas are transient ^[8]. That makes an old session reopenable and inspectable, and it stops there: the data stays scoped to its session unless another component explicitly reads it ^[9]. There is no embedding index, no vector retrieval path, no user-profile store and no fact confidence model doing that reading ^[11].

The working-context layer fails by omission. When a request grows too large, model-visible history is replaced by a generated compaction checkpoint ^[6], and later requests continue from that checkpoint plus recent context while the old history stays durable in the database ^[10]. Surviving a long session by summarizing it is not the same as the runtime having picked the important parts ^[15]. The transcript still contains the constraint you gave early on. The model does not.

The belief that a memory manager exists has a traceable origin. One provider-specific prompt carries a narrow file-memory convention, but core neither manages nor retrieves that file as a memory service ^[12]. The `/init` command looks like learning and is not: it asks the active agent to create or improve AGENTS.md after the user invokes it ^[13]. That is close to what produced the case that started the investigation, where guidance sat in Markdown files outside the repository and every new session followed it ^[3], because an agent had written those files through an ordinary file tool at the user's request and a project-local instructions config loaded them on every provider turn ^[4].

The delta worth acting on sits in the instruction layer, and it is a shrinkage. The desktop-compatible path under `packages/opencode` accepts four kinds of instruction source: AGENTS.md, optional CLAUDE.md, configured local files, and HTTP instruction sources ^[14], ^[1]. The V2 `InstructionContext` under `packages/core` observes AGENTS.md files only ^[14], which removes three of the four ^[16]. If your standing rules live in CLAUDE.md or in a file named only in config, the V2 path does not load them, and since the loader has no maintenance duties ^[7], nothing in the pipeline is responsible for telling you they went missing. The HTTP source in the legacy path is worth a separate look for the opposite reason: it means the system prompt for every turn can include bytes fetched from a remote host ^[14].

The author is explicit that this reading tracks named files in the current tree, including `session/instruction.ts`, `session/compaction.ts`, `core/src/instruction-context.ts` and `core/src/session/sql.ts` ^[2], and that where the legacy and V2 paths diverge the difference is called out rather than flattened ^[1]. That is the right posture for a subsystem that only exists as a habit of speech.