AI config drift: how to keep five teams on one standard

Mohammad Omar opens by noting that no team asks "which agent should we use?" anymore—everyone uses several. The real question is how to keep five teams and dozens of repos aligned without a dedicated person managing configurations. The problem shows up in concrete ways: frontend and backend code from the same AI tools looks visibly different; two repos' AGENTS.md files contradict each other on supposedly settled decisions; security teams discover agents running with unremembered permissions.

Omar traces the root cause to a dynamic he calls configuration drift, which compounds through people. Each new repo forks its instructions from whichever repo its creator touched last, spreading conventions like mutations rather than releases. Every developer's laptop accumulates private stacks of skills, rules, and permissions that work for them but stay invisible to the organization. When someone improves a convention, it 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 organization's real AI setup is unknowable: not bad, but unknowable, and therefore impossible to review, secure, or improve.

Omar documents what teams have already tried and failed. A wiki page describing the blessed setup is a suggestion with no distribution and no feedback loop. A shared template repo fixes day zero (setup) but does nothing for day ninety, 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. A centralized org-wide instructions file fails in the opposite direction—too generic to help the data team, too noisy for security to trust, and owned by everyone and therefore no one.

The solution Omar proposes is to version the standard and declare it per repo using a committed harness.json manifest. The manifest specifies an exact schema (https://baselane.sh/harness.schema.json), version number, target repo, and a set of versioned packs—for example, "@acme/org-baseline: 3.0.0" and "@acme/frontend-taste: 1.2.0". Tooling expands these packs into the files each agent actually reads, writing only inside marked managed regions so each repo's own content never gets overwritten. The manifest itself becomes the single source of truth: reading the file answers what this repo's setup is; comparing pins across manifests answers which teams are on the current security baseline. 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.

Omar frames this as applying the same machinery that already works for code and dependencies. Git gave teams one answer to "what are we running, who's on it, and when did it change?" for code; package managers gave them the same for dependencies. The harness.json manifest does this for AI instructions, skills, and permissions. The specification is open at github.com/baselane-sh/harness.json and is useful with zero tooling—any human or agent can read one small file. The baselane tooling automates audit, materialization, drift-checking, and fleet visibility; running npx baselane audit on one repo is offered as a ten-minute diagnostic to see current configuration state.

The core tension Omar identifies is that configuration drift compounds through people in ways individual drift does not. When one developer forks a repo's instructions from whatever setup they last touched, conventions spread like mutations—uncontrolled, invisible, and immune to organizational intent. A wiki page or shared template does not solve this because it lacks feedback loops and distribution machinery. The real problem is deeper: the org's actual AI setup becomes unknowable, and you cannot review, secure, or improve what you cannot enumerate.

The solution Omar proposes mirrors the machinery that already works for code and dependencies. A small versioned baseline pack captures org-wide commitment (security, review discipline), while each team owns a domain-specific pack (frontend patterns, hardened permissions). Every repo declares its setup in a committed harness.json with exact version pins—the same declarative approach that made Git and npm reliable. This transforms silent, invisible drift into visible, reviewable pull requests. Improvements to a convention become a pack release plus pin-bump PRs that each team merges on its own schedule, ensuring nothing lands silently.