Agentic AI Engineering · Module 07 of 16

Multiple Agents

A multi-agent system is several bounded agent roles cooperating on one outcome. The value comes from clear responsibility and isolation—not from creating more personalities.

Engineering focus: Manager, specialist and handoff patterns with scoped responsibility

In plain English

What problem are we solving?

A multi-agent system is several bounded agent roles cooperating on one outcome. The value comes from clear responsibility and isolation—not from creating more personalities.

Framework names come later. First understand what the application is doing and where its control boundaries belong.

Running case · Operations Investigator

Across the course, imagine an assistant that investigates operational problems using narrow tools. The design progressively adds plans, specialist agents, approvals, reliability controls and MCP while keeping model output separate from execution authority.

Learning objectives

By the end of this module, you should be able to:

Explain manager/orchestrator and handoff patterns.
Scope each specialist to the tools and context it actually needs.
Recognize when one agent plus tools is simpler and safer than multiple agents.

Start with one agent plus tools

Multiple agents add model calls, handoff logic, state coordination, latency and new failure modes. Split the system only when there is a real boundary in domain, permissions, context or ownership.

Manager/orchestrator pattern

A manager keeps ownership of the user goal and delegates bounded tasks to specialists. Specialists return structured findings; the manager combines them and decides what happens next.

Handoff pattern

A handoff transfers conversational or task ownership to a specialist. That is different from a manager calling a specialist as a subtask and then remaining in control.

Scope authority with responsibility

A Kubernetes specialist may inspect pods but should not automatically inherit database administration tools. Tool permissions and context should follow the role boundary rather than a shared 'super-agent' capability set.

Worked examples

Manager with specialists

User goal
  ↓
Operations Manager
  ├─ Linux specialist → service/log evidence
  └─ Kubernetes specialist → pod/service evidence
  ↓
Manager combines findings

The manager retains task ownership.
Specialists return bounded evidence, not unrestricted control.

When not to split

Need: disk usage + service status
Best: one agent + two read-only tools
Not: disk-agent + service-agent + manager-agent

More agents would add coordination without a meaningful boundary.
Architecture should minimize moving parts.

Try it · core lab · account-free

Dispatch work to scoped specialists

Goal: Simulate a manager that delegates Linux and Kubernetes investigations while enforcing each specialist's allowed tools.

Before you start

Python 3 only. No models are called; the lab exposes delegation and permission boundaries directly.

STEP 1

Run the manager/specialist lab

python3 public/labs/agentic-ai/07_multi_agent_systems.py

STEP 2

Inspect each specialist's tool scope

Notice that Linux and Kubernetes specialists cannot call each other's tools.

STEP 3

Trigger a forbidden cross-domain request

The lab must reject a specialist trying to use a tool outside its role.

Download this Python lab Download all current labs

Verify

The manager receives structured findings from both specialists.
A cross-role tool request is rejected.

Expected outcome

Responsibility and authority are visibly aligned.
The manager can combine evidence without granting every specialist every tool.

Break / fix · diagnose

If a specialist can call all tools, check the per-role allowlist.
If the manager loses findings, inspect the structured result returned by each specialist.

Production view

Multi-agent systems need the same engineering controls as distributed systems: explicit contracts, ownership, bounded permissions, timeouts, correlation IDs and observable handoffs.

Avoid these traps

Common mistakes

Creating multiple agents to make the architecture look sophisticated.
Giving every specialist the same broad tool set.
Passing the entire conversation to every specialist when only a small task context is needed.
Confusing a subtask delegation with a full ownership handoff.

Knowledge check

Explain the control decision, not just the vocabulary.

Open every answer only after committing to your own answer. Opening all four answers records knowledge-check activity in My Learning.

1When is one agent plus tools usually preferable to multiple agents?

When there is no meaningful boundary in domain, permissions, context or ownership — fewer moving parts are easier to operate.

2In a manager pattern, who retains the overall user goal?

The manager/orchestrator — specialists perform bounded subtasks and return results.

3What is different about a handoff?

Task or conversational ownership moves to the specialist rather than returning immediately to a manager that still owns the flow.

4Why give specialists different tool allowlists?

Authority should match responsibility — role separation is useful only if permissions and context are scoped with it.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.