Agent workflows & conversation styles

You have already built a two-agent system. In module 2.02 a drafter produced the work and a separate critic scored it, and the reason for splitting them was mechanical: everything the drafter wrote was sitting in its own context window, so asking it to judge its own output made agreement the statistically likely continuation. A second agent with an independent context window was the fix.

That is the whole idea behind multi-agent design, and in this module we scale it up. Every agent in a multi-agent system is still the single agent of module 2.01, an instruction written as named blocks that commits a general model to one purpose. What is new is one mechanism that wires several of them together, and it is worth stating now in a form you can carry: one agent’s instruction says who it must consult, and it chooses among them by reading a one-line description of each. Carry that sentence through everything below: each topology is a shape that wiring can take, and each failure mode is a consequence of the wiring being prose.

Two surfaces come out of it. Topology is the shape: who hands what to whom, and whether one specialist runs or all of them do. Voice is how each agent speaks, and it turns out to be the same kind of thing as the wiring, written down as rules rather than emerging from the model. By the end you will be able to pick a shape for a problem and say what it costs, and read a transcript back to the exact line that produced each behavior in it.

what changes when there is more than one agent

Here is the shape of a multi-agent request before we name any of the parts.

A request arrives at one agent, the orchestrator, whose instruction fixes the narrow job it does itself and names the specialists it consults for everything else. It reads the request and decides which specialist should handle it.

How does it decide? By reading each specialist’s description, a short line in the configuration saying what that agent is for. Those lines are the entire routing mechanism: the orchestrator reads them the way you would read a list of colleagues’ job titles and picks one.

The chosen specialist runs with its own instruction, its own tools, and its own independent context window. This is the part that produces the benefit, and the mechanics are module 2.02’s: a window holding one job has no competing instructions diluting its token probabilities, and it sees the orchestrator’s reasoning and the other specialists’ work only if you deliberately pass them along, so the argument for a wrong answer that was sitting in the orchestrator’s window is nowhere in the specialist’s.

Its answer returns to the orchestrator, which either delivers it, sends it to another specialist, or combines several answers into one.

Everything in this module routes this way: the decision lives inside the orchestrator’s own turn, implicit in which specialist it calls. Hold that fact. In module 2.04, once these topologies have become files you can read, you will meet a second method that pulls the routing decision out of the model’s turn and into code, built for the case where choosing a specialist is the orchestrator’s whole job.

four topologies

Nearly every multi-agent system is one of four shapes, or a nesting of them. Take them in the order you should try them.

solo

One agent with good tools, answering directly. No delegation at all.

This is the right answer far more often than people expect, and it is where you should start every design. An agent with a search tool and a database tool handles an enormous range of work without any of the cost that comes next. The Tutor you ran in module 1.02 is this shape.

router

An entry agent whose sole purpose is intent classification and hand-off: it reads the request, matches it against the specialists’ descriptions, and delegates the whole turn to one of them. Its whole mechanism is its instruction. Here it is verbatim from delegation.yaml:

orchestrator:
  name: "RouterAgent"
  instruction: |
    You are a triage router.
    You do NOT answer questions directly if they require specialized knowledge.
    Instead, you examine the user's request and delegate to the appropriate specialist:
    - If the user asks a coding or programming question, delegate to CodeExpert.

subagents:
  - name: "CodeExpert"
    description: "Expert in programming, software development, and debugging."

Read that as: the orchestrator’s instruction holds the contract, saying when to hand off and to whom; each entry under subagents holds a name the contract can point at and a description the orchestrator reads when it decides. Two keys, and the whole router is in them.

Read the shape of that instruction against module 2.01, where an identity block fixed an agent’s “sole purpose” in one sentence. The line beginning “You do NOT answer” is that block doing its job in a router: classification and hand-off are the router’s sole purpose, and the line pins the agent to it. Why does it need saying? Because a capable model asked a coding question will answer it. Answering is the helpful-looking continuation, and your carefully built specialist never runs.

Use a router when requests fall into genuinely different kinds needing different tools, different knowledge, or different tone. Notice that the router is an agent whose whole job is classification. The same shape already appeared at the end of Part 1, in module 1.07, where the classes were how much thinking a request deserves rather than which specialist it belongs to, and sorting requests that way before spending on them turns out to be one of the largest savings available in a production system.

One version of this shape deserves a flag now and gets its full treatment in module 2.04. When the specialist’s answer is the whole reply, with nothing combined and nothing added, the router’s final turn is a copy operation performed by a model, and a model can fumble even a copy. That module shows the method that removes the turn entirely.

decomposer

An agent that splits a task into ordered steps, hands each to a specialist, and merges the results. A manager agent passes raw data to an analyst, passes the analysis to a writer, and delivers the finished document.

Use it when the steps have a real dependency, when step two cannot start until step one has produced something.

council

Several specialists examine the same input in parallel, and an orchestrator weighs their independent answers into one verdict.

