stopping the build, starting the integration
The early position was build, and it was argued with conviction: wrap an existing agent runtime, then fork it, then accumulate local changes. The strategic document of that period insisted the thing was a different category rather than a better tool. It was right about the category and wrong about the method.
The reversal came from an audit, not from fatigue. The question asked was whether the local fork was a natural extension of the upstream primitives or a competing implementation. Checked against upstream conventions rather than asserted, the answer was extension: the same event envelope, the same hook family, the same test conventions. In the same period a capability study found that a surface the design had been leaning on was inert in the shipped version, which is what building against an assumed interface buys you.
So the method changed. Defects found in production were reproduced, fixed locally, and then offered upstream as reports with the fix attached. Publication was gated on full local proof rather than on confidence, and the upstream request was narrowed to a seam: expose the runtime backend so an external supervisor can own the process, instead of maintaining a divergent copy forever.
The cost is real. We no longer set the roadmap of a component we depend on, review happens on somebody else's schedule, and we argue our case in public rather than deciding alone.
What this proves: the team will abandon a sunk cost and a defensible narrative when the evidence says integration is cheaper, and prefers a smaller surface with a voice upstream to a larger surface nobody else can inspect.
drawn from: commit cluster
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.