Split or Merge

Draw the boundary as data: this role receives X and may call Y and is done when Z. If X, Y, and Z are the same for two names, they are one agent. Extra names are a costume. Costumes invoice like people.

A contract here is not a legal PDF. It is a small object you can compare: input shape, tool set, stop predicate. The previous lesson said when a split can be honest. This lesson is the review move: put two proposed personas on the table and ask whether their contracts differ. If you cannot show a difference, you are proposing a soap opera.

Merge is the default. Split is the exception you can justify with a row in the contract table. Teams that skip this review accumulate intern, intern-2, manager, director, and a critic who all call search and all stop when the paragraph “feels done.” That is one policy with five system prompts and five traces to debug.

The contract table

Write three columns before you write personas.

Receives. A researcher that must see raw HTML is not the same as a writer that must see a 200-word brief. If both see the full ticket plus the full wiki, they share context. Shared context plus shared tools is one agent.

May call. Tools are the teeth. search plus finish is a different job from edit plus run_tests. refund is a different job from both. If both names can call the same writes, you did not isolate anything. You duplicated a dispatcher.

Done when. “Helpful” is not a check. has_cite, tests_green, refund_posted_and_hitl_ok are checks. If both roles stop on “looks good,” they share a stop. A shared stop plus a shared allow-list is one policy.

You split when one of these is true:

• Dangerous tools must not sit next to each other (coder vs billing)
• The context the first role needs would drown the second (logs vs patch)
• Done means different checks (citations vs tests vs a paid refund)

You merge when:

• Both can call the same writes
• Both stop on the same “looks good” vibe
• The only difference is the system-prompt nickname
• You added a “manager” so someone would pick the next speaker (that is orchestration, later — not a third hat with the same tools)

Walkthrough: intern, manager, coder, research

Four names walk into a design review.

Intern. Tools: search, finish. Done: helpful. Sees the user ticket.

Manager. Tools: search, finish. Done: helpful. Sees the user ticket. System prompt says “you are senior.”

Coder. Tools: edit, run_tests. Done: tests_green. Sees a typed brief plus the repo.

Research. Tools: search only. Done: has_cite. Sees the web or the log dump. Returns a brief, does not finish the user-facing job.

Intern versus manager: same tools, same done, same inputs. Merge. The senior sentence does not change the dispatcher. If you needed someone to assign work, that is a supervisor with a different contract (assigns, does not search), not a manager who also searches.

Coder versus research: different tools, different done. Split can earn its keep. Coder versus intern: different tools and different done. Split.

If someone proposes “director” who also searches and also stops when helpful, you already know the answer. Merge into the intern/manager blob, then rename the blob to one agent.

Run to execute this in your browser. Nothing is sent to a server.

What printed: intern versus manager is True then merge. Coder versus research is False then split. Coder versus intern is False then split. The function only compares tool sets and done strings. That is enough for this review. If you later add “receives,” compare that field too: two roles with different tools but the same drowning context may still be a bad split.

Flip manager’s done to plan_valid and give it no search — only assign. Then intern and manager would no longer match. That is a real supervisor, not a hat. Do not invent that change in a prompt. Change the object.

Nicknames, committees, and fake critics

A nickname is a string in a system prompt. It does not change Y or Z. If your framework makes it easy to add agents by pasting a persona paragraph, you will add them. The contract table is the brake.

A committee of three “experts” who all search and all vote in chat is still one allow-list. Voting is not a done-check unless you reduce votes with a rule (majority label, then a verifier). That pattern belongs to swarms and debate, with caps. It is not “add Expert 2.”

A fake critic shares the worker’s write tools or shares the worker’s “looks good” stop. Then you have two workers. The next part of this track gives the critic no writes and a rubric. Until those differ, merge the critic into the worker and keep the tests.

What goes wrong if you skip the merge

You will debug tone. Why did Manager sound annoyed. Why did Intern ignore Manager. The traces will be four novels. Cost will rise with no quality win. A forbidden tool will be “someone’s” because every name can call it. On-call will not know which policy to freeze.

You will also delay the real design: the typed brief, the hop list, the blackboard. Personas feel like progress. Contracts are progress.

How agents use this

In a design review, show the tool list and the done-check on one slide. If you cannot show a difference, you are proposing a soap opera. Refuse to merge this review with “we will figure out orchestration later.” Orchestration is who speaks. It is not a reason to duplicate an allow-list.

Put same_contract in the repo next to the role catalog. A unit test can add a new persona and fail if it collides. That is cheaper than a postmortem titled “we had two refund agents.”

When product asks for a “team,” translate: which contract row is new? If the answer is “a grown-up voice,” merge and hire an editor for the system prompt of the one agent. If the answer is “billing must not clone the repo,” split and write the allow-list.

Deleting a persona is a valid ship. The baseline lesson will ask you to prove the remaining team still wins. Merge first when the contracts match; then measure.