Notes on AI, coaching & building AIHQToronto

Seven Agents, One Codebase, and the Rule That Stopped Them Overwriting Each Other

What running a small business on a team of AI agents taught me about permissions, reviews, and saying no to automation.

Several glowing computer monitors on a cluttered desk at night, with sticky notes, cables and coffee mugs

AIHQ is the software that runs my business: the AI coach, the marketing, the reports, the security on my websites. Most of it is written by AI agents, and there are seven of them, from five companies.

  • Claude Code (Anthropic) reviews architecture and ships features.
  • Replit Agent owns deployment.
  • RT, an agent I configured as a marketing lead, runs content.
  • Codex (OpenAI), Gemini (Google), Grok (xAI) and Muse (Meta) are on probation, building a track record.

They share one codebase and one message channel. The first time two of them edited the same file, neither noticed. The second time, I lost an afternoon of work. That was when AIHQ got its first real rules.

Rule 1: claim the file before you touch it

A few files are dangerous to edit at the same time, like the server’s startup file and the database schema. Before touching one, an agent posts a claim to the shared channel: which file, why, and for how long. Other agents see it when they start up. When the work is done, the claim is released, and if nobody releases it, it expires.

It’s the same thing a team of people does with “I’m in the spreadsheet, don’t touch it,” written down where a machine can read it.

Rule 2: a different model checks the work

Every change gets a second set of eyes. When the eyes are also a model, they have to be a different one.

An agent that reviews its own work agrees with itself, for the same reasons it made the call in the first place. So for anything risky (the database, security, payments, anything that runs on its own all day), the work goes to an agent from a different company before it merges. Claude’s work goes to Codex, and Codex’s to Claude.

The instruction matters as much as the reviewer. “Any thoughts?” gets a polite yes. The request has to say which call the author is least sure of, and ask the reviewer to break it.

This has paid for itself. One change shipped while its review was still pending. The review came back afterwards and found a real bug, plus a claim in the commit message that wasn’t true. Now a pending review blocks the merge.

Rule 3: “done” is a claim, not a fact

Agents report their own work optimistically. “Posted.” “Fixed.” “Safe to delete.” I’ve watched each of those turn out wrong, including an agent that deleted a folder of the system’s memory files while fixing a real problem, and reported a message it never sent.

The rule now: before anyone accepts “done,” they check the real thing. Was the message actually posted? Does the original problem still happen? What’s actually inside the folder?

Rule 4: if a fix fails twice, stop

If two attempts at the same bug haven’t fixed it, a third attempt by the same agent is usually the same idea again. After two, the agent has to bring in a different one.

What I didn’t automate

The agents can write code all day. What they can’t do alone: publish to my live websites, or change the rules above. Those still come to me, and this article did too.

None of these rules is clever. They’re what you’d write down for any team. The difference is that an AI team follows the written rules exactly, and nothing it was only told.