Every team I talk to about baselane asks a version of the same question: how do we keep everyone on the same AI setup? Nobody asks which agent to use anymore. Everyone uses several. The question is how five teams and dozens of repos stay on one standard without a full-time babysitter. This is my answer.
Mohammad Omar · Jul 18, 2026 · 6 min read
The question usually arrives with a backstory. A team lead noticed that frontend and backend produce visibly different code from the same AI tools. Someone diffed two repos' AGENTS.md files and found they disagreed about things the org supposedly settled months ago. A security lead found an agent running with permissions nobody remembers approving. And whoever brings it up has already tried writing down the recommended setup on a wiki page, sharing it, and hoping. It didn't work.
I recognize the story because I lived a miniature version of it. One person, 23 repos, a ~/.claude folder with 369 skills. No two of my repos had the same instructions. If I couldn't keep my own repos aligned through discipline, five teams never will. Drift isn't a diligence failure. It's just what config does when there's no machinery underneath it.
Team drift has a property solo drift doesn't: it compounds through people. Every new repo forks its instructions from whichever repo its creator touched last, so conventions spread like mutations rather than releases. Every developer's laptop accumulates a private stack of skills, rules and permissions that works great for them and is invisible to everyone else. When someone improves a convention, the improvement lands in one repo and stops. There is no channel for "this is better, everyone should have it" besides a Slack message that half the org scrolls past. The result is that the org's real AI setup is unknowable. Not bad. Unknowable. You can't review, secure, or improve what you can't even enumerate.
A wiki page describing the blessed setup is a suggestion, not a system. It has no distribution and no feedback loop. A shared template repo fixes day zero and does nothing for day ninety, which is when drift actually bites. A sync script that overwrites each repo's files gets reverted within a week, because per-repo content is real and developers are right to defend it. Centralizing everything into one giant org-wide instructions file fails in the other direction: too generic to help the data team, too noisy for security to trust, owned by everyone and therefore no one.
The shape that holds is the one that already keeps every other shared thing in an engineering org honest. The org's common ground (commit discipline, review rules, secret handling) becomes a small versioned baseline pack. Each team owns a pack for its own domain: frontend's component patterns, security's hardened permission set. And every repo declares what it uses, with exact pins, in a committed harness.json:
{
"$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"
}
}Tooling expands the packs into the files each agent actually reads, and it writes only inside marked managed regions, so each repo's own content never gets clobbered. The manifest is what turns the unanswerable questions into lookups. What's this repo's setup? Read the file. Which teams are on the current security baseline? Compare pins across manifests. That's a script, not a survey. Improving a convention becomes a pack release plus pin-bump pull requests, reviewed and merged by each team on its own schedule. Nothing lands silently, on a repo or a laptop. The first silent overwrite a team discovers is the last day they trust the standard.
When a team asks "how do we keep everyone on the same setup," what they're really asking for is the thing every other part of their stack already has: one answer to what are we running, who's on it, and when did it change. Git gave them that for code. Package managers gave them that for dependencies. The instructions, skills and permissions steering their AI agents still run on folklore, and that's configuration that writes code into their repos every day. Give it the same machinery. Version it, pin it, distribute it by pull request, and measure adoption instead of asserting it. That's the whole answer, and it's boring on purpose.
The manifest spec is open at github.com/baselane-sh/harness.json. It's useful with zero tooling: one small file any human or agent can read. The tooling that automates the rest (audit, materialize, drift-check, a fleet view across every team) is baselane. If your team is asking this question, npx baselane audit on one repo is the ten-minute way to see where you actually stand. The step-by-step rollout is in the companion post: How to manage AI-harness config across five teams.