Build1 distinct publisher3 min readPublished
What OpenCode users call memory is an instruction loader, a SQLite event log and a compaction summarizer. Each has a different owner and a different way of losing your project rule.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
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 [5]. Nothing notices when a rule stops describing the code, because there is no service that updates facts when they change [3]. 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 [6]. 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 [7]. There is no embedding index, no vector retrieval path, no user-profile store and no fact confidence model doing that reading [9].
The working-context layer fails by omission. When a request grows too large, model-visible history is replaced by a generated compaction checkpoint [4], and later requests continue from that checkpoint plus recent context while the old history stays durable in the database [8]. 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 [10]. 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 [11]. 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 [1], 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 [2].
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 [12], [13]. The V2 `InstructionContext` under `packages/core` observes AGENTS.md files only [12], which removes three of the four [1]. 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 [5], 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 [12].
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` [14], and that where the legacy and V2 paths diverge the difference is called out rather than flattened [13]. That is the right posture for a subsystem that only exists as a habit of speech.
Ranked by verification strength, evidence, and original report placement.
The article follows the current OpenCode source tree, which contains both the desktop-compatible session path under packages/opencode and the newer V2 runtime under packages/core, and calls out differences between the two paths rather than treating them as one implementation.
Primary code references include packages/opencode/src/session/instruction.ts, packages/opencode/src/session/compaction.ts, packages/core/src/instruction-context.ts, packages/core/src/session/context-epoch.ts and packages/core/src/session/sql.ts.
The investigation began after the author found a local OpenCode project that appeared to remember guidance across sessions; the guidance lived in Markdown files outside the repository, yet every new session followed it.
The session record showed that an agent had created the files through an ordinary file tool after an explicit user request, and a project-local instructions configuration then loaded them on every provider turn; what looked like autonomous memory was user-triggered file authoring plus deterministic prompt injection.
There is no general runtime-managed service in OpenCode that decides what to save, updates facts when they change, and semantically retrieves useful knowledge in later sessions.
What users experience as memory is produced by three mechanisms with different owners and failure modes: instruction files loaded into the system prompt, durable session events and projected messages persisted in SQLite, and old model-visible context replaced by a generated compaction checkpoint when the request grows too large.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific code citations, single unverified reader
The source names concrete files and call paths across both the packages/opencode and packages/core trees and explains its reasoning mechanism by mechanism, which is stronger than assertion-only commentary. But it is one self-published author reading a moving source tree with no commit hash, no release tag, no maintainer or documentation corroboration, and no second publisher in the cluster; several central claims are exhaustive negatives ('there is no X'), which are the hardest form to establish from a single reading.
No adoption signal in cluster
The supplied source reports no release, deployment, benchmark, pricing, licensing or usage figures. It describes one local project the author inspected and gives no indication of how many users rely on the legacy versus V2 instruction paths, so adoption cannot be scored without inventing facts.
Deflationary framing, but absolute negatives outrun proof
The story's direction is anti-hype: it argues that apparent agent memory is prompt injection plus a summarizer, which understates rather than inflates capability. The gap is positive only because the article's own strongest claims are categorical absences asserted from a single unpinned source-tree reading, and the headline generalization ('no memory subsystem') is broader than the evidence a lone reviewer can close, with zero adoption measurement to show scale of impact.
Low commercial stake, mild debunking-authority incentive
The source is an individual developer blog post with no disclosed vendor, employer or affiliate relationship to OpenCode or any competing agent, and it promotes no product or paid offering. The residual incentive is reputational: 'X has no memory subsystem' is an attention-earning framing that rewards confident negative claims, which aligns with the absence of version pinning or maintainer checks.
Internally coherent, externally unconfirmed
Mechanism-level claims are consistent, specific and plausible for an agent runtime of this shape, and the author separates the two code paths instead of blending them. Confidence stays below the midpoint because the cluster has one publisher, adoption is unmeasured, the reviewed revision is unidentified, and the load-bearing claims are absences that a maintainer or a second reviewer could revise.
product
The personal agent is a folder, not a model: four files and less memory than you thought1 distinct publisher
build
Superpowers makes spec-driven work a precondition, then ships it to twelve harnesses1 distinct publisher
build
The AGENTS.md file is an audit of the documentation you never wrote for humans1 distinct publisher
build
The bug in agent memory is not volume, it is that everything recalled has equal authority1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026