Multi-agent software engineering

Several agents work on one piece of software, each with a role. One plans, one builds the interface, one builds the server side, one writes tests, and sometimes a coordinating agent routes work between them. The appeal is parallelism and focus. An agent scoped to one role carries less context, and many agent mistakes come from holding too much at once.

It is real, and it is further from routine than it is usually presented. The layer page covers what the rung costs as a whole: coordination becoming the work, your attention as the ceiling, review volume and running costs. This page is about what splitting the work by role adds on top.

What it is for

Work that splits along seams that already exist. A contract between client and server that both sides build against. A test suite written from the specification rather than from the implementation. A mechanical change that touches many files in the same way. Where the seam is real, separate agents can work without stepping on each other, and their outputs meet at a point you defined in advance.

Where the seam is invented for the sake of parallelism, the agents meet somewhere you did not plan, and that is usually in your review queue.

Who it suits

Engineers who already review a single agent's output well and work from a written specification. Teams whose codebase has clear module boundaries and a test suite that can judge each part on its own.

It does not suit someone looking for speed on the lower rungs. If one agent with a good brief is not yet reliable for you, several agents will not be either.

How to tell this is your category

• More than one agent works on the same change at the same time, each with a role.
• The roles follow parts of the system or kinds of work: interface, server, tests, review.
• The agents share a contract or a specification, and each one's brief names it.
• If instead one piece of work passes through different tools in turn, planned in one and built in another, that is AI-orchestrated development, the other category on this rung. The two often combine.

What it costs you later

• Integration is yours. Each agent's output can be correct on its own and wrong in combination. Two agents agree on an interface only if that interface was written down before either of them started. The contract is what they share, not the conversation.
• Ownership has to be written down. Without a list of which agent owns which files, two agents will change the same one. On a shared working copy the later write quietly wins. On separate branches you meet the clash as a merge conflict, which is the better of the two outcomes.
• Context drifts. Each agent's picture of the task moves as it works. A decision one agent makes is invisible to the others unless it lands somewhere shared, such as the specification or the repository itself.
• The contract becomes load-bearing. Once several agents build against a contract, changing it mid-flight means checking every agent's work against the new version. Change the contract between rounds of work, not during one.
• A role that reads too much stops being a seam. A test agent that can see the implementation tends to write tests that describe it, and then the suite confirms the code rather than the specification. Keep the test role working from the specification alone, or the independent check you split out is not independent.
• A coordinator is one more agent to review. When a coordinating agent splits and routes the work, its decomposition is a set of decisions too, made as plausibly and as silently as any other. If you did not write the split yourself, read it before the work starts, because a wrong split is paid for in every task beneath it.

How to tell it is working

Merges are uneventful. When something needs to change, you change the specification rather than relaying a message from one agent to another. Every agent's task ends with a check that can pass or fail before integration, so a broken part is caught at its seam rather than after assembly.

A brief that holds an agent to its seam names the contract it builds against, the files it owns and the check that closes the task. It can be this small:

role: client
goal: Call the orders API from the checkout page
contract: specs/orders-api.yaml
owns:
  - src/checkout/orders/
leave_alone:
  - src/server/
done_when:
  - the client tests pass against the examples in the contract
  - every endpoint in the contract has at least one test

If you find yourself copying output from one agent into another by hand, the split is in the wrong place.

When to stay with one agent

If the work cannot be written as independent tasks with outputs you can check, one agent working from a good specification will finish sooner and leave less to untangle. Multiple agents are a way to scale a method you already have, not a substitute for one.