The runnable specimen is the Council (config/agents/examples/council.yaml), three agents, every one of them ollama/qwen3:8b on your own machine:

• The Moderator manages the deliberation and renders the verdict. It never argues a side of its own, and its instruction fixes the verdict’s shape: the case for, the case against, and its own judgment in two to four sentences.
• The Advocate builds the strongest honest case in favor, exactly three numbered arguments. Its instruction carries an escape clause that outranks the pressure to argue well, so it can say “the honest case is thin” rather than defending a weak claim anyway.
• The Skeptic builds the strongest honest case against, exactly three numbered objections: risks, edge cases, flaws.

The Council file also sets a temperature per agent, and the numbers are the design: the two specialists run at 0.7 to explore arguments, the Moderator at 0.5 to weigh them. That dial is available here because all three agents are local ollama/ models; several hosted models, current Gemini among them, expose no temperature at all. Hold the detail either way — module 2.04 makes per-agent hyperparameters a schema surface.

Use a council when a question has no single correct lookup and the value is in weighing perspectives: a design review, a risk assessment, a judgment call.

the cost of adding an agent

Before you reach for any shape right of solo, count what it costs, and count it on the specimen. The Council’s live run was three model calls where a solo agent would have made one, and on an 8-billion-parameter model on a laptop those three calls took about 85 seconds end to end. Consulting all three stylists in the Style Council you will meet below tripled its calls the same way. Each delegation is another complete trip through the model, so latency and tokens scale with the number of agents in the reply path.

The second cost is easier to miss. Each handoff passes text between windows, so anything the specialist needed but did not receive is gone. That is the isolation working as designed, and it will bite you the first time a specialist answers without a detail the orchestrator never passed on. Every added agent is one more place for that to happen.

So the rule falls out of the arithmetic:

Add an agent only after one has failed: do not add an agent until a single agent with tools has actually failed at the boundary of specialization. Every extra agent adds latency, a context handoff, and one more thing that can fail.

When has a single agent actually failed? When one prompt has genuinely started fighting itself: the instructions for one job contradict the instructions for another, or one agent needs tools you are not willing to give the rest. Module 2.04 opens by taking that failure apart mechanically. Until you have seen that failure, stay at solo.

Practice the choice below. Each scenario has a shape that fits it, and each wrong pick explains itself:

the delegation contract

We said the orchestrator picks a specialist by reading its description. Look at what that makes the description field. A model acts on it when it routes, so the description is the interface between two agents.

subagents:
  - name: "CodeExpert"
    description: "Expert in programming, software development, and debugging."

Read that as: this is the only text the orchestrator has about CodeExpert when it decides. Write it the way you would write a function signature: what goes in, what comes back, and when to reach for it.

The other half of the contract sits in the orchestrator’s own instruction. In the Council it is one line: “You MUST consult BOTH of your subagents before answering,” followed by the order and the instruction to pass the claim verbatim. That sentence is the entire routing mechanism: a model reads the contract and each description and reasons over both.

The delegation contract. An orchestrator’s instruction says who it must consult and when; each specialist’s description says what that specialist is for; the orchestrator’s model reads both and chooses. Both halves are prose, so both are auditable, and both are where routing failures start.

The failure mode follows from the contract being prose. A vague description produces a system that misroutes, and the misrouting is confusing to debug because every individual agent works correctly in isolation. The strongest syndicates spend real effort on these lines.

Watch the Council run. This is a live run on one laptop, no API key. The Moderator consults the Advocate and the Skeptic, neither of whom sees the other’s answer, then renders its fixed three-part verdict:

Read that transcript back against the file. The Advocate’s first line, “the honest case is thin,” is the escape clause firing: a countable contract of exactly three arguments would otherwise pressure a model to pad, and the clause gave it somewhere else to go. The verdict arrives in the three-part shape the Moderator’s instruction fixed, with the judgment naming which single consideration weighed most and what evidence would change the answer, because the instruction asked for both. Every behavior in that run traces to a line of council.yaml, which is the delegation contract doing everything it can do.

Grade it honestly, though. The escape clause and the “never argue a side yourself” line are prose in an instruction, and module 2.01 was plain about what that buys: a written rule changes what the model is likely to do, and it is not a wall. On this run the valve fired. Nothing in the file guarantees it fires on the next one, and if a side must never be inflated in production, the check belongs in code that reads the output, which is the critic loop from module 2.02.

engineering voice

Two agents with access to the identical database can produce completely different experiences, and the difference is written down rather than emergent.

Voice is set by communication laws, module 2.01’s fifth block, whose rule was that a law must be checkable against a transcript or the model treats it as optional. Applied to register, that means word limits, required structures, forbidden phrasings, mandatory closings: things you could check against a transcript, which means things a review agent could check too.

The Style Council shows this cleanly. One router conducts three stylists with identical knowledge and identical tools, and the stylists differ only in four register laws apiece, five or six lines of YAML each. Two of the three:

