An agent fixes a difficult bug on Monday. On Thursday, a second agent meets the same failure and starts from zero. The missing piece is not a larger prompt. It is a maintained record of what the team learned, why the fix worked, and when that knowledge stops being trustworthy.
That is the useful meaning of compound engineering memory. It is an editorial model for durable engineering context, not a named memory product inside Compound Engineering. The current Compound Engineering workflow contributes solution documents and maintenance commands; Claude Code contributes instruction and auto-memory mechanisms; a code knowledge graph can add structural context as an external layer. Those systems have different owners and failure modes, so treating them as one feature creates more confusion than reuse.
What Compound Engineering Memory Means
Compound engineering memory is the part of the workflow that makes a solved problem cheaper to recognize and reason about the next time. It should preserve a small amount of high-value context:
- repository rules that should guide many tasks;
- validated solution records for recurring problem classes;
- limited task history when it explains a decision;
- revision-aware facts about code structure, when an external system supplies them.
The official Compound Engineering repository does not document a feature named “Compound Engineering Memory.” Its current ce-compound skill identifies one durable learning from the completed work and writes it to the repository's solutions/ directory. A separate ce-compound-refresh skill reviews those documents for stale, overlapping, or conflicting guidance. [CE-COMPOUND-20260724] [CE-REFRESH-20260724]
This distinction matters. Memory is not every transcript, search result, or note an agent ever produced. It is selected evidence with an authority level, an owner, and a review date. A repository becomes easier to work in when the agent can find the right record quickly and can also tell whether that record still applies.
For the structural foundation, see Knowledge Graph for AI Coding Assistants. The scale-specific transition is covered separately in Compound Engineering Large Codebase Memory.
Memory Layers in the Workflow
A practical stack has four layers.
First, repository instructions such as CLAUDE.md state stable rules: build commands, test expectations, architectural constraints, and working conventions. Claude Code loads these instruction files into context, which makes them appropriate for concise guidance that should affect most sessions. [ANTHROPIC-MEMORY-20260724]
Second, Compound Engineering solution documents explain validated problem-solution pairs. The current ce compound workflow writes one focused learning rather than a generic session summary. That keeps the record closer to an engineering runbook than a diary. [CE-COMPOUND-20260724]
Third, task history provides temporary evidence. The current Compound Engineering plugin can inspect session history in its fuller compounding path, but that history is an input to distillation, not the durable artifact itself. [CE-COMPOUND-20260724]
Fourth, an external code knowledge graph can represent relationships such as “handler calls service,” “type implements interface,” or “test covers endpoint.” That layer is not part of the official plugin. It is a proposed integration pattern for teams whose repositories need queryable structural context.
Where Memory Breaks Down
Memory fails quietly. A note can remain plausible after the code has changed. Two solution documents can recommend different fixes because they were written for different releases. A task transcript can preserve an abandoned hypothesis next to the final explanation. An inferred code link can outlive the commit that supported it.
The search phrase Compound engineering plugin often collapses these layers into one thing. The safer model is to decide which layer should answer each question and which source has authority.
Three controls reduce that risk.
Provenance records where a claim came from: a file and revision, an issue, a test result, or a reviewed solution. Scope says which service, version, or configuration the claim applies to. Status distinguishes proposed, validated, superseded, and expired records.
The current ce-compound-refresh workflow is designed to find stale and overlapping solution documents, then route meaningful changes through review. [CE-REFRESH-20260724] That is useful maintenance, but it does not make every note correct automatically. Teams still need a named owner for high-impact guidance and a rule for resolving conflicts.
Expiration should be based on evidence, not age alone. A stable explanation of a protocol may remain valid for years. A workaround tied to a specific dependency version may expire at the next upgrade. The memory record should carry the condition that invalidates it.
How Code Knowledge Graphs Help
Markdown is good at explaining why. It is weaker at answering structural questions across thousands of changing files. A code knowledge graph can complement solution documents by making relationships explicit and queryable.
In a proposed external design, every graph fact should include its source revision, extraction method, confidence, and access scope. An agent could then ask for the callers of a changed function, the tests linked to those callers, and solution documents associated with the same subsystem. The graph narrows the search space; the solution document explains the reasoning behind a previous fix.
Graphify can be evaluated as one possible external code graph layer, but that is not an official Compound Engineering integration. The useful contract is vendor-neutral:
- retrieve structural facts for the current revision;
- link facts to reviewed human or agent-authored explanations;
- show provenance in the agent response;
- fall back to repository inspection when evidence is missing or stale.
A graph should not be treated as a truth oracle. Generated edges can be incomplete, dynamic calls can be hard to resolve, and branch differences can invalidate otherwise correct facts. The gain is better navigation and auditable retrieval, not certainty.
Limits and Governance Notes
The memory stack needs governance proportional to its effect. A typo in a local scratch note has low impact. A repository-wide instruction that changes migrations or authorization checks has high impact and should require review.
Keep repository instructions short and stable. Anthropic's current guidance recommends concise CLAUDE.md files and warns that overly large instruction files consume context and reduce adherence. [ANTHROPIC-MEMORY-20260724] Put detailed, situation-specific learning in solution documents that can be retrieved when relevant. Keep raw transcripts temporary unless a compliance or debugging requirement justifies retention.
For an external graph, define who can ingest private repositories, which branches are indexed, how deleted code is removed, and whether sensitive identifiers can appear in embeddings or logs. A structural fact should be revision-aware, and any cross-link to an issue or pull request should respect the source system's permissions.
Finally, measure usefulness with controlled tasks. Compare the same repository revision, task, model, and tool configuration. Record retrieval latency, irrelevant context, correction rate, and whether the final answer cites evidence. Do not infer a universal token-saving percentage from one successful session.
FAQ
Who should own memory cleanup?
The team that owns the affected subsystem should own the meaning of its durable records. A platform or developer-experience team can maintain templates, refresh jobs, and retention rules, but it should not silently decide whether an authentication or data-integrity workaround is still valid. Assign a reviewer in the solution document and route high-impact changes through normal code or architecture review.
How should teams handle conflicting notes?
Do not merge them into a vague compromise. Record the scope and evidence for each note, reproduce the relevant behavior on the current revision, and mark one record as current only after review. Keep a link to the superseded record when it explains historical behavior, but remove it from default retrieval.
When should old solutions expire?
Expire a solution when its stated assumptions no longer hold: the referenced code is removed, a dependency version changes, the underlying incident class is eliminated, or a newer reviewed solution supersedes it. Time-based review reminders are useful, but the invalidation condition is more informative than a fixed age.
What is compound engineering in AI?
It is a workflow in which completed engineering work produces reusable knowledge for later work. In the current Compound Engineering plugin, that includes planning, review, and a compounding step that captures a durable solution. [CE-README-20260724] It does not mean saving every conversation forever.
Conclusion
Compound engineering memory works when each context layer has a narrow job. Instructions define stable rules. Solution documents preserve validated reasoning. Task history remains temporary evidence. A proposed external code graph supplies revision-aware structural links.
The operational test is simple: can an agent retrieve a relevant claim, see where it came from, know whether it applies to the current code, and discover who can correct it? If any part is missing, the repository has accumulated notes, not reliable memory.
Leave a Reply