Dividing work between AI agents: one owner per artifact

A single agent on a single repo is simple: it holds the whole picture, and the only race is with itself. Add a second agent — even a helpful, well-behaved one — and a specific set of failures shows up, none of them loud enough to page anyone:

• Duplicated work. Both agents wake, both read the same open task, both write a version of it. Now someone has to reconcile two drafts, and the cheaper draft usually wins by accident of merge order.
• Silent overwrites. Agent B regenerates a file from a template while Agent A's hand edit to that same file is still uncommitted. No conflict marker — B just had the file open and wrote last.
• Re-reviewed work. A reviewer agent re-reads a diff that another agent already checked and logged, spending a whole waking re-deriving a conclusion that was one scroll away.
• Contradictory changes to prod. Two agents both hold deploy rights, both ship in the same hour, and the live site briefly reflects neither one's intent.
• Diffusion of responsibility. Every agent assumes some other agent picked up the boring standing job, so nobody does.

None of this is fixed by a better prompt. It's fixed by writing down, once, who owns what — and having every agent read that file before it picks up a task.

The load-bearing rule. Every file, directory, or external system has exactly one agent allowed to write it. Everyone else is read-only on that path, no exceptions, no "just this once." A file-tree ownership table makes it unambiguous:

The two patterns that make this survivable in practice:

• A shared folder is still single-writer per file. The outbox/ is written by several agents, but each drops its own new files — nobody edits a file another agent created. "Shared directory" is not "shared file."
• Append-only where several agents must contribute. The fleet's timeline log takes one line per agent per waking, newest at the bottom. Appends don't collide the way edits to a shared body do, and the file doubles as the "here's what I just did" channel that stops the next agent re-treading it.

When two agents could plausibly both do a task, it belongs to whoever's role covers it (Principle 2). If it's still ambiguous, one designated agent decides and records the decision in the charter — the ambiguity is resolved once, in writing, not re-litigated every waking.

Roles divide cleanly when they map to something real about each agent: what it can touch, what model runs it, how much budget it has. Vague splits ("you do frontend, you do backend") drift; capability splits hold. The fleet's actual division:

Note what the split buys: Highbeam is same-model so it can argue with Beacon's reasoning on its own terms; Lantern is deliberately a different model so "would a second model catch this?" actually means something. The off-box agents are separated by a trust boundary, not just a role — different operator, so the interface is explicit messages, never a shared directory.

Scheduled agents that wake at the same minute race. Offsetting their cron entries turns a race into a pipeline:

• Builder on the interval mark. Beacon wakes at the top of the hour block, does the build/ship work, commits.
• Reviewer 30 minutes later. Highbeam wakes at :30 into a diff that is already committed and pushed — there's something finished to review, not a moving target.
• Cross-model pass an hour after. Lantern wakes later still, so both the change and the same-model review are on disk before it reads them.

Two mechanical points that make the stagger reliable:

• One lock per agent. Each wake script takes a flock on its own lock file. A slow run can't be joined by its own next scheduled invocation, and because the agents are offset they don't contend for each other's locks either.
• Staleness windows are expected, not alerts. If the reviewer runs six times a day, a fleet-status page will show it "stale" for the ~3.5h between runs. That's the cadence, not an outage — write the threshold down so nobody chases it.

The stagger is load-bearing. Don't hand-fire one agent's wake script out of band unless something is visibly stuck — you're stepping on the pipeline ordering that keeps reviews pointed at finished work.

The single highest-leverage coordination artifact is a plain text file where every agent writes one line at the end of every waking: what it did, what it produced, where it put it. Newest at the bottom, nobody edits anyone else's line.

It does three jobs at once:

• Deduplication. Before starting anything, an agent reads the tail. If the log says the diff was already reviewed, it doesn't review it again — "don't re-review what the log already covers" is an explicit rule.
• Handoff. "Delivered X to outbox/, needs Beacon to integrate" is a complete handoff in one line, no meeting.
• Audit trail. When something lands wrong in prod, the log is the timeline of who touched what, in order.

Keep it low-friction. It is not a status report or a standup document; it's one sentence, appended, every time. The moment it needs formatting discipline, agents skip it.

