A playbook for platform leads: one org baseline, one pack per team, a manifest in every repo, rollout by pull request — and drift you can measure instead of suspect.
Mohammad Omar · Jul 19, 2026 · 7 min read
Picture a normal mid-size engineering org: five teams — frontend, backend, platform, data, security — forty-odd repos, and every developer using an AI coding agent daily. Ask what the org's AI setup is and you'll get five different answers, none of them written down. Each team's AGENTS.md files forked from whichever repo came first; each developer's laptop carries a private stack of skills and permissions nobody else has seen. I hit the single-player version of this across my own 23 repos. At team scale the same drift compounds by headcount — and the fix has the same shape. Here it is as a playbook.
Don't start by writing the perfect config. Start by diffing what exists: every AGENTS.md, CLAUDE.md, .cursor/rules, and copilot-instructions.md across every repo. You're looking for three things: the conventions everyone already agrees on (your baseline, discovered rather than invented), the conventions teams genuinely differ on (your team packs), and the stale instructions actively steering agents wrong (your first fixes). In every org I've looked at, the third bucket is the shock — instruction files untouched for a year, still confidently describing an architecture that no longer exists, read by an agent on every single task. npx baselane audit automates this inventory for a repo; a diff and an afternoon works too.
The structural mistake is one giant org-wide instructions file — too generic to help the data team, too noisy for security to trust. The factoring that works is the one package managers taught us: a small org baseline pack (commit conventions, review discipline, secret-handling rules, the things that are true everywhere), plus one pack per team owning its domain — frontend's component and testing patterns, data's pipeline conventions, security's hardened permission set. Five teams, six packs, each versioned and owned by the team it serves, not by a central doc nobody maintains. A repo composes what applies to it; layering is the manifest's job, not a wiki page's.
Each repo then declares its harness in a committed harness.json, with exact pins:
{
"$schema": "https://baselane.sh/harness.schema.json",
"version": 1,
"target": { "kind": "repo", "id": "checkout-web" },
"packs": {
"@acme/org-baseline": "3.0.0",
"@acme/frontend-taste": "1.2.0"
}
}This one file is what makes team scale tractable, because it turns three unanswerable questions into lookups. What is this repo's AI setup? Read the manifest. Who's on the current security baseline? Read every manifest and compare pins — that's a script, not a survey. What changed? git log harness.json. Tooling materializes the packs into the files each agent actually reads, writing only inside marked managed regions so each repo's own content — build commands, local warnings, team quirks — is never clobbered. Exact pins only: "latest" is how you get an unreviewed convention change landing in forty repos at once.
Never push config silently — not to repos, not to laptops. Every adoption and every update lands as a normal pull request that the owning team reviews and merges on its own schedule. Silent pushes convert drift (annoying) into mistrust (fatal): the first time a team finds their instructions changed under them, they stop believing the standard is theirs. Sequence it: start with the team that felt the pain most, let their repos prove the baseline for a couple of weeks, fold what they correct back into the packs, then open PRs to the next team citing the first. Partial adoption isn't failure — a repo pinned to last quarter's baseline is a repo that says so in a file, which already beats every org running on vibes.
Once manifests are everywhere, governance stops being meetings. Updating the security baseline is a pack release plus pin-bump PRs — you can see, per repo, exactly who has merged it. Drift becomes computable: install receipts record the hash of every written file, so a mismatch means a human deliberately changed something. Surface it and ask — it's either an improvement that belongs upstream in the pack, or a divergence worth a conversation. Never auto-revert; the fastest way to kill adoption is tooling that fights the developers it serves. And a fleet dashboard — which is all baselane's Fleet view is, reading every manifest and comparing pins — replaces the quarterly "AI transformation" slide with an actual number.
Inventory what exists before inventing anything. Factor into one baseline pack plus one pack per team, each owned by its team. Declare per repo with exact pins in harness.json. Roll out and update by pull request, one team first, never silently. Govern by diffing manifests, and treat human edits as signal, not noise.
None of this requires believing in any particular vendor — the manifest spec is open, and the playbook works with a diff, a script, and discipline. The tooling that automates it — audit, materialize, drift-check, fleet view — is what I'm building as baselane. Either way, the principle is the one that already runs the rest of your engineering org: version it, pin it, review it, and make "what are we actually running?" a question with one answer.