An agent team gets faster when each task leaves knowledge behind

Every published a guide called Compound Engineering that states its thesis in one sentence: "The core philosophy of compound engineering is that each unit of engineering work should make subsequent units easier—not harder." The guide is co-written by Kieran Klaassen and Claude, and it comes out of a company that runs five products with primarily single-person engineering teams. The claim comes from practice: the working method of people who ship fast and had to explain why.

The loop it defines has four steps: plan, work, review, compound. The first three are familiar to anyone who has run an agent. The fourth is the one that decides what the next run starts with. For your data engineering agent, the fourth step is the mechanism that separates a team that gets faster from one that re-buys the same knowledge every morning.

Stated plainly, an agent team gets faster only when each unit of work leaves knowledge the next run reads.

Only the fourth step makes the next run faster

The fourth step is where the compounding happens. The guide is explicit: "The first three steps (plan, work, review) produce a feature. The fourth step produces a system that builds features better each time." That sentence carries more weight when the worker is an agent, because an agent starts every session blank.

An agent reads what it is given and nothing else. Everything the previous run learned, saw, corrected and decided is gone unless someone wrote it down in a form the next run will open.

The guide's own examples point at the form. Preferences and project context go into the file the agent reads at the start of every session. Solved problems become searchable documentation so future sessions find them. Repeated taste becomes a skill file.

The operative standard is placement and audience: material written for the next run, placed where the next run reads it, at the moment it needs it.

The guide does not leave the placement vague. "Update the system. Add new patterns into CLAUDE.md, the file the agent reads at the start of every session. Create new agents when warranted."

It points at solution notes too: "docs/solutions/ builds your institutional knowledge because each solved problem becomes searchable documentation. Future sessions will find past solutions automatically."

The names matter less than the rule underneath them. Whichever file your agent opens at the start of every session is the file your team's lessons need to reach.

Two more lines from the guide set the rhythm for the rest of this argument. "When the agent makes a mistake, add a note so that it improves with each correction." And: "After each implementation, document what the plan missed so you can build faster the next time."

Notice who the reader is in both: the next run, which will arrive with no memory of this one.

The same rule already runs in our engineering and go-to-market work

Our own engineering and go-to-market work both run on this rule, and it is the rule we would keep if we had to give the rest back. Plans, review findings and corrections do not stay in the session that produced them. A correction that survives review gets promoted into the rules the agent loads before it touches anything, so the next run starts with the lesson in front of it. Repeated workflows become skills, which keeps the sequence in one place instead of in whoever remembers it.

The same rule is the basis of our productivity claim: the same team ships more with Vibedata. The two measures are time to PR and time per PR, the total human effort per accepted change including spec, review and rework. The gain is conditional on changing what the team focuses on and how it builds, and review compounds as each accepted change shrinks the next review.

The forms are not exotic. Each one is a place a lesson can live.

None of these artifacts exist to impress a reader. They exist to change what the next run does, before it acts.

The guide is also worth reading with its evidence in view, because the numbers it leans on are its authors' own (Every).

"In our experience, first attempts have a 95 percent garbage rate. Second attempts are still 50 percent." The page cites no study, no dataset and no method for the 80/20 or 90/10 splits it uses to frame the argument (Every).

"An hour spent creating a review agent saves 10 hours of review over the next year" is offered as a rule of thumb, not a measurement (Every).

The argument for writing lessons down does not depend on those figures. It depends on something smaller and checkable: whether the next run, starting cold, repeats a mistake the last run already had corrected. Your own review queue will show you that within a week.

The compounding shows up in the small stuff, which is most of data work. It rarely arrives as a grand decision. It arrives as a line in a file that stops a run from making the same wrong turn twice.

The convention the team settled on after the third argument is one example. The workaround that exists because the platform cannot do the obvious thing is another. Each is cheap to write once and expensive to re-derive every session.

The overhead objection is true about documentation and false about the mechanism

