Compound Engineering: How Every's Agent Plugin Turns Code Reviews into Reusable Knowledge

Most agent workflows treat each session like a blank slate. You ask for a code review, the agent reads the diff, writes feedback, and forgets everything when the context window closes. The next review starts from zero. Every’s Compound Engineering plugin (18K stars, trending #1 TypeScript) flips this. It stores brainstorms, plans, and reviews as durable artifacts on disk so future agent runs can read past decisions without re-prompting.

Unlike vector stores that embed and retrieve approximate matches, file-based artifacts preserve exact wording and decision context. This avoids lossy embeddings and keeps the full reasoning chain intact. The plugin ships commands for Claude Code, Codex, and Cursor that coordinate planning, execution, and review into a loop where each cycle makes the next one cheaper.

The 80/20 Inversion

Traditional dev workflows spend 80% of time writing code and 20% planning or reviewing. Compound engineering inverts this: 80% planning and review, 20% execution. The idea is that a good plan shrinks the implementation, a good review catches patterns (not just bugs), and a good compound note means the next agent does not have to learn the same lesson from scratch.

The plugin provides five core commands:

/ce-strategy: Captures product problem, approach, persona, and metrics at STRATEGY.md
/ce-brainstorm: Generates requirements and writes them to a durable artifact
/ce-plan: Reads the brainstorm, writes an implementation plan
/ce-code-review: Reviews code and writes feedback
/ce-compound: Extracts reusable knowledge from the session and appends it to a compound notes file

An optional /ce-ideate command sits upstream of the loop. Use /ce-ideate when exploring multiple architectural approaches before committing to a single brainstorm. It produces a ranked ideation artifact, not requirements or plans.

Artifact Storage and State Boundaries

The plugin persists artifacts as Markdown files in the project directory. STRATEGY.md holds the product anchor. Brainstorm and plan outputs go into timestamped or named files. Compound notes accumulate in a shared file that agents read at the start of each session.

This creates a clear state boundary:

Ephemeral: LLM context window, tool call results, in-flight reasoning
Durable: Markdown files on disk that survive session termination

When an agent runs /ce-plan, it reads STRATEGY.md and the brainstorm artifact before generating the plan. When it runs /ce-compound, it extracts patterns from the current session and appends them to the compound notes file. The next agent session reads those notes as grounding, so it does not re-derive the same architectural decision or code style rule.

Coordination Between Commands

The commands do not share in-memory state. They coordinate through file reads and writes. Here is the typical flow:

/ce-strategy writes STRATEGY.md
/ce-brainstorm reads STRATEGY.md, writes brainstorm-YYYY-MM-DD.md
/ce-plan reads both files, writes plan-YYYY-MM-DD.md
Agent executes the plan (outside the plugin, using standard code generation)
/ce-code-review reads the plan and the diff, writes review-YYYY-MM-DD.md
/ce-compound reads the review and session history, appends to compound-notes.md

Each command is a discrete LLM call with a specialized prompt. The plugin does not maintain a stateful orchestrator. It relies on the human or agent to invoke commands in sequence and on the file system to carry state between invocations.

Concurrency and Merge Strategies

The current implementation does not include file locks or append-only logs. If two agents try to compound knowledge simultaneously, both will read the current compound notes file, generate their additions, and write back. The second write overwrites the first.

This is a known trade-off. The plugin targets single-developer workflows where one agent session runs at a time. For multi-agent scenarios, you would need to add:

File locks (flock, lockfile package)
Append-only writes with atomic renames
Merge strategies that detect concurrent edits and prompt for resolution

The current design optimizes for simplicity and local dev environments, not distributed agent swarms.

Observability and Failure Modes

The plugin does not expose structured logs or telemetry. Observability is file-based: you inspect the artifact files to see what the agent wrote. If a command fails (LLM timeout, malformed output), the artifact is incomplete or missing.

Common failure modes:

Failure	Symptom	Mitigation
LLM timeout during `/ce-plan`	Plan file is empty or truncated	Retry the command, reduce brainstorm size
Concurrent writes to compound notes	Lost updates	Run one agent at a time, or add file locks
Stale `STRATEGY.md`	Plans drift from product goals	Re-run `/ce-strategy` when goals change
Compound notes grow unbounded	Slow reads, context overflow	Periodically archive or summarize old notes

The plugin does not auto-retry or checkpoint intermediate state. If a command fails, you re-run it manually.

Deployment Shape

The plugin is an npm package (@every-env/compound-plugin) that integrates with IDE agent extensions. It does not run as a standalone service. The deployment shape is:

Local: Plugin installed in the IDE, artifacts written to the project directory
No server: No API, no database, no cloud dependency
Single-user: Designed for one developer or one agent session at a time

For team workflows, you would commit the artifact files to version control so other developers (or agents) can read them. This turns the file system into a shared knowledge layer, but introduces merge conflicts when multiple people compound knowledge in parallel.

Code Example: Reading Compound Notes

Here is how an agent might read compound notes before generating a plan:

import fs from 'fs/promises';
import path from 'path';

async function readCompoundNotes(projectRoot: string): Promise<string> {
  const notesPath = path.join(projectRoot, 'compound-notes.md');
  try {
    const notes = await fs.readFile(notesPath, 'utf-8');
    return notes;
  } catch (err) {
    if ((err as NodeJS.ErrnoException).code === 'ENOENT') {
      return ''; // No notes yet
    }
    throw err;
  }
}

async function generatePlan(projectRoot: string, brainstorm: string): Promise<string> {
  const strategy = await fs.readFile(path.join(projectRoot, 'STRATEGY.md'), 'utf-8');
  const compoundNotes = await readCompoundNotes(projectRoot);
  
  const prompt = `
You are planning an implementation.

Strategy:
${strategy}

Compound Notes (past learnings):
${compoundNotes}

Brainstorm:
${brainstorm}

Write a detailed implementation plan.
`;
  
  // Call LLM with prompt
  const plan = await callLLM(prompt);
  await fs.writeFile(path.join(projectRoot, `plan-${Date.now()}.md`), plan);
  return plan;
}

Note: This example is safe only for single-agent workflows. Under concurrent writes, use file locks or append-only logs to prevent lost updates.

The key is that compoundNotes is read from disk and injected into the prompt. The LLM sees past decisions without the human having to copy-paste them.

Limitations

The plugin does not include:

File locks or concurrency control for compound notes
Structured telemetry or observability beyond file inspection
Auto-retry or checkpointing for failed commands
Automatic knowledge expiration or versioning

You have to curate compound notes manually, which means they can become a liability if left unmaintained.

When Compound Notes Help vs. Hurt

Compound notes reduce redundant LLM calls when:

The same architectural pattern appears across multiple features
Code style rules are consistent but not enforced by a linter
The team has tribal knowledge that is not documented elsewhere

They add overhead when:

The project is small and context fits in one session
The team already has comprehensive docs and ADRs
The notes grow stale and contradict current decisions

Technical Verdict

Use this plugin when you expect more than three agent sessions per feature and compound notes can reduce re-planning time by at least 15%. It works best for single-developer or small-team projects where one agent runs at a time and artifacts are committed to version control.

Avoid it if you need multi-agent concurrency, structured observability, or automatic knowledge expiration. The file-based design is simple but fragile under concurrent writes. The lack of telemetry makes it hard to debug when a command fails silently.

The 80/20 planning inversion is opinionated. If your workflow is already fast and your agent context is cheap, the ceremony of brainstorm, plan, review, compound may slow you down. But if you are hitting context limits or re-explaining the same patterns, this plugin gives you a durable knowledge layer without standing up a vector database.

Source: GitHub Repository