The interesting thing about multi-agent orchestration is that the pattern is easy and the frameworks are hard.
Fan out a task. Let three or four subagents work on it in parallel with isolated contexts. Pull the pieces back. Merge them into an answer. That's it. That's the whole shape. Every serious framework — LangGraph, CrewAI, AutoGen — takes that shape and wraps it in a state machine, a role system, a message-passing protocol. Sometimes the scaffolding earns its weight. Sometimes the scaffolding is the reason a project takes six weeks longer than it should.
Hermes ships with the pattern and skips the scaffolding. That's a design choice worth understanding, because it maps onto a much larger argument about where multi-agent work is actually going.
What parallel subagents actually is
A parallel-subagent architecture is one where a parent agent decomposes a task into pieces, dispatches each piece to a child agent with its own context, waits for the results, and synthesizes them into a final answer.
Three things distinguish it from "an agent that calls tools." First, the children have their own LLM turn — they're not just function calls. Second, the parent doesn't see the children's intermediate reasoning; it sees only their returned answer. Third, the children run in parallel by default, because the whole point is to shrink wall-clock time on tasks that would otherwise be sequential.
The pattern shows up under different names — "worker-orchestrator," "research swarm," "fan-out/fan-in" — but the shape is the same. What varies is how much the framework insists on scaffolding around it.
What the pattern actually does
- Decomposes the incoming task into sub-tasks that can run independently. Bad decomposition is the number-one failure mode; if the sub-tasks share state, you don't have a parallel job, you have a distributed data race.
- Dispatches each sub-task to a child agent, usually with its own context, its own tool subset, and its own scoped permissions.
- Isolates children from each other. Sibling A cannot see sibling B's reasoning. This is the property that makes the pattern work; it's also the property most frameworks quietly violate.
- Tracks each child's status — running, blocked, failed, complete — from the parent, so a stuck subagent is visible instead of silent.
- Merges the returned results. Simple merge (concatenate the outputs) works for research tasks. Structured merge (reconcile conflicts, dedupe, rank) works for anything that involves opinions.
- Accounts for cost per subagent. In a multi-child job with three different LLM providers, "how much did this cost" is not obvious without instrumentation.
Why it beats a single-agent loop
Single-agent loops fail on breadth. Ask one agent to research five competitors, and it will do them serially, contaminate its own context across the five, and get slower and less coherent as the context grows. Ask five subagents to each do one competitor and return a summary, and you get five clean, isolated researches in the time of one, plus a parent that can compare them without ever seeing the intermediate mess.
Anthropic's engineering post on their multi-agent research system makes this concrete: their internal research agent uses a lead agent that spawns subagents for parallel investigation. They observe roughly a 90% performance improvement over single-agent research on breadth-heavy tasks. That number will not generalize to every job — depth-heavy tasks with tight dependencies don't parallelize — but it names the shape of the win.
The pattern also gets you a useful failure isolation property. When a child agent goes off the rails (loops on a tool call, hallucinates a citation, decides it's actually a different agent), the damage is scoped to that child. The parent's context is not corrupted. In a single-agent loop, one bad turn poisons everything after it.
Where this is being built
Three frameworks and one runtime worth naming.
LangGraph is the most explicit graph-based take: you declare nodes, edges, and state, and the framework runs the traversal. It's the right choice when the sub-tasks are structured enough to encode as a graph and you want the graph to be inspectable. It's the wrong choice when the sub-tasks are dynamic and the graph would have to be rewritten on every run.
CrewAI leans harder into the "team of roles" metaphor: you declare agents with backstories and goals, and the framework negotiates the collaboration. It reads well in demos. In practice, the role scaffolding tends to become the thing you're debugging when a job goes wrong.
AutoGen from Microsoft Research sits in between: less graph-heavy than LangGraph, less role-heavy than CrewAI, more focused on the conversation protocol between agents. The OpenAI Agents SDK is a more recent, thinner take on the same shape, aimed at teams already in the OpenAI stack.
Then there's the runtime approach: Claude Code's Task tool spawns subagents with isolated context, Hermes's delegate_task(background=true) does the same, and neither treats multi-agent as a framework problem. The bet is that fan-out/fan-in is simple enough that you don't need declarative scaffolding — you need a good primitive and the discipline to use it. Whether that bet is right depends on how structured your workload is.
How to evaluate a solution
Six checks before you commit to any multi-agent architecture.
How does the parent track child status? If a subagent hangs, does the parent notice within seconds, or does the whole job just wait for a timeout? Ask for a live status feed, not a post-hoc log.
What's the failure recovery model? When a child fails, does the parent get a clear error, a partial result, or a stack trace? Can the parent decide to retry a specific child, or does one failure abort the job?
How is cost accounted per subagent? Multi-agent jobs are the fastest way to burn a monthly LLM budget. Any system without per-child cost telemetry is asking to surprise you.
Is context truly isolated between siblings? Read the framework's message-passing docs and then verify. Some systems say "isolated" and mean "same context window, filtered." Some mean "actually different processes." The difference shows up when a sibling's data leaks into another sibling's reasoning.
Are long-running subagents cancelable? A background subagent that has been running for 40 minutes on a task the user has since abandoned is a bug. There has to be a way to kill it that also updates the parent.
What happens on decomposition failure? If the parent can't figure out how to split the task, does it fall back to running the whole thing as a single agent, or does it fail loudly? Both are defensible. Silent fallback with no log is not.
Multi-agent orchestration is one of the few areas where the framework you pick actually shapes the code you write. Pick the lightest one that still gives you the scaffolding you need, and no lighter.