The obvious objection deserves to be stated in full. This sounds like documentation, and documentation is overhead. It goes stale, it accumulates, and nobody reads it. The model keeps getting better, which means each task keeps getting faster without any of this effort.

The objection splits into two claims, and each has a boundary and a symptom worth naming.

The first half of the objection is true about documentation written for people. Reference material that describes a system to a human reader does go stale, and it should not be duplicated into the agent's path. A rules file, a skill and a source map are read by the run that is about to do the work. Their job is to change what that run does.

The staleness answer is the part most teams miss. When a rule is retired, the entry that retires it names its successor in the same place. Our own rule files work this way: a retired line is marked as retired and points to its successor, and the changelog keeps both.

An agent that loads the rules can read the supersession in the same file, so the retired shape is no longer the only instruction in front of it. That is stored knowledge. Whether the next run applies the successor is a separate question, answered only when a later run acts and the correction does not recur.

A rule that goes stale and names its successor is a lesson updated. A rule that goes stale in place is a trap for the next run.

The better-model half of the objection does not touch the mechanism at all. A stronger model raises the ceiling on every individual task. It does not remember what your team learned. A new model still starts your next run from zero.

This is the part of the guide worth repeating: "When you treat that work as overhead instead of an investment, the codebase accumulates debt." Swap codebase for data platform and the sentence keeps working.

Data work hides more knowledge outside the schema than software does

Data engineering gives the argument sharper edges than software does, because most of the knowledge an agent needs is not in the schema. Which table is the source of truth for an entity, and which one merely looks like it. Which pipeline is fragile and why.

The same goes for the workaround that exists because the platform cannot do the obvious thing, and the naming convention the team settled on after the third argument.

A model cannot infer any of that, and a schema does not carry it. An agent that starts without it produces a confident first attempt on work the team has already done once, and the review meeting becomes the place where the same correction gets made again.

That repetition is the diagnostic. The first time a correction arrives, it is review feedback. The second time, it is a signal that knowledge is leaking out of the loop. Correcting harder does not help.

The fix is to decide where the lesson gets written so the next run reads it before the mistake is available to be made again.

The test for whether the loop is closed is simple enough to run on a Tuesday.

1. Pick the last three corrections your review produced.
2. For each one, open the file your agent reads before it starts.
3. If the lesson is not there, the loop is open, whatever the review notes say.
4. If it is there, with a line that names the rule and the date it changed, the knowledge is stored. The loop is closed only when a later run acts on it and the correction does not recur.

An agent team changes the character of the loop. A person accumulates context whether or not anyone writes it down; experience lives in the person and shows up in the next task automatically. An agent has no such reservoir.

Write the lesson down and it has a chance to compound. Skip that step and the team's knowledge stays exactly where it was, run after run, while the work keeps accelerating.

That is why the guide's own time split is worth taking seriously: allocate "50 percent of engineering time to building features, and 50 percent to improving the system" (Every). For a solo builder that half is a discipline. For an agent team it is the difference between a curve and a flat line.

Whether or not the number fits your team, the direction is the one to hold onto: the system-improving work is the part that makes next month cheaper than this one.

One question tells you whether your loop is closed

The practice reduces to one test applied to every unit of work: after this task, what will the next run know that this one had to learn? If the answer is nothing, the task was a rental: full price, no equity. If the answer is a rule, a skill, a source map entry or a decision line, the lesson has a place to live. Whether it is paid for twice is settled by the next run that reads it, not by the note itself.

The smallest version of this is available today. Take the correction you made most recently, the one you would hate to make again, and put it where the next run will read it. That single move is the fourth step, practiced once.

The guide closes its argument on the system, so here is the version for your team. Your data engineering agent will pick up its next task soon, probably today. What will it already know that the last one paid to learn?

References

• Every, Compound Engineering: The AI-Native Engineering Philosophy, by Kieran Klaassen and Claude