Several AI agents, one repository: the house rules
One AI coding assistant on a website is a careful new hire. Three of them on the same repository, started from different machines by different people, are a newsroom with no editor. Each one begins its session knowing nothing about the others, does good work, and pushes it. The trouble lives in the seams between them. I run several agents on my own sites every day, and these are the rules that keep their work from colliding.
On this page
Why the second agent changes everything
A single assistant's mistakes are easy to see, because every change in the repository is either yours or its. Add a second agent and the history interleaves. Agent A edits a page while agent B rebuilds the same page from an older copy. Agent B's change lands second and quietly reverts A's. Nobody did anything wrong in their own session, and the live site still went backward.
The agents cannot coordinate by conversation, since none of them sees the others' chats. They coordinate only through what is written down in the repository and through checks that refuse bad work. Every rule below is one of those two things.
Give every agent its own working copy
Two agents editing files in the same folder at the same time will overwrite each other between saves, before Git ever sees a conflict. Give each agent its own checkout. On one machine, git worktree add creates a second working folder attached to the same repository, on its own branch, so a long job can run there while another agent works in the main folder. On separate machines, each agent already has its own clone, and the shared repository on GitHub becomes the only meeting point.
Keep one checkout as the live one, the copy a server or a deploy job actually serves from, and let agents change it only by merging finished work into it.
Fetch first, fetch again, and never force
An agent should fetch from the shared repository before it starts and again right before it pushes, because other agents may have pushed in between. If the shared branch moved, the agent rebases or merges, resolves any conflict by reading both versions, rebuilds, and tests again before pushing.
Ban the plain force push in your instruction file. Git's own manual says a force push "can cause the remote repository to lose commits," and with several agents those commits belong to someone else's session. If history truly has to be rewritten, --force-with-lease at least refuses when the branch moved since the agent last looked. On GitHub, branch protection on main enforces the ban whatever the instruction file says.
Also ban long chains that pull and push in one unattended command. When a merge half-fails, some commands still report success, and the next step commits conflict markers straight to production. Pull, look, then push.
Check what a diff hides
Agents review text changes well. They miss the changes a normal diff barely shows: a file that lost its executable permission, line endings flipped on every line, a generated file rebuilt from stale sources. A script that loses its executable bit still looks identical in review, and the first sign of trouble is a deploy that fails with "Permission denied."
Two cheap defenses cover most of it. Make git diff --summary part of the review, since it prints mode changes. And add a test that checks the bit on the files that must stay executable; git update-index --chmod=+x restores it without touching the contents.
One instruction file that every agent reads
Each agent product looks for its own instructions. AGENTS.md has become the shared convention: a Markdown file at the repository root, now stewarded by the Agentic AI Foundation under the Linux Foundation, and read by Codex, GitHub Copilot's coding agent, Cursor, Gemini CLI, Jules, and many others. Claude Code reads its own CLAUDE.md and, according to its documentation, can use an existing AGENTS.md in its place. Write the rules once, in AGENTS.md, and point any other file at it.
Put in it what an agent cannot work out from the code: how to build and test, which checks must pass before a push, what never to touch, and how to name commits. Keep secrets, client names, and anything confidential out of it. On a public repository that file is public, and AI search reads it too.
Make every change traceable
Have each agent start its commit messages with its own name, so the history answers "who did this" without a forensic exercise. Have it leave a short handoff file in the repository when a session ends: what changed, which checks ran, what it could not verify, and what comes next. Keep a changelog with one line per deploy. The next agent, and the next human, start from those files instead of from guesswork.
Let the build referee
Instructions are advice that an agent can misread. A check that fails the build is a rule. Every time agents step on each other, turn the lesson into a check: conflict markers in source files, duplicate titles, a page missing from the sitemap, a hand-curated list that a new page never joined. Make the serious checks fail loudly, and keep the rest as warnings that print on every build, where the next agent will see them.
Finally, give the site one deploy path that every agent uses: fetch, test, back up anything stateful, merge, verify live. When each agent deploys its own way, the shortcuts multiply.
How I handle this for clients
When a team is putting AI coding agents to work on its website, I set up the instruction file, the checks, and the deploy path, and I review what the agents ship with the same eye I bring to an SEO release. For the broader picture, see my guide to AI coding assistants on a website. To talk through your setup, book a call or reach me through Upwork.