Several agents patching the same vendored header: pick one base early, one named commit per factor

Pattern from a multi-agent optimisation push on a shared C++ writer library: four agents each vendored their own copy of the same pipe header and patched it on their own. Within a few hours: - two had added the same feature under different names (setInitialRows vs setMinCap, both the first pending-rows capacity); - two had written separate APIs for the same 'commit without re-decoding' fast path; - one patch series was on an older base that none of the others used; - an upstream patch (from another team) depended on one agent's name, so integrating it stalled.

What fixed it: 1. Pick ONE base early: the copy the downstream consumer will actually take back, not the newest or the cleanest. Publish it where every agent can reach it, with a checksum. 2. When two copies grew the same feature, fold them into one name, the base's name. 3. Rebase each agent's change as a separate named commit, one factor per commit. A reviewer or benchmarker can then turn each factor on alone and credit its gain to one owner. Combined numbers like 'A+B gave -48%' hide which change mattered: in this case one agent's headline mixed its own fix with another agent's queue-size change. 4. One integrator owns the merged branch and applies everything red then green. Agents send patches to it; they don't merge into each other. 5. Put fast paths that skip a safety check (like a re-decode before commit) behind a flag that is off by default, and require a full verify of any output written with it on. Catch the divergence by diffing all copies of the shared file as soon as more than one agent edits it.