Multi-Agent Patterns - part 2

How each one works and when it might fit your needs

In Part 1, I talked about the super-agent trap and how stacking tools and context onto a single agent creates overhead that slows down simple tasks. Multi-agent systems offer a different trade-off: specialized agents that stay lean and coordinated.

I've been experimenting with three approaches, and here's what I've learned.

1. The Delegation File

One file contains tasks routed to specialized agents. A primary agent reads the file, decides what needs to happen, and delegates based on task type before the specialists do their work and report back.

What I like: It's easy to analyze; you can look at the file and see exactly what's being routed where.

Where it gets tricky: The primary agent still needs enough context to route well, and if tasks have dependencies, you're managing state across agents.

2. The Folder System

This mimics shared task boards. You create folders — "to-do," "in-process," and "done" — and agents interact by moving tasks between them. An agent grabs a task, works it, and moves it along. Other agents watch for completed work and pick up downstream tasks.

What I like: Loosely coupled agents don't need to know about each other; they just respond to what shows up.

Where it gets tricky: Context has to travel with the task and not in agent memory, requiring clear conventions.

3. The Hive

This is a feature we've been experimenting with at Scout. The core idea is that rooms become projects.

You might have a blog writing room, a CRM room, and a coding project room, with multiple agents subscribing to rooms relevant to their skills. Subscribed agents react to posted tasks, doing their work and posting the output back to the room. Other agents see that output and respond in turn.

This is different from a pipeline in that it's not a fixed sequence; the workflow emerges from the conversation. The same agents can serve different projects by subscribing to different rooms.

What I like: It's dynamic and flexible, organized at a logical project level. You're creating a space where agents collaborate rather than a pipeline for each use case.

Where it gets tricky: Conversation becomes context; if a room gets noisy, things get hard to follow. It's important to have good norms about when to speak up.

What the Industry Is Learning

Don't reach for multi-agent because it looks sophisticated. Wait until you've hit hard security boundaries, genuine context overload, or true parallelism needs. For tightly coupled tasks that need fewer than 10-20 tools, a single agent with good tool design is probably the better path.

Current Thinking: Separating Implementation From Validation

Separate doing the work from judging the work.

A writer does their own research, and an editor reviews the results. These are different modes of thinking with different contexts.

In a single-agent setup, you're asking the same agent to create and critique its own output. In a multi-agent setup, you can separate these cleanly. Implementation agents, such as researchers or writers, focus on producing, while validation agents, such as judges and editors, focus on evaluating against criteria.

Example using the Hive:

1. A topic request appears in the blog-writing room.
2. A research agent posts research notes.
3. A writer agent drafts a post and shares it.
4. Judge agents evaluate (one for accuracy, one for tone, one for structure) and post feedback.
5. The writer revises, and the cycle continues until the post satisfies the judges or a human steps in.

The writer and researcher could be the same agent, but the judges are separate, bringing fresh context focused purely on evaluation.

This mirrors human teams where a writer researches and writes and an editor reviews. Separating those roles brings the right focus to each stage.

Questions To Help You Decide

• How diverse are your tasks? Similar tasks can stay with one agent, but wildly different tasks might benefit from specialists.
• Can you separate implementation from validation? If your workflow has creation and evaluation phases, that's a clean multi-agent boundary.
• How important is speed? Coordination adds latency.

More To Come

I'm still experimenting. Open questions include:

• How granular should validation agents be?
• When does the Hive get too noisy?
• How do you handle disagreement between judges?

If you're exploring similar patterns, I'd love to hear what you're learning.

More To Explore

• Choosing Between Single-Agent and Multi-Agent Systems — Microsoft
• Agents and Workflows — Louis Bouchard
• AI Agent Orchestration Patterns — Product School
• Effective Context Engineering for AI Agents — Anthropic