Chapter 5 · Multi-Agent & Team Harnesses · Lesson 5.5
Fighting Drift & Governance
A shared harness rots as many hands add to it - keep it lean the same way you keep code lean.
- Chapter 0 · Sprint Zero
- Chapter 1 · The ratchet & the practice loop
- Chapter 2 · Spec-driven development in depth
- Chapter 3 · Scaling & trusting the harness
- Chapter 4 · Measuring & evolving the harness
- 5.1 · When to add a second agent
- 5.2 · Orchestration patterns
- 5.3 · Worktrees & parallel isolation
- 5.4 · The team harness
- 5.5 · Fighting drift & governance
When many hands touch one file
The moment you commit the harness as a team asset (Lesson 5.4), a new problem shows up. Now several people add rules to the same rules file. And people are optimistic: someone reads about a "best practice" and drops in a line "just in case", someone else adds a note for a bug that a newer model no longer makes, and old scaffolding for a workflow you dropped months ago just sits there. Nobody deletes, everybody adds. The file bloats.
That slow bloat has a name - harness drift: a shared harness thickening as unearned rules and stale scaffolding pile up. It is the exact enemy of the lean, earned rules file you built in Lesson 1.2. Solo, you fight it with willpower. On a team, willpower is not enough, because no single person is watching the whole file.
Why drift scales the damage
Recall the core cost from Lesson 1.2: the rules file is pasted into the model on every turn, so every line spends attention budget again and again. An unearned line does not just sit there harmlessly - it competes with the lines that matter and makes the agent a little worse at the thing you actually care about.
Solo, one bloated file makes one person's agent worse. On a team, that same file is cloned by everyone, so a bloated shared harness makes everyone's agent worse at once. Drift is the mechanism that quietly scales the damage from one seat to the whole team.
Govern the harness like code
The fix is not a new tool - it is a habit you already trust for source code. You do not let anyone push arbitrary lines to main without review, and you should not let anyone push arbitrary lines to the harness either. Treat the rules file, the skills, and the hooks as reviewed code with an owner and a delete key.
- Review rule changes in PRs. A line added to the harness gets the same scrutiny as a line of code. The test is unchanged: every added line still needs a real failure behind it - that is the ratchet. No named failure, no merge.
- Assign an owner. One person owns the rules file and guards what goes in, the way a module has a maintainer. Shared with no owner is how drift wins.
- Prune on model upgrades. A better model outgrows old workarounds. Scaffolding a new model no longer needs is dead code - delete it, the same way you delete a function nothing calls.
- Measure with the eval set. Run Chapter 4's eval set after harness changes. If a rule stops helping the score, it has stopped earning its place, so it comes out.
The ratchet at team scale
None of this is a new discipline. It is the same ratchet from Lesson 1.1 - add a line only after a real failure, remove it when a better model makes it redundant - just applied by a group with shared ownership instead of one person with good intentions. Review, ownership, and pruning are simply how a team keeps a ratchet honest when many hands can turn it.
That is the deeper point of the whole chapter: harness engineering is a team practice, not a personal hack. The lean, earned, disposable file is not a solo virtue you happen to share - it is something the team maintains together, the way it maintains any other shared asset. Osmani frames the underlying discipline plainly in Agent Harness Engineering: lean and earned, every line traceable to a failure.
Check yourself
Harness drift means the file -
Drift is the slow bloat of a shared harness as many hands add unearned rules and stale scaffolding. A file that shrinks or that a model compiles is not drift.
A bloated shared harness hurts -
Every unearned line spends attention budget on every turn, and the shared file is cloned by everyone - so bloat degrades the whole team's agents at the same time.
Governing the harness means you -
Treat the harness like code: review changes in PRs, assign an owner, and prune on model upgrades, so every line still traces to a real failure. Adding freely and never deleting is exactly how drift wins.
Do this now (5 min)
Open your team's shared rules file - or your own, if you work solo. Read it top to bottom and find one line that no longer has a real failure behind it: a "best practice" nobody can trace to anything that broke, or scaffolding for a workflow you have since dropped.
Delete it. That one line is drift, and cutting it is drift reversed. If you can't name the failure a line prevents, it hasn't earned its place.
You've completed Chapter 5
One breath to see how far this got. Chapter 4 taught you to measure the harness. Chapter 5 taught you to scale it in two directions. Across agents: add a second one only for isolation, parallelism, or diversity; orchestrate with named shapes; and isolate parallel work so runs don't clobber each other. Across people: commit the harness as a team asset, then fight drift with governance so the shared file stays lean.
And here is the throughline of the whole course. The model is the commodity - it changes under you every few months, and everyone can rent the same one. The harness is your edge. You build it (Chapter 1), spec-drive it (Chapter 2), scale it safely (Chapter 3), measure it (Chapter 4), and work across agents and teams (Chapter 5) - and through all of it you keep it lean, earned, and disposable. Now go keep ratcheting on real work: every failure you meet is one more line the harness can learn.
Go deeper
Primary source (read this): Addy Osmani - Agent Harness Engineering. The clearest single essay on lean, earned rules and treating the harness as an artifact you tighten, not a thing you set up once.
Wisdom (test it on people): the HumanLayer community argues hardest for lean, earned rules files - the right crowd to pressure-test your team's governance habits against.