Agent workflows & conversation styles
by the end you can:
- Choose among four workflow topologies for a given problem
- Read an orchestrator instruction as a delegation contract
- Specify a conversation style as explicit communication laws
- Match instruction lines to the behavior they produce
A multi-agent system relies on two critical design surfaces: the topology, which dictates the shape of who does what, and the voice, which defines the strict laws governing how each agent speaks. Both surfaces require plain language authoring, and both must remain actively checkable. Module 01 constructed a single instrument. This module wires several instruments together before proving the voice thesis through a syndicate built specifically for this lesson and executed live.
four shapes of work
Nearly every agent system you encounter assumes one of four architectural shapes.
Solo: A single agent wielding robust tools without external coordination. Melchizedek’s image producer functions precisely as an orchestrator equipped with a generate_image tool and an empty subagents list.
Router: A triage agent that answers nothing itself. It reads each request and delegates the work to the appropriate specialist (delegation.yaml).
Decomposer: A system that splits one overarching goal into sequential parts, delegates them, and merges the results. The hierarchical.yaml’s ProjectManager routes research to one agent and drafting to another, ultimately owning the final combination.
Council: A structure where several specialists examine the exact same question in parallel, allowing an orchestrator to weigh their independent judgments into a single verdict. This defines the shape of Melchizedek’s financial syndicate, where fundamentals anchor the decision, technicals dictate the timing, and macroeconomics calibrate the scale.
Mastery requires intentional simplicity. Every added agent introduces a structural handoff, a potential loss of context, increased latency, and inflated computational cost. A single agent equipped with robust tools outperforms a committee right up until the work genuinely fractures into distinct domains. Route the scenarios yourself:
Language serves as the actual wiring between these shapes. Observe the router’s entire mechanism, verbatim:
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."The instruction states the policy directly, bypassing fragile keyword matchers and static routing tables. Each subagent’s description explicitly advertises its competence, allowing the orchestrator to reason over both at runtime. That description field functions strictly as an API rather than passive documentation. The orchestrator reads it to determine a handoff. Therefore, the strongest syndicates write descriptions as precise function signatures, explicitly stating when to invoke the tool and what parameters to pass. Prose carries structural weight, and sloppy sentences inherently produce sloppy routing.
voice is engineered
Voice operates as the second engineered surface. Two agents can possess identical facts yet function as entirely different instruments based solely on their communication laws. To demonstrate this honestly, we built the Style Council specifically for this module and ran it live. It features one router conducting three stylists equipped with identical knowledge. Their only difference lies in roughly six lines of specific register law each:
- 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.Ask the council yourself. The answers below derive from the live execution (2026-07-11, lightly compressed):
Read the execution trace against the specific laws to trace every distinct difference. The Peer’s closing question exists because the instruction demanded exactly one short question. The Mentor’s water-and-clay imagery exists because the contract commissioned exactly one metaphor drawn from the physical world. The most lyrical sentence in the transcript is simultaneously the most highly engineered. Because these laws rely on countable metrics like word limits and specific structural counts, a voice specification becomes just as testable as a strict format contract. This establishes the exact foundation for the next module.
Equip yourself with the materials. Download the complete council, featuring the verbatim YAML alongside the unedited live transcript: style-council.md. Retrieve a fill-in voice specification equipped with rules for rendering laws enforceable: voice-spec-template.md. To execute the council live, utilize the exact setup from module 01: Node 20+, a Gemini key, and the command npm run chat:syndicate -- --syndicate style_council "your question, all three stylists". This requires no database and no external tools; three subagent calls per compared answer represent the only computational cost.
A topology is a definitive sentence about who answers. A voice is a definitive sentence about how they answer. Document both explicitly, and the system transitions from an unpredictable mood into a definitive artifact: diffable, testable, and deeply teachable. Module 03 enforces this reality by placing an agent’s work in front of a critic, looping the process until the answer earns strict confidence. Its door opens on the syllabus.