Every engineering org now has a small crowd of AI agents working alongside its developers – Claude, Copilot, Cursor, Codex – whatever has been approved within the organisation. Each one is only as good as the context it is given to work with: CLAUDE.md, copilot-instructions.md, and of course the open format AGENTS.md. These files are the README of the agent world. By giving consistent context to each agent, you are giving each one a personality transplant, the difference between an agent that writes idiomatic, on-standard code and one that’s just guessing from whatever it can infer off the file tree and its training. We all know the potential that generative AI has to write volumes of code, but the greatest challenge organisations face is making sure AI doesn’t accelerate your development in the wrong direction.
Context files are the closest thing an AI agent has to onboarding, and right now, many organisations give every repo a slightly different one. The trouble is that “onboarding” only works if it’s the same onboarding everywhere. In my current organisation, that stopped being true almost as soon as we had more than a handful of repos. A context file gets written for one repo, and it never automatically finds its way to the other ninety-nine. Someone updates the coding standards after a retro, commits it to the repo they’re sitting in, and the update lives there and nowhere else. Six months later, Claude Code enforces one naming convention in one repo and a subtly different one in another, Copilot suggests EF Core in a repo whose standard is Dapper, and nobody notices until a PR review turns into an argument about which file is actually right.
That’s a worse problem than it sounds. Inconsistent AI-generated code isn’t as obvious as a bug, it appears as a deliberate style choice, and it quietly erodes the standards your team have strived so hard to get alignment on.
Context files need the same rigour as the standards they encode
This was a problem I wanted to solve before it got out of hand, so I built a small governance repo which sits at the heart of our GitHub Org, whose job is to make sure the AI context layer – plus a few adjacent repo settings – stays identical across every repo that is opted in.
Distributing context files without breaking the ones already checked out
The core mechanism is a scheduled GitHub Actions workflow that treats context files as a set of canonical sources of truth, continually evaluated against the target repo’s, not a one-time seed:
standards/AGENTS.mdstandards/CLAUDE.mdstandards/.github/copilot-instructions.mdstandards/.cursor/rules/project-standards.mdc
Every day the workflow checks each governed repo’s copy against them, byte for byte, on whatever integration branch changes land on there (develop if it exists, otherwise the default branch). When drift is detected, the workflow doesn’t push the fix straight to a protected branch, it opens a Pull Request. This has the same benefit any other peer review would, a safety net that keeps automated context distribution in check. However it also has the supplementary benefit of highlighting to engineers exactly how the agreed standards have been implemented, with control over how and when they are entering their workflow.
The AI context files are managed as a group, but the workflow also allows for independent files, like .editorconfig and .gitignore. These files are just as important for keeping repositories consistent, but because they do occasionally change (for example, when a team introduces a new tool) the GitHub Actions mechanism works well here too.
Underneath, it’s mostly careful bookkeeping. It doesn’t raise a duplicate PR if one’s already open for that branch, doesn’t open a PR with no real commits behind it, and always diffs against what’s live on the target branch rather than assuming state. Unglamorous, but it’s exactly the kind of bookkeeping a person maintaining this by hand across a hundred repos would eventually get wrong or give up on.
A supporting layer: settings that shape how both humans and agents can act
Context files aren’t the only thing that governs an AI agent’s behaviour, the repo’s own GitHub settings play a part too. A second, simpler workflow runs daily and enforces all the niggly little GitHub preferences onto every governed repo. This includes deleting HEAD branches after merge and disabling GitHub features we don’t use (wikis, issues and projects so that they aren’t diluting existing usage of Confluence, Jira or whatever you use for work tracking. Dependency scanning and vulnerability alerts are also enabled consistently across repos to prevent non-compliance with DevSecOps standards.
This is deliberately the smaller half of the story. It exists because a consistent AI-agent experience isn’t just about what an agent reads, it’s also about the environment it’s operating in, and keeping this working within the same guardrails as the humans.
Why not GitHub’s built-in answer
GitHub’s more “correct” long-term mechanism here is custom properties combined with Enterprise Cloud rulesets structured metadata enforced centrally, no scheduled workflow required. For now, my organisation is on GitHub Teams, where that isn’t available, so the governed topic plus a scheduled workflow is the pragmatic equivalent: an opt-in experience for the person tagging a repo, built out of a couple of Actions workflows instead of a licensed platform feature. It’s likely the organisation will transition to Enterprise Cloud, at which point swapping the topic check for a properties check is a small, contained change and everything downstream keeps working.
What this solution bought us
In short, less manual work, far better consistency, and less confusion about which file is ‘right’. When the architecture standards change after a design review, every governed repo gets a PR within a day, reviewed like any other change, instead of the update quietly living in whichever repo it was first written in. Claude, Copilot, and Cursor end up reading the same coding standards, the same architecture principles, the same CI/CD conventions, in every repo — which is the actual precondition for trusting an AI agent’s output to look the same regardless of which part of the codebase it’s touching.
It’s a small piece of infrastructure (two workflows and a folder of canonical files) but it gets rid of a failure mode that’s easy to miss until it’s already caused a bad PR: an AI agent doing exactly what it was told, just by a file that nobody remembered to update.
Treasure Your Exceptions 