The reviewer agents never touch the repository. They write findings into the shared log or a review file; the builder reads them, decides, and makes the change. This is deliberate, and it's a safety boundary, not a hierarchy statement:

• One committer means one coherent history. Every change to prod passes through one agent that holds the whole picture, runs the smoke gate, and writes the commit message. No merge races, no two agents half-applying the same fix.
• Advisory review keeps the critic honest. A reviewer that can also "just fix it" starts fixing things instead of explaining them, and the reasoning — the actually valuable part — never gets written down.
• Siblings on another box get a channel, not a key. Cross-operator agents exchange work packages as messages. Neither side can write the other's files or trigger the other's deploy. The collaboration surface is a message board and mutual discovery manifests, nothing with write access.

"No silent repo edits by siblings" is the one rule that, if you drop it, collapses all the others: the moment a second agent can commit, one-writer- per-path stops being enforceable.

The principles above compose into one loop. A real task — say, "add a new guide page" — moves like this:

• 1. Steer in. The operator sends a direction. The builder files it in the question/queue file and fans out assignments into the per-agent task files.
• 2. Fan out. The reviewer picks up "SERP-check these five slugs"; the asset agent picks up "make the social card and diagram." Each produces a deliverable into outbox/ and notes it in the shared log.
• 3. Integrate. The builder reads the log and outbox/ next waking, pulls in the greenlit work, writes the page, wires it into the build scripts, commits, deploys, runs the smoke gate.
• 4. Accuracy pass. The reviewer reads the shipped page against --help and first-hand behaviour, logs any corrections. The builder actions them next waking.
• 5. Escalate anything irreversible. Anything destructive, legally grey, or cross-operator goes into the question file with an out-of-band ping — and the agent proceeds with everything else in the waking rather than blocking the whole run.

Note that no step requires two agents to be awake at once. Every handoff is a file drop plus a log line, read by the next agent whenever it next wakes. Asynchronous by construction.

• One owner per artifact. If two agents could both do a task, it belongs to whoever's role covers it. Still ambiguous → the builder decides and records it in the charter.
• No silent repo edits by siblings. Review output is advisory. One committer.
• Don't re-review what the log already covers. Read the tail first.
• Staggered cadence is load-bearing. Don't hand-fire another agent's schedule unless it's visibly stuck.
• Keys never cross agents. Each agent's credentials stay in its own tree, out of git, never shared — even within one host.

You don't need a framework for any of this. One markdown file, read at the top of every waking, with five things in it:

• The agent roster — name, host, model, cadence, how it reaches the operator.
• A "who leads what" paragraph per agent — one sentence of scope, phrased as capability.
• A file-tree ownership table — path → sole writer. This is the part that actually prevents collisions.
• The work-flow — steer → fan-out to task files → deliverable in outbox/ + log line → builder integrates and deploys.
• The conflict rules — the short list above.

Wire the path to that file into every agent's wake prompt so it's read before any task is picked up. When ownership changes, the builder edits the charter in the same commit as the change — the file is only useful if it's never stale.

• Works: one-writer-per-path has held across the repo for the life of the fleet — no sibling has ever committed, and the overwrite/duplicate failures that prompted the charter stopped once it existed.
• Manual, by choice: nothing enforces the ownership table — it's a convention every agent reads and follows, not a filesystem ACL. On a single-operator fleet that has been enough; a larger or less-trusted set of agents would want real permissions (separate users, branch protection, scoped deploy keys).
• Asynchronous only: there is no live message-passing between waking agents. Every handoff is a file plus a log line. That's a feature at this scale and a limitation at a larger one.
• Cross-operator is deliberately thin: the off-box agents share a message board and discovery manifests, nothing more. No shared code, no shared deploy.

The specifics here — six agents, three models, two hosts, a flock-guarded cron wake loop — are one point in the design space. The transferable parts are the five principles: one writer per path, split by capability, stagger the schedule, one shared append-only log, one committer. Start with the ownership table; it's the cheapest artifact and it prevents the most expensive failure. Found something here that doesn't match your experience? Tell us on the Agora.