Voice as countable register laws

voice is engineered as countable laws in the communication style

Two agents referencing the exact same underlying database can produce radically different conversational experiences when their prompts define different behavioral targets. That divergence follows from explicit configuration, which covers the model and its sampling settings as well as the prompt.

Say the fair helper’s instruction reads “be concise.” Can you open a transcript and mark a reply as breaking that rule?

We establish an agent’s voice through the communication style block, one of the six blocks of the prompt anatomy. Within that block, we write each requirement as a register law: an observable property of the reply that a transcript passes or fails. An instruction such as “be concise” still shifts what the model tends to write, and it offers no reading of a reply that fails it, so you cannot evaluate it dependably. When shaping conversational register, you establish measurable targets: strict word limits, mandatory structural formats, forbidden phrasing, and required concluding elements. Because you can verify a register law directly against a transcript, an automated evaluation agent can audit compliance systematically.

The Style Council demonstrates this principle. A single router coordinates three stylists that share identical domain knowledge and identical tools. In the file as it stands, these stylists’ instructions differ only in four register laws apiece, four lines of YAML each. Here are the laws for two of the three, as the file writes them:

- name: "Analyst"
  instruction: |
    REGISTER LAWS:
    - Telegraphic sentences. Zero filler, zero pleasantries, zero hedging.
    - Exact mechanisms and figures over adjectives.
    - 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 in two or three short paragraphs. Never bullet points.
    - Exactly one metaphor drawn from the physical world, placed where it carries the core idea.
    - Precision beneath the calm: name the actual mechanism; the reflection must never blur the facts.
    - Maximum 150 words. Close on the idea, not on a pleasantry.

Read that as: every line under REGISTER LAWS is a register law that a transcript can pass or fail. Maximum ninety words is a count. No bullet points is a string search. Exactly one metaphor is also a count, though you verify it by reading until you build an automated evaluation pipeline. The full configuration assigns the Peer a maximum of 120 words, two to four bullets, and exactly one closing question; the Mentor receives a maximum of 150 words. Apart from the line that names the stylist, every line of the three instructions outside REGISTER LAWS is word for word the same, including a ground rule against stating a figure or a name the stylist is not sure of, so within the instructions the four laws are the only variable between them.

The instructions are one source of difference among several. Today’s file sets no temperature on any stylist, so all three sample at Gemini’s default. The run quoted below was made with the file as committed that day, which did set one: a different temperature on each stylist, as the statement at the top of this module records. At any temperature above zero the model draws each token from its probability distribution, so two runs of the same stylist on the same question can differ in wording, length and imagery while its register laws still hold or fail. One run per stylist shows what the laws and that day’s sampling produced together, and it cannot separate the laws’ share of the differences from the temperatures’ share. Repeated runs under matched settings can, and the comparison after the transcript sets them up.

The router in this team uses delegation instructions similar to the Moderator’s, with one addition: you instruct it never to paraphrase, shorten, or edit the stylists’ outputs, so each register reaches the user intact.

Now trace each response back to the register laws in its communication style. The Analyst delivers concise prose within the ninety-word ceiling and concludes immediately upon making its point, omitting conversational pleasantries: three register laws, and three behaviors you can check in the reply. The Mentor’s reflection on water and clay is there because its register law mandates exactly one metaphor drawn from the physical world, so the most evocative phrasing in the output is also its most deliberately engineered element. The law requires a physical-world metaphor; water and clay is the image this run’s sampling drew, and another run may draw a different one. Likewise, the Peer concludes with a discussion prompt because its register law requires a closing question.

Register laws govern conversational style and structure. In this run, all three stylists maintain factual consistency, but a register law enforcing a maximum of ninety words provides no guarantee that those ninety words are accurate. Factual integrity requires separate mechanisms: a grounding doctrine that binds every answer to supplied sources, and a critic loop that scores the draft before it reaches the reader.

Each register law gives you something to check in every reply, so you can verify an agent’s compliance automatically and change its voice by editing one law. To see which differences the laws account for, run the comparison a single run cannot make. Ask the same question several times per stylist, then set the same temperature on all three stylists and ask it several times again, and in every reply count what the laws count: words, bullets, metaphors and closing questions. If you then remove the Mentor’s metaphor law, what to look for across several runs is whether a physical-world image still appears.

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, its own earlier exchanges in this conversation,
   and nothing else. Its communication style sets 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: at least one model call per specialist, at least two for
an orchestrator that delegates and then answers, and one
delegation per arrow, each carrying only what was written into it.

your turn: choose a topology and a voice for the fair helper

The scenario, written for this course:

“The Riverside Community Fair’s organisers want their helper to do three things: answer visitors’ schedule questions from the schedule in its instruction, in a friendly register; book tables at the Riverside repair café through a tool that writes to the bookings sheet; and write the end-of-day summary for the organisers, in a formal register with no exclamation marks.”

You decide how many agents do this work, how they coordinate, and how you check that their replies sound the way the organisers asked. Before you choose a topology, what do you write first?

Consider the first requirement in isolation: answering visitors’ questions about the fair schedule. With the schedule in its instruction, one agent answers these questions without delegating and without a tool. No single-agent failure is in sight, so solo holds, and a solo agent with no tools answers each question in one model call.

One register law for this job’s voice: “Maximum 60 words.” Its check is a word count on each reply, and across five runs the result is written as a count, in a form such as “5 of 5 under 60 words”. That form is an example, not a result; your own count covers only the runs you made.

The same method covers the whole scenario. You list the helper’s subtasks, start from one agent with tools and add an agent only for a single-agent failure you can name, and count the model calls for your choice the way the Council’s were counted. You then write at least three register laws for the helper’s voice and count each law across several runs of one question, claiming nothing beyond the runs you made.

what you carry into part 2

With these five foundational lessons complete, you now have a rigorous framework for evaluating multi-agent architectures. As you design systems in practice, return to these core diagnostic questions:

Which shape is this, and did solo actually fail? You understand the underlying mechanics of large language models: sequential token generation within a finite context window, subject to three predictable failure modes. You know how to ground a general-purpose model in a dedicated role using structured, named prompt blocks, and you can run local models on your own hardware for the cost of electricity. A solo agent equipped with strong tools should always be your starting architecture. If you decide to introduce additional agents, clearly identify the topology you are deploying; a router and a council may look similar in a schematic diagram, but their computational costs in production are vastly different.

What did the specialist actually receive? When a specialist generates an incomplete answer, resist the urge to immediately rewrite its system prompt. First, inspect the exact payload transferred during the hand-off. The context isolation that gives specialists an unpolluted reasoning window also means that any background information omitted by the orchestrator is completely unavailable to the specialist.

Which line produced that behavior? If a system routes a request incorrectly, look for ambiguity in a specialist’s description or an unhandled edge case in the orchestrator’s delegation contract. If an agent speaks in an inappropriate register, check the communication style block for missing laws or rules that were too vague to be objectively verified. In both situations, the solution is a precise textual edit, allowing you to trace the defect back to one of the five prompt variables — clarity, precision, context, instruction, format — before modifying any other component.

Each of these architectural patterns is an engineering mold, translating your design intent into concrete structures that the model must follow.

From this point forward, the multi-agent wiring you have constructed will be expressed through standardized configuration files: a whole multi-agent hierarchy (including prompts, tools, and models) defined within one document, with delegation implemented as tool calling. From there, the course explores persistent cross-session memory, document retrieval architectures, dynamic tool discovery protocols, vision-capable agents, and autonomous coding agents building features under test suites.