The guardrails that let me run multiple AI agents

One of my earliest multi-agent experiments worked because the boundaries were boring.

I assigned agents to individual levels in my game. Each could change its own files. I could rebuild, visit a level, decide what needed work, and send that feedback to the agent responsible for it. Several pieces improved at the same time without much coordination.

Then a machine update took out my open sessions. When I restarted, I reorganized the work around themes: tutorials, controls, bug fixes, UI improvements, and other changes that sounded like sensible projects.

Those themes crossed the same codebase. Eight agents could now make different decisions about shared systems. Changes accumulated into large commits. Eventually, levels stopped loading. Finding the problem took hours, and reverting was difficult because the changes were tangled together.

I had made it easy to start work and hard to recover from it.

Give ownership to a change surface

The rule I use now is one writer per overlapping scope. That can mean a file, a subsystem, or a contract spanning runtime code and an editor. The boundary needs to reflect what can actually change together.

“You own the UI” is usually too broad. “Update this shared list component and its affected callers; another task is investigating layout without editing” gives me a usable division of work.

Read-only work is easier to parallelize. An agent can inspect a subsystem while another examines failures or prepares a review. When two implementation tasks really are independent, both can run. When they meet at a shared contract, I make the dependency explicit and serialize the overlapping edits.

Separate branches help isolate files, but they cannot reconcile incompatible design assumptions for me. Ownership still matters at integration time.

Put the quality bar in the assignment

I use a small task brief:

Outcome: What should be observably different?
Ownership: Which files or subsystem can this task change?
Constraints: Which existing contracts must it preserve?
Evidence: Which check will demonstrate the intended result?
Escalation: Which discovery changes the scope or needs a decision?
Handoff: What changed, what passed, and what remains uncertain?

The evidence line is important. If I cannot describe how I will judge the result, I probably have more thinking to do before delegating implementation.

This brief also lets an agent act without asking me about every reversible choice. I am trying to clarify the decisions that matter and remove friction from the rest. Requiring approval for every small step would throw away much of the benefit.

Make recovery cheap

Small, coherent changes are easier to inspect and undo. They preserve a connection between the problem, the decision, and the evidence. A large diff containing several unrelated improvements breaks that connection, even when every individual edit seems reasonable.

I also keep the current implementation and the latest handoff ahead of old plans. Plans describe an intended future. In a fast-moving project, some of them become archaeology surprisingly quickly. An agent that confidently follows an obsolete design can create more work than an agent that stops to identify the current owner.

The durable information belongs in the repository: sources of truth, build commands, known constraints, and short handoffs. Chat is useful working memory. It is a poor place to store the only explanation of why a decision was made.

A guardrail can become unnecessary work

There is a second failure mode: adding so much verification and coordination that a simple fix becomes a procession of agents and reports.

In September, I changed the repository’s operating rules to default to quick, focused smoke checks. A routine change should receive the smallest meaningful validation, and passing evidence should be reused while the relevant inputs remain unchanged. Broader sweeps have a place, especially for shared behavior and release risk. They should have a reason.

A documentation correction does not need a game build. A small tool change should not automatically trigger a full gameplay campaign. A shared save-system change deserves much more scrutiny. The risk determines the check.

I apply the same reasoning to delegation. One implementation owner is often enough. A reviewer or investigator earns its place when it provides a distinct kind of evidence, not when it repeats the author’s conclusion.

The test for a useful rule

I judge a guardrail by the decision it makes easier. Does it prevent conflicting edits? Catch a failure close to its cause? Make a result reviewable? Let the next session continue without guessing?

If it does none of those things, it may be ceremony.

The rules I kept after that early failure have made parallel work more manageable. They let me grant autonomy with a clearer understanding of what I will get back. That is the kind of process I want: enough structure that I can move quickly and still know where I am.

Related: What an AI agent has to prove before I call it done.