How CE Turns Engineering Experience into a Compound, Reusable System

1. What CE Considers "Memory"

Many agent products equate memory with conversation history, automatic summaries, long context, or user preferences. These are useful, but they are not what CE values most.

CE truly values three durable artifacts:

docs/brainstorms/

docs/plans/

docs/solutions/

These correspond to three different layers of system cognition.

1. docs/brainstorms/ : Problem Definition Layer

Here the focus is not on "what we talked about" but on defining the problem, its boundaries, and success criteria.

For example,

docs/brainstorms/2026-03-29-testing-addressed-gate-requirements.md

contains a very complete structure:

Problem Frame

Requirements

Success Criteria

Scope Boundaries

Key Decisions

Outstanding Questions

The most important value of this document is not to preserve the discussion, but to turn the discussion into an artifact that a subsequent planning step can consume directly.

2. docs/plans/ : Technical Decision Layer

Correspondingly,

docs/plans/2026-03-29-001-feat-testing-addressed-gate-plan.md

is not a rewrite of the requirements; it adds another layer of information:

Requirements Trace

Context & Research

Key Technical Decisions

Implementation Units

System‑Wide Impact

Risks & Dependencies

The interesting part of this plan is that it is not a to‑do list; it records how the issue is organized at the technical level, making the knowledge reusable for future similar tasks.

3. docs/solutions/ : Validated Experience Layer

This layer generates the compound returns. It does not contain ad‑hoc notes; instead, it stores structured solution documents defined by ce:compound and ce:compound‑refresh.

The repository shows clear categorisation:

docs/solutions/skill-design/

docs/solutions/developer-experience/

docs/solutions/integrations/

docs/solutions/workflow/

docs/solutions/best-practices/

This demonstrates that CE is not merely remembering "we fixed a bug" but is preserving knowledge units that can be retrieved and reused by future agents.

2. ce:compound Does Not Write Docs, It Encodes a Solution Process into the Knowledge System

The skill file plugins/compound-engineering/skills/ce-compound/SKILL.md illustrates CE’s method. Its goal is not to ask you to summarise experience, but to design a fairly complete knowledge‑writing pipeline.

1. First Use Parallel Sub‑agents for Evidence Collection

In Full Mode, CE launches at least three parallel tasks:

Context Analyzer

Solution Extractor

Related Docs Finder

These tasks respectively:

Extract problem classification, metadata, and file ownership from the context.

Extract the structural body of the solution.

Search existing documents, identify relations, and assess overlap.

The key point is not the parallelism itself but CE’s understanding of knowledge writing: it is a structured extraction, not free‑form prose.

2. It Distinguishes Bug‑Track and Knowledge‑Track

ce:compound

reads references/schema.yaml and references/yaml‑schema.md to separate documents into different tracks. For example:

Bug track focuses on symptoms, root cause, solution, and prevention.

Knowledge track emphasises context, guidance, why it matters, and when to apply.

This distinction matters because solving a bug and distilling a design principle are fundamentally different kinds of knowledge.

3. It Decides Whether to Create, Update, or Merge

Phase 2 is not a blind file creation. Related Docs Finder performs an overlap assessment:

High overlap → update the existing doc.

Medium overlap → create a new doc but mark it for possible consolidation later.

Low overlap → normal new creation.

This mature approach prevents the knowledge base from becoming a chaotic pile of duplicated articles.

3. CE’s Knowledge Is Not a "Doc Pile" but Searchable, Assessable, Refreshable System Components

1. Solution Docs Have Structured Frontmatter, Not Ad‑hoc Notes

For instance,

docs/solutions/skill-design/discoverability-check-for-documented-solutions-2026-03-30.md

includes explicit frontmatter fields:

title

date

category

module

problem_type

component

severity

applies_when

tags

Another example, docs/solutions/skill-design/beta-skills-framework.md, shows the same metadata awareness. This shows CE wants experience written as objects that future agents can search, filter, and consume.

2. learnings‑researcher Is the Retriever of This Knowledge System

The agent file

plugins/compound-engineering/agents/research/learnings-researcher.md

teaches how an agent consumes the knowledge base. Its workflow is:

