The Compounding Software Company

I. Thesis

Compound engineering taught us a small but profound lesson: when an agent plans, builds, and reviews a piece of work, the most important step is the one that comes after — compounding. The agent writes back what changed, what was learned, what to do differently next time. That codified lesson is what makes the next agent cheap.

Without the compound step, every agent re-derives context from scratch. With it, context accrues. Knowledge becomes capital. The system gets smarter without anyone having to reason about it.

The insight started in engineering. The plan-build-review-compound loop runs inside a repository, against code, with the lesson recorded in internal docs for agents. But the loop generalizes. Not every action a company takes fits this shape — but many do. Shipping a feature. Fixing a bug. Drafting a blog post. Publishing a changelog. Each is a plan-build-review-compound loop. And the compound step is what makes the next version of the company cheap.

All of this rests on one architectural commitment: the whole company lives in the repo.

As much of the company as possible — the running app, the API, the marketing site, the docs, the changelog, the blog, the wiki, the decisions, the runbooks, the entities — lives in the same monorepo, in source-controlled, agent-readable files. The marketing site is code. The docs are markdown. The strategic notes are markdown. Customer profiles, incident histories, and the projection maps that bind everything together: all markdown, all in the same diff.

Without this, the surfaces sit in different systems — Webflow over here, Notion over there, Intercom in another corner — and no agent can read across them easily. No diff can show what changed across them, no Compounder can see the full picture easily. With it, every surface is in the same repo as the wiki that governs it. The same agent can read, build, and compound the whole thing in one pass.

This is the Compounding Company: a software company organized so that every action ends by writing the lesson back, every surface stays coherent because the graph forces it to, and every agent inherits the full context of everything the company has ever learned.

The principles

1. The whole company lives in the repo.
2. The compound step is non-optional.
3. Surfaces stay coherent because the graph forces them to.
4. New agents inherit context. They don’t rediscover it.
5. Compounding has no end state.

II. How the system works

The architecture has three layers and four roles. Each layer has a clear job; each role has a clear contract. Nothing is implicit.

The three layers

Signals are events flowing in from the world. Errors caught in production. Performance regressions. Product analytics. Support tickets. Feature requests. Customer calls. Signals are passive feeds; they do not contain truth on their own. They are raw input that humans or agents decide what to do with.

Compound Memory is the layer we are focused on. It is a collection of markdown files. It lives in the same monorepo as the surfaces, so every change to either flows through the same diff. It holds three kinds of knowledge:

• Decisions — ADRs, theses, strategic notes. What the company believes, and why. Slow-moving, narrative, foundational. New work consults Decisions before acting so the team doesn’t re-litigate questions that already have answers.
• Runbooks — procedures, post-mortems, playbooks. How to act in known situations. Event-driven, operational. New incidents check Runbooks before re-deriving a fix from scratch.
• Entities — features, components, incidents, integrations. Each entity is a junction node carrying a projection map: a list of paths, globs, and prose describing exactly where that entity appears on every surface in the company.

Surfaces are where the company speaks — to users, to machines, to itself. They split into two zones:

• Product Surfaces — the running app, the API/CLI/SDK/MCP, documentation, the changelog. Where the product lives. Built and reviewed by engineering with technical-fidelity rules.
• Marketing Surfaces — the marketing site, the blog, social posts. Where the story lives. Written and reviewed with narrative and audience-fit rules.

The split between Product and Marketing matters. They have different agents writing for them, different review cycles, different governance. Product surfaces are subject to drift checks against entity facts. Marketing surfaces are subject to softer review of positioning, tone, and customer voice.

The four roles

Triager, Builder, Storyteller, and Compounder are shapes of work that flow between the layers. Each can become an autonomous agent in time, but in any starting version of a Compounding Company they are simply patterns of work — done by people, increasingly with AI assistance, following well-defined contracts.

• Triager — “the work of making sense of incoming signals” — describes the shape of triage work without saying anything about Memory destinations or specific entity types.
• Builder — “the work of shipping product” — describes engineering work as it already exists, no claims about which Memory artifacts it reads or writes.the Compounder.
• Storyteller — “the work of telling the company’s story” — describes marketing work as it already exists.Compounder.
• Compounder — Surfaces → Memory. The return arrow. After any Builder or Storyteller action, the Compounder writes the lesson back: updates the entity, adds an ADR if a decision was made, drafts a runbook if a new pattern emerged. The Compounder is what makes the next iteration cheap.

Three of these roles run on their own. Triage happens because someone has to act on a Sentry alert; building happens because that’s the job; storytelling happens because there’s a launch to announce. They follow normal incentives, and they will get done whether or not anyone is thinking about Compound as a framework.

The Compounder is different. It is the one role that does not happen by itself. There is no immediate reward for writing the lesson back; it is easy to skip; it is unclear when now is the time. Without it, the whole system collapses — no learning accrues, no surfaces stay coherent, no future work inherits context.

So the Compounder is the one role that needs structural enforcement, from day one. The discipline is simple: any change to a surface must be accompanied by a Memory update in the same change. The Compounder runs before the PR opens, every time. A PR check that flags surface changes without a corresponding Memory update can reinforce this — but the discipline itself is the load-bearing thing.

The projection contract

The most important contract in the system is how Memory connects to Surfaces. Every entity in Memory carries a ## Projections section that lists exactly where it appears on every surface — by path, by glob, with prose commentary describing what each projection should look like.

## Projections

### App
- `surfaces/app/features/subscription-pause/**/*.tsx` — full feature folder.
  Main customer-facing flow lives in `PauseFlow.tsx`; admin config in `PauseSettings.tsx`.

### User docs
- `surfaces/docs-user/billing/pause-subscription.mdx` — the how-to article.
  Tone: instructional, screenshot-heavy. Must reflect the canonical "max pause = 90 days" claim.

### Marketing
- `surfaces/marketing/features/subscription-pause/page.tsx` — the marketing page.
  Hero positioning should match the entity's value statement, in marketing voice.

### API
- `surfaces/api/openapi.yaml` — paths under `/subscriptions/{id}/pause`.

### Changelog
- `surfaces/changelog/2026-03-15.mdx#subscription-pause` — release entry.

Bindings live in the wiki, not in surface files. The wiki is the single place that knows where everything goes. This is unidirectional by design: the entity points outward, not the other way around.

Search is critical, and not having to manually maintain an index is equally important. For a small wiki, grep suffices. As the wiki grows, a markdown-aware search tool like qmd becomes the right primitive. Path renames are handled by preferring globs in projection maps and by search staying current with the actual file contents.

How compounding works

Surface file changes are picked up by the compounder A diff over the surfaces finds what changed. The Compounder compares the new content against the wiki’s claims and either confirms alignment, makes an edit, or adds new entries.

III. What to build first

The Compounding Company is not a product to buy. It is a way of organizing a software company — and a company can adopt it incrementally, in two phases.

The minimum stack. This alone delivers most of the leverage:

1. Stand up Memory in the monorepo. A wiki with three folders — decisions/, runbooks/, entities/ — and a frontmatter schema, living alongside the code and the surfaces so every change flows through the same diff.
2. Adopt the Compounder discipline. Any change to a surface must be accompanied by a Memory update in the same change. The Compounder runs before every PR. A PR check that flags surface changes without a corresponding Memory update can reinforce this; the discipline itself is the thing.

That is the MVP. Everything else is progressive autonomy — useful as the system scales, not required to start.

IV. The principle in one line

Every action ends by writing the lesson back. Every agent inherits the lesson. The company gets smarter without anyone having to reason about it.

That is the entire framework. Everything else is plumbing.