Multi-Agent Systems

The previous lesson built a single agent: an LLM inside a loop, with tools, memory, observations, and stopping conditions. That agent can plan a trip, search the web, call APIs, and revise its next step.

Now imagine a larger task: build an ML-powered weather application. The system needs to inspect data, choose features, write code, test edge cases, document the design, and review whether the forecast is trustworthy.

Should one agent do all of that, or should the work be divided across specialists?

That is the motivation for multi-agent systems. They are not a new kind of language model. They are software architectures that coordinate multiple LLM-driven workers.

A single agent is like one capable generalist. A multi-agent system is like a small product team. One role plans, another researches, another implements, another tests, and another reviews.

The point is not that five agents magically become five times smarter. The point is that complex work often benefits from decomposition:

Each agent receives a narrower context and a clearer objective. The researcher does not need to write the UI. The tester does not need to design the whole product. The reviewer can focus on catching mistakes rather than producing the first draft.

In a single-agent loop, one policy maps the current state to the next action. In a multi-agent system, each agent has its own role, context, tools, and policy.

Here, $\pi_i$ is the policy for agent $i$, $s_i$ is the state visible to that agent, and $a_i$ is the action or message it produces.

A simple pipeline composes these policies:

Intuitively, the output of one agent becomes part of the input to the next. A researcher produces notes, an engineer turns notes into code, a tester turns code into failures or approvals, and a reviewer turns the whole trace into a final judgment.

More flexible systems maintain shared state:

The coordinator chooses which agent acts at time $t$, records the action and observation, and updates the shared workspace. That workspace may be a task board, scratchpad, vector database, document store, or structured log.

Multi-agent design is mostly control-flow design. You are deciding who acts, what context they receive, how they communicate, and who has authority to merge or reject results.

Agents communicate by passing messages. Those messages may be natural language, JSON, tool outputs, test results, retrieved documents, or structured handoff packets.

A useful handoff is specific:

{
  "task": "Write tests for the weather prediction endpoint",
  "context": "The endpoint accepts city and date, then returns a temperature forecast",
  "constraints": ["test missing city", "test malformed date", "test confidence warning"],
  "expected_output": "A test file plus a short list of uncovered risks"
}

Shared memory is the workspace that keeps agents aligned. It can store the original goal, constraints, intermediate findings, tool outputs, decisions, and open questions. Without shared memory, agents can drift into separate realities.

The hardest part of multi-agent design is usually not creating agents. It is dividing the task correctly. Good decomposition gives each worker a clear boundary.

For the weather app, a good decomposition might be: data audit, feature plan, model implementation, interface implementation, test suite, documentation, and review. A bad decomposition would ask three agents to independently build the entire app and then hope their outputs merge cleanly.

A minimal multi-agent framework does not require a special library. You need agent objects, messages, a coordinator, and a shared state object.

from dataclasses import dataclass, field

@dataclass
class Message:
    sender: str
    recipient: str
    content: str

@dataclass
class Agent:
    name: str
    role: str
    tools: list[str] = field(default_factory=list)

    def run(self, task: str, memory: dict) -> Message:
        # In a real system this would call an LLM with:
        # role + task + relevant memory + available tools.
        return Message(
            sender=self.name,
            recipient="coordinator",
            content=f"{self.name} completed: {task}"
        )

class Coordinator:
    def __init__(self, agents: list[Agent]):
        self.agents = {agent.name: agent for agent in agents}
        self.memory = {"notes": [], "risks": []}

    def assign(self, agent_name: str, task: str) -> Message:
        agent = self.agents[agent_name]
        message = agent.run(task, self.memory)
        self.memory["notes"].append(message.content)
        return message

agents = [
    Agent("planner", "decompose the project"),
    Agent("researcher", "inspect data and constraints"),
    Agent("engineer", "implement the app", tools=["code_runner"]),
    Agent("tester", "write and run tests", tools=["test_runner"]),
    Agent("reviewer", "find mistakes and risks"),
]

coordinator = Coordinator(agents)
coordinator.assign("planner", "split the weather app into concrete tasks")
coordinator.assign("researcher", "find data quality risks")
coordinator.assign("engineer", "implement the prediction endpoint")
coordinator.assign("tester", "test the endpoint")
coordinator.assign("reviewer", "review the full plan and code")

This toy version uses mocked outputs, but the structure is real. In production, each run method would call a model, pass relevant memory, expose only approved tools, validate the returned message, and append the result to an audit log.

Independent workers can also run in parallel:

import asyncio

async def run_worker(agent, task, memory):
    return await call_llm(agent.role, task, memory)

results = await asyncio.gather(
    run_worker(researcher, "audit the dataset", memory),
    run_worker(ui_designer, "draft the interface", memory),
    run_worker(tester, "write edge-case tests", memory),
)

memory["worker_results"] = results
final = await call_llm(
    coordinator.role,
    "merge worker results and produce the final plan",
    memory,
)

Disagreement is normal. One agent may recommend a linear regression baseline, while another recommends gradient boosting. One may say the dataset is clean, while another finds missing station readings.

Common resolution strategies include voting, confidence weighting, a judge model, deterministic tests, external tools, and human review. The safest systems do not treat consensus as truth. They ask what evidence supports each claim.

Multi-agent systems increase the attack surface. A researcher that reads untrusted web pages can pass malicious instructions to an engineer. A coding agent with shell access can make changes a reviewer never approved. A supervisor can accidentally grant broad permissions to the wrong role.

Use least privilege. The documentation writer does not need deployment credentials. The researcher does not need write access to production data. High-impact actions should require human approval, and every tool call should be logged.

Compare against a single-agent baseline. If the multi-agent version costs three times more and takes twice as long, it should produce a measurable improvement.