Extract keywords from the task description.

Perform category narrowing.

Use a grep‑first filter to pre‑select candidates.

Read the frontmatter of each candidate.

Score and rank the candidates.

Return distilled summaries.

The insight is that a knowledge base is valuable only when it can be consumed at low cost; reading the entire repository each time would be a burden.

3. repo‑research‑analyst and ce:plan Pull Past Experience into Current Decisions

Phase 1 of ce:plan explicitly runs repo‑research‑analyst and learnings‑researcher. This shows that CE’s planning is not based solely on the current requirement and code; it actively incorporates what the team has previously learned about similar problems.

4. Writing Alone Is Not Enough for a Compounding Knowledge System; It Must Also "Refresh"

When knowledge accumulates, two new problems appear: stale knowledge and overlapping knowledge. CE addresses this with the skill

plugins/compound-engineering/skills/ce-compound-refresh/SKILL.md

, which models knowledge maintenance as five possible outcomes:

Keep

Update

Consolidate

Replace

Delete

The skill also stresses two important points:

Avoid low‑value churn just to leave a review trace.

Evaluation must consider not only accuracy but also whether the document remains a correct knowledge unit.

A truly compounding system must accept that knowledge is not better when it merely grows; outdated, duplicate, or misleading knowledge harms the system.

5. CE Even Writes a Solution About Whether Knowledge Is Discoverable

The solution

docs/solutions/skill-design/discoverability-check-for-documented-solutions-2026-03-30.md

discusses a system‑design problem rather than a business bug. Its key points are:

Root instruction files serve as a universal discovery surface.

Discoverability should be assessed semantically, not by simple path greps.

Additions should be small and informational, not forced command‑style rules.

This demonstrates that CE treats the discoverability of the knowledge system itself as a first‑class design object.

6. These Intermediate Artifacts and the Knowledge System Are Not Soft Agreements; They Are Tested

The repository contains two contract tests:

tests/pipeline-review-contract.test.ts

tests/review-skill-contract.test.ts

These tests do not run business logic; they verify the workflow and skill contracts themselves. For example, pipeline-review-contract.test.ts checks:

Whether ce:work still enforces code review.

Whether ce:work‑beta mirrors the stable version.

Whether ce:plan explicitly handles blank test scenarios. review-skill-contract.test.ts checks:

The modes and orchestration boundaries of ce‑review.

Alignment of the findings schema with downstream skills.

Whether stack‑specific reviewers follow a unified structure.

This shows that CE’s workflow, knowledge loop, and agent contracts are not merely documented expectations; they are continuously enforced rules.

7. Putting CE Back Into the "Superpowers" Context Clarifies Its Uniqueness

If you are familiar with superpowers, you can see that CE’s difference lies in treating the whole process as a closed‑loop system. Superpowers emphasises single‑delivery discipline (brainstorming, writing‑plans, TDD, verification, sub‑agent‑driven development). CE, on the other hand, focuses on cross‑iteration knowledge feedback and system compounding.

8. Five Practical Methods CE Offers for Building an Experience‑Accumulating Agent System

Don’t treat memory as only context. Context expires and is unstable; true reusable memory must be an artifact that future skills and agents can actively consume.

Separate documentation by cognition layer. CE keeps docs/brainstorms, docs/plans, and docs/solutions separate because they solve different levels of problem.

Knowledge writing must be structured. Without frontmatter, categories, fields, and conventions, a knowledge base quickly degrades into a pile of articles that are hard for both humans and agents to search.

The system needs a retriever. In CE, the role is fulfilled by learnings‑researcher, which extracts, filters, ranks, and returns distilled summaries.

The system needs a refresh mechanism. ce‑compound‑refresh shows that a truly compounding system must maintain the freshness and boundaries of its knowledge units.

Conclusion

Many AI‑agent workflows appear to have brainstorm, plan, review, and docs stages, but CE’s core distinction is that it treats these stages as components of a closed‑loop system. Requirements are not chat logs, plans are not temporary drafts, and solutions are not post‑mortem notes; they are system components that future agents will continue to consume.

References

https://github.com/EveryInc/compound-engineering-plugin