Compound Engineering: How AI Agents Learn From Your Bugs
Using AI agents to debug a memory leak, then capturing those learnings so future agents avoid the same mistakes.
LLM agents have no memory. Every session starts fresh. Ask Claude to fix a bug today, and tomorrow’s session has no idea what you learned.
That’s why Every developed compound engineering—a workflow for coding with agents: brainstorm, plan, work, review, compound. The “compound” step is key: after solving a problem, you document it so future agents can reference it.
But how do agents find those docs? This is context engineering—you have to point the LLM to things explicitly. We add references to CLAUDE.md and AGENTS.md, which appear early in the context window. Vercel’s research confirms this matters: when information is explicitly present, agents use it. When they have to decide whether to look something up, they often don’t.
We’ve been using Every’s compound-engineering-plugin with Claude Code. Here’s how it played out on a real bug.
The Problem
App slowing down over extended sessions. Users refresh to fix it temporarily. Classic resource leak.
Brainstorm Phase
Start with the human-level question: what are we actually trying to solve? The symptoms were vague—“app gets slow.” Could be rendering, could be network, could be memory.
We talked through it: slowdown over time, refresh fixes it temporarily, happens across different pages. That pointed toward accumulating resources rather than a specific component bug.
Plan Phase
Agents researched the codebase and external docs. The issue turned out to be our sync layer—Electric SQL, which streams Postgres data to clients via Server-Sent Events (SSE).
- Found Electric SQL shape subscriptions creating persistent SSE connections
- Searched Electric SQL docs—SSE connections don’t close automatically
- Found retry timeout logic accumulating without cleanup
Key insight: login, navigate, logout, login again—original connections persist. They double.
The plan: cleanup function for all collections, chain it to logout, clear retry state.
Work Phase
Implementation was brief once the plan was clear:
export async function cleanupAllCollections(): Promise<void> {
await Promise.allSettled(
collections
.filter((c) => c !== null)
.map((c) => c.cleanup())
);
// Reset singletons for fresh creation on next access
_quizzesCollection = null;
// ...
}
Chain to logout:
const logout = useCallback(async () => {
await cleanupAllCollections(); // Close SSE connections
clearRetryState(); // Cancel pending timeouts
queryClient.clear(); // Clear cached data
await authClient.signOut();
}, [queryClient]);
Review Phase
Multiple sub-agents analyze the code from different angles:
- Simplicity: Is this the minimal fix? Are we over-engineering?
- Edge cases: What if cleanup fails mid-way? What about session expiry?
- Patterns: Does this follow existing conventions in the codebase?
The review caught one thing: we needed Promise.allSettled instead of Promise.all so cleanup continues even if one collection fails.
Compound Phase
We just fixed a bug. Now we document it so future agents don’t repeat the investigation.
- What happened: SSE connections don’t auto-close, causing memory accumulation
- How we fixed it: Cleanup function chained to logout
- How to verify: DevTools Network tab, filter “EventStream”—connections should close on logout. Heap snapshots should return to baseline.
- How to prevent: Checklist for adding new Electric SQL features
Then added references to CLAUDE.md and AGENTS.md:
## Electric SQL
- Memory management: `docs/solutions/electric-sql-collection-cleanup.md`
- Prevention checklist: `docs/strategies/electric-sql-memory-leak-prevention.md`
Next time an agent touches Electric SQL code, it sees these references and searches the docs during planning. It knows about SSE connection lifecycle. It knows to check for cleanup on logout. It doesn’t repeat the investigation we already did.
Why This Works
The agent starts fresh, but the repository doesn’t. Learnings accumulate in docs. Agent config files point to those docs. Each bug fix adds to the knowledge base future agents can search.
Human developers do this naturally—you remember past bugs, or dig up old notes. LLM agents can’t remember. You have to build their memory for them.