Working with Multi-Agents - part 1

Why I started experimenting with multi-agent systems

I've been thinking a lot about autonomous agents lately, and one question keeps coming up: When does it make sense to have multiple agents working together versus one agent handling everything?

Conventional wisdom says to start simple by building one capable agent, giving it the tools it needs, and letting it handle your workflow. I followed that solid advice, and I ran into the limits. Here's what happened.

To make my agent useful across different tasks, I kept adding tools. I added more context to handle complex domains and more instructions to cover edge cases. Eventually I'd built what I started calling a super agent that could theoretically handle anything.

The problem was that it handled everything the same way.

A simple request to check a calendar triggered the same context load as a complex research task. The agent dutifully loaded its full system prompt, all its tools, and all its background context, even when 90% of it wasn't relevant. Tokens added up, latency crept in, and simple tasks became slow and expensive.

Researchers call this context rot. Models have finite attention, and when you pack in too many tools and instructions, the agent struggles to identify what's relevant. The more you add, the harder it gets for the model to focus on what matters for this specific request.

I'd optimized for capability and created overhead.

A Different Trade-Off

Instead of one agent that knows everything, multi-agent systems have specialized agents that each know their domain well. A research agent focuses on research, while a writing agent concentrates on writing. Each one loads only what it needs.

The trade-off is coordination. You need agents to communicate, hand off work, and align, which isn't free. The benefit is that each agent stays lean, and simple requests don't expend the processing power of more complex ones.

I wasn't sure if this trade-off would be worth it, so I started experimenting.

Three Approaches I've Been Testing

The Delegation File

With this simple setup, you create a single file, be it JSON, Markdown, or another program, that contains a list of tasks with enough detail for a primary agent to route them. The primary agent reads this file, decides what needs to happen, and delegates each task to a specialized agent based on type. The specialists do their work and report back. To try this yourself, start with a file that defines task types and which agent handles each. Your primary agent just needs the logic to parse the file and call the right specialist.

The Folder System

This approach mimics how teams use shared task boards. You create a folder structure, such as — "to-do," "in-process," and "done" — and agents interact with tasks by moving files between folders. An agent monitoring the "to-do" folder grabs a task file, moves it to "in-process" while working on it, and moves it to "done" when finished. Other agents can watch for completed work and pick up downstream tasks that depend on it. To experiment with this, set up a shared directory your agents can access, define a simple task file format (a task description, any inputs needed, where to put outputs), and build agents that poll folders and respond to what they find.

The Hive

This is a feature we've been experimenting with at Scout. Agents communicate as if they're in a chat room, such as Slack. They subscribe to channels, post updates, ask questions, and respond to each other in real time. An orchestrator agent might post a task to a channel, and specialized agents monitoring that channel can claim the work, ask clarifying questions, and post their results. The conversation becomes a coordination mechanism. To try something similar, use a simple message queue or even a shared log file where agents append messages and poll for new ones. The key is to give agents a way to broadcast and listen rather than just receive direct instructions.

Each of these approaches has different strengths. The delegation file is explicit and easy to debug, and the folder system is loosely coupled, meaning agents don't need to know about each other. The Hive handles dynamic, conversational work where tasks evolve through back-and-forth.

In Part 2, I'll go deeper into what each approach is good for, where it gets tricky, and how to think about which one fits your needs.