- name: "Analyst"
  instruction: |
    REGISTER LAWS:
    - Telegraphic sentences. Zero filler, zero pleasantries, zero hedging.
    - Maximum 90 words, dense prose, no bullet points.
    - End when the cargo is delivered. No closing remarks.

- name: "Mentor"
  instruction: |
    REGISTER LAWS:
    - A stoic mentor's voice: measured, flowing prose. Never bullet points.
    - Exactly one metaphor drawn from the physical world, placed where
      it carries the core idea.

Read that as: every line under REGISTER LAWS is a test a transcript can pass or fail. “Maximum 90 words” is a count. “No bullet points” is a search. “Exactly one metaphor” is a count too, and a harder one to run, which is exactly the kind of law you should expect to check by hand at first. The full file gives the Peer around 120 words, two to four bullets, and exactly one closing question, and the Mentor around 150 words. What the file does not do is dial a sampler per stylist — the Style Council runs on Gemini, which takes no temperature — and that sharpens the lesson rather than weakening it: every difference you are about to read was written into an instruction.

The router in this council carries the same delegation contract as the Moderator did, with one line added that matters later: it must never paraphrase, trim, or edit a stylist’s answer, because the differences the user sees are the whole exhibit. Ask the council yourself. The answers below are quoted from the live run, lightly compressed:

Now read that transcript back against the specific laws, because the correspondence is exact. The Analyst delivers dense prose under ninety words and stops the moment the point lands, with no closing pleasantry: three laws, three observable behaviors. The Mentor’s water-and-clay imagery exists because its contract commissioned exactly one metaphor drawn from the physical world; the most lyrical sentence in the whole transcript is also the most engineered. The Peer’s closing question exists because a law demanded exactly one.

Grade the instrument here too. Register laws audit register. The three stylists’ knowledge claims agree in this run, but nothing in “maximum 90 words” checks whether the ninety words are true; that is a different contract, the grounding doctrine of module 2.01 and the critic of module 2.02. And the transcript above is compressed from the live run, so read it for the seams the laws produced, and take the full transcript from the download if you want to count the words yourself.

That is the lesson to carry out of these opening modules of Part 2. Nothing in those transcripts is personality. Every characteristic you can point at traces back to a line somebody wrote, which means you can specify a voice deliberately, audit it automatically, and change it by editing a rule. Take the Mentor’s metaphor law out and run it again; the water and clay go with it.

run the council locally

1. Take the Council configuration and execution notes: council.md.
2. Take the Style Council specification and live transcripts: style-council.md.
3. Take a fill-in voice specification template: voice-spec-template.md.
4. Run the local Council: npm run syndicate:council (needs Ollama running qwen3:8b).
5. Run the cloud Style Council with a free key: npm run syndicate:style.

Here is the delegation pass on one card, in the vocabulary you now own:

1. REQUEST
   Arrives at the orchestrator, whose instruction says what it
   does not answer itself.

2. CONTRACT
   The orchestrator reads its own instruction (who must be
   consulted, in what order, passing what) and each specialist's
   description (what that specialist is for).

3. HAND-OFF
   It names a specialist and a task. Router: one specialist.
   Council: every specialist, the same input. Decomposer: one
   after another, each fed the last one's output.

4. SPECIALIST TURN
   Own instruction, own tools, own window. It sees the task it
   was handed and nothing else. Its communication laws set the
   register the answer arrives in.

5. RETURN
   The answer comes back to the orchestrator as text, and the
   orchestrator delivers, forwards, or weighs it.

Cost: one full model call per agent in the reply path, and one
hand-off per arrow, each carrying only what was written into it.

what you carry into the protocol

Five modules, and the foundation is complete. Read it back as questions you can now ask on a working day.

Which shape is this, and did solo actually fail? You know what the machine computes, tokens one guess at a time inside a finite window, with three failure classes that follow from the design; you know how to commit a general model to one purpose by writing an instruction as named blocks; and you can run a model you own for the cost of electricity. So a single agent with tools is a real option, and it is the one to exhaust first. When you do add agents, name the shape, because router and council look alike on a whiteboard and cost differently in production.

What did the specialist actually receive? When a specialist answers without a detail you thought it had, do not reach for its instruction first. Read the hand-off. The isolation that buys the independent window is the same isolation that drops anything the orchestrator did not pass on.

Which line produced that behavior? A misroute is a description read the wrong way, or a contract that left a case open. A wrong register is a law missing or a law the model treated as optional because it could not be counted. In both cases the fix is an edit to a line, and you can diagnose a bad output to one of the five variables from module 2.02 before you touch anything else.

Every one of those is a mold: a way of putting your judgment into a form the machine has to follow.

From here the wiring you built becomes a file. In module 2.04 you will read a whole team, its hierarchy, prompts, tools, and models, in one document, and watch delegation turn out to be tool calling; then persistent memory across sessions, retrieval over your own documents, tools discovered at runtime over a protocol, agents that read images, and a coding agent that builds features under test. Open Module 2.04 to continue.