A platform team's playbook for going from drift to one governed standard across 23 repos without a big-bang migration.
baselane team · Apr 30, 2026 · 6 min read
We've watched several platform teams go through this rollout now, and the pattern repeats closely enough that it's worth writing down as a playbook rather than a one-off story. The shape is always the same: 20-something repos, somewhere between fifty and a few hundred developers, and an AI tooling situation that grew organically — meaning nobody actually decided it, it just accumulated. What follows is the sequence that worked, drawn from a composite of teams around the 90-developer, 23-repo mark.
The instinct when you're the platform team is to write the ideal standard first and push it everywhere. That's the fastest way to get ignored. The teams that succeeded started instead by connecting their repos to baselane's admin portal and just looking — which repos had any agent instructions at all, which frameworks and test commands were actually in use, where the packs already installed (usually by individual developers, off the record) actually diverged from each other. That inventory alone reset a lot of assumptions about how standardized things already were.
The rollout didn't start with anything ambitious. It started with the single pack every repo could plausibly adopt without controversy — usually a baseline AGENTS.md/CLAUDE.md convention pack with no opinions about workflow, just "here's where commands and constraints get declared." Fit-gating meant the pack only proposed itself to repos whose detected profile matched what it assumed; nothing landed on a repo it didn't fit.
That first pack going out as a PR, getting reviewed, and merging cleanly in most repos within a week did more for the rollout's credibility than any announcement would have.
The unit of adoption that actually mattered wasn't the repo — it was the team that owned it. A repo with three different teams touching it stalls in review longer than a repo with one clear owner, independent of how good the pack is. The playbook that worked: subscribe repos team by team, starting with the platform team's own repos as the dogfooding case, then the teams most vocal about wanting consistency, saving the repos with unclear or shared ownership for last.
It was tempting to push the laptop agent out to every developer at the same time as the repo-level packs, on the theory that it's faster to do both at once. It isn't, in practice — developers who hit a repo-level PR and a background agent change in the same week can't tell which one caused whatever friction they noticed, and support tickets get harder to triage. Sequencing repos first, then laptops once the repo-level standard had settled, kept each change legible on its own.
There was no cutover date. Repos adopted packs as their owning teams reviewed and merged the PRs, on their own schedule, and the coverage view in the admin portal made it possible to see progress accumulate — not push it. By the time most of the 23 repos had converged, it looked less like a migration and more like something that had just happened, one merged PR at a time.