Multi-Agent Skill Systems

One Level Up From Composition

The previous lesson composed several skills inside one agent — a research skill, a SQL skill, and a visualization skill, all reasoned about by a single decision-making loop. Multi-agent systems take the same idea one level further: instead of one agent drawing on several skills, several agents, each with their own distinct skill set, work on different parts of the same problem.

This isn’t composition with extra steps — it’s a genuinely different structure, with a different reason to reach for it.

Why Split Into Multiple Agents at All

A single agent composing several skills works well when one continuous line of reasoning can hold the whole task. It starts to strain when a task needs genuinely different kinds of judgment happening at once, or when one part of the task benefits from a fresh, unbiased look rather than continuing the same train of thought that produced the earlier work. A reviewer that’s the same agent, same context, same reasoning thread that just wrote the code it’s now reviewing tends to rubber-stamp its own decisions — a structurally different agent, with a different, narrower skill set focused purely on review, doesn’t carry that bias in.

Five Common Roles

Supervisor
    ↓
 Planner
    ↓
Researcher
    ↓
Executor
    ↓
Reviewer

Each role carries a distinct skill set — not a subset of one giant skill list, but skills scoped specifically to that role’s job.

Supervisor. Holds the overall goal and decides which agent acts next, based on what’s come back so far. Its skills are about orchestration and routing decisions — a Decision pattern skill, from the design patterns lesson, applied to “which agent handles this next” rather than to a business rule.

Planner. Breaks the supervisor’s goal into an ordered set of tasks — exactly the Planner pattern from two lessons back, but now producing tasks for other agents to execute rather than steps the same agent carries out itself.

Researcher. Gathers information needed before execution can proceed — skills scoped to search, retrieval, and synthesis, deliberately without any skill that takes real-world action. A researcher agent with a skill that can also modify data has a scope that’s crept past what the role needs.

Executor. Takes a specific, well-defined task and does it — skills scoped to action: calling tools, writing files, making the actual changes. This is where a task’s real-world effects happen, which is exactly why its skill set should be the most tightly scoped and the most carefully governed (a preview of Security and Governance).

Reviewer. Assesses completed work against criteria — the Reviewer pattern, structurally separated from whichever agent produced the work being reviewed, specifically to avoid the self-review bias mentioned above.

Designing Skill Sets, Not Just Skills

The design question at this level isn’t “what should this skill do” — it’s “what set of skills does this role need, and just as importantly, what should it explicitly not have access to.” An executor agent with a reviewer’s skills can end up second-guessing its own actions mid-task in ways that slow it down without adding real oversight; a researcher agent with an executor’s skills can take real-world action based on incomplete information, without the review step ever happening. Scoping a role’s skill set is as much about exclusion as inclusion.

## Executor agent — skill set

Included:
- deploy-checklist (Workflow)
- config-validator (Validator)
- rollback-procedure (Workflow)

Explicitly excluded:
- Any skill that approves its own output — approval and review happen
  in the Reviewer agent, not here.

Writing the exclusion down, not just the inclusion, is what keeps a role’s boundaries from drifting the first time someone adds “just one more skill” to make an agent more capable in isolation.

Handoffs Between Agents

Just as composed skills within one agent need a consistent output contract (from the previous lesson), agents handing work to each other need the same discipline, at a coarser grain. A planner agent’s task list needs to be something the researcher and executor agents can actually consume without re-interpreting it from scratch:

## Planner agent — task handoff format

Each task in the output list includes:
- task_id
- assigned_role: researcher | executor
- description
- depends_on: [task_id, ...] or none

Without a stated handoff format, each receiving agent has to infer structure from free-form prose, which reintroduces exactly the unpredictability that a stated contract was meant to remove.

When One Agent With Composed Skills Is Enough

Multi-agent systems cost more to build, more to run, and more to debug than one agent with several composed skills — more handoffs mean more places for information to get lost or misinterpreted between agents. The business intelligence example from the previous lesson didn’t need to become a supervisor/planner/researcher/executor/reviewer system — one agent composing three skills handled it well, because nothing about that task benefited from a structurally separate reviewer or an independent research pass. Reach for multiple agents when a task genuinely needs different kinds of judgment operating with real independence from each other — not by default, and not just because a task has several steps.

Summary

• Composition (previous lesson) combines skills within one agent; multi-agent systems distribute distinct skill sets across several agents
• The reason to split into multiple agents is independence of judgment — most clearly, keeping review structurally separate from the work being reviewed
• Five common roles — supervisor, planner, researcher, executor, reviewer — each need a skill set scoped specifically to that role, including deliberate exclusions, not just a subset of one shared list
• Handoffs between agents need a stated contract, the same discipline composed skills need within one agent, just at a coarser grain
• Multi-agent systems cost more to build and debug than one agent with composed skills — reach for them when a task genuinely needs independent judgment, not by default

You’ve now scaled a skill from one file to a full multi-agent system. The next four lessons shift from designing skills well to proving they work — starting with testing and evaluation at a scale beyond what the free course’s manual checks can catch.