Running Codex team agents without stepping on each other

The failure that shows up in week two

A team adopts Codex. Everyone is happy for a week. Then two agents touch the same module in the same afternoon, both produce a plausible refactor, and the second merge quietly undoes half of the first. Nobody notices until a test that never ran in CI starts failing on a Friday.

Codex team agents do not cause this. Unowned boundaries do. The agent just makes the collision arrive faster than your review process was built for.

Put the shared rules in the repository

The single highest-value thing a team can do is stop keeping conventions in people's heads. Agents read files. So write the conventions into a file the agent picks up automatically, at the repo root, with more specific files closer to the code they govern.

What belongs in it:

• The exact build and test commands, copy-pasteable, no prose around them
• Directories that must never be edited by hand, and why
• The migration or codegen step that must be re-run after a schema change
• How to add a dependency, including who has to approve it
• What a done change includes: test, changelog entry, whatever your team needs

Keep it short. A thousand-line instructions file gets skimmed by humans and diluted for the model. We push teams toward something under a page at the root, with narrow files added per package as they earn their place.

Split work by boundary

Assign agents the way you would assign a contractor: by area of the system, with an owner who reads the output. Two agents in the same package at the same time is the thing to avoid, and it is easy to avoid once you say it out loud in standup.

Branch per agent run. Small diffs. If a diff is unexpectedly large, inspect why and split independent changes when practical. Preserve useful work; line count alone is not a reason to discard a patch.

What team agents are still bad at

Cross-cutting judgement. An agent working in the payments package will not know that the notifications team is mid-rewrite and depends on the current event shape. It will find the coupling only if the coupling is visible in code, and organisational coupling usually is not.

They are also poor at saying "this ticket should not be built". Expect enthusiastic implementation of bad ideas. The check for that is a human reading the ticket before the agent starts, not a human reading the diff after.

Start here this week

Pick one repository. Write the instructions file, ten to thirty lines, and get every developer to run one agent task against it. Then hold a twenty minute review where you read three real diffs together and argue about them. That conversation produces better team norms than any document we could hand you, and gives you concrete issues to address in the next exercise.

If you want help putting this into practice, talk to us.