Multi-Agent Orchestration with Muse Spark 1.1: How Subagent Delegation Actually Works in Production

Multi-agent architectures have a credibility problem, and it's deserved. The standard failure looks like this: a team splits a task across five agents, each agent gets a fraction of the context, four of them duplicate work while the fifth waits, and the orchestrator spends more tokens coordinating than a single agent would have spent just doing the job. I've reviewed enough of these to be a skeptic by default.

What makes Muse Spark 1.1 worth a second look is that Meta trained delegation as a first-class behavior rather than leaving it to your prompt. The model is trained to work as a main agent that plans and delegates, and as a subagent that sticks to its assigned job and escalates when it hits something outside that scope. Those are two different jobs and most models are only trained for neither. This post covers how to build it and, more importantly, when not to.

The two roles, and why the second one matters more

Every multi-agent framework gives you an orchestrator. Almost none of them address the subagent side, which is where the failures actually originate.

A subagent that isn't trained to stay in scope does one of two bad things. It expands, deciding that fixing the adjacent module is obviously in the spirit of the request, and returns work nobody asked for that now needs reviewing. Or it collapses, hitting a genuine blocker and inventing a plausible answer rather than reporting the blocker, which is worse because it's invisible until something downstream breaks.

Meta training the subagent behavior explicitly — do your job, escalate when you can't — targets exactly this. In our testing the escalation behavior was the more reliable half. A subagent handed a task with a missing credential reported the missing credential instead of improvising around it, which sounds like a low bar until you've watched other models improvise around it.

Structuring the orchestrator

Delegation is only worth its overhead when subtasks are genuinely independent. Our orchestrator prompt makes that the explicit test:

ORCHESTRATOR_SYSTEM = """
You plan and delegate. Break the task into subtasks only when they are
independent: each must be completable without seeing another subtask's output.

Delegate when work fans out across items (many files to read, many records to
check, many candidates to evaluate). Do the work directly when it is sequential,
when it fits in one response, or when the subtasks would need to talk to each other.

Each delegation must include everything the subagent needs: the goal, the
constraints, the definition of done, and where to write its output. Subagents
cannot see this conversation.
"""

That last line is the one people forget. Subagents don't inherit the orchestrator's context. Every piece of information a subagent needs has to be in the delegation message, and the most common multi-agent bug is an orchestrator delegating "fix the remaining issues" to an agent that has no idea what the issues are.

The loop itself stays ordinary. The orchestrator emits delegation tool calls, your harness spawns a subagent per call against the same endpoint, and results come back as tool outputs:

async def delegate(subtask: dict) -> dict:
    messages = [
        {"role": "system", "content": SUBAGENT_SYSTEM},
        {"role": "user", "content": subtask["instructions"]},
    ]
    return await run_agent_loop(
        client, model="muse-spark-1.1", messages=messages, tools=SUBAGENT_TOOLS
    )

results = await asyncio.gather(*[delegate(s) for s in subtasks])

Run them concurrently. The entire economic argument for delegation is wall-clock parallelism; a sequential fan-out is just a single agent with extra steps and worse context.

Goal conditioning and context compaction

Two more trained behaviors that matter for runs of any length.

Goal conditioning means the model holds the original objective as a persistent anchor rather than letting it decay as the conversation grows. The practical consequence is that your opening message deserves real effort. State the goal, the constraints, and what "done" looks like, all up front, in one well-specified turn. This is the same advice I gave for Claude Opus 5 long-horizon runs and it's converging across the frontier: models are increasingly trained to plan against a stated goal, which rewards stating one properly and punishes drip-feeding.

Context compaction as a trained behavior means the model summarizes its own history as it approaches the window rather than requiring your harness to do surgery on the message array. With a 1M-token window and per-subagent isolation, we didn't hit compaction on most runs. Where it mattered was the orchestrator on long fan-outs, accumulating dozens of subagent reports, and the summarization it produced kept the decisions and dropped the transcripts — which is the right instinct.

The cost math that makes this interesting

Multi-agent has always carried a token tax: you pay for coordination, for repeated context in each subagent, and for the orchestrator reading every result. At Claude Opus 5 prices, that tax is what kills most fan-outs on the spreadsheet before they're tried.

Muse Spark 1.1 at $1.25 input / $4.25 output per million tokens changes the arithmetic. A ten-way fan-out that would cost roughly $6 in output tokens on Opus 5 costs about $1 here. That doesn't make bad architecture good, but it does mean the parallel version of a workflow is now worth trying on cost grounds where previously it wasn't.

A hybrid that's working well for us: Muse Spark as the subagent fleet, a stronger model as the orchestrator. Subagent work is usually bounded and well-specified, which is where cheaper models hold up. Orchestration is where judgment lives, and judgment errors multiply across every subagent you spawn.

When a single agent is still the right answer

The skeptic's section, which I stand by even with the training improvements.

Sequential work should stay sequential. If step two needs step one's output, delegation adds context-passing overhead and buys nothing.

Small tasks don't need a committee. If a single agent finishes in ten turns, splitting it into three agents costs more and finishes later.

Shared mutable state is a trap. Subagents editing the same files concurrently produces conflicts that cost more to resolve than the parallelism saved. Give each subagent its own scope, or its own worktree, or don't parallelize.

Debuggability degrades. One transcript is readable. Twelve interleaved transcripts are an investigation. Budget for tracing before you fan out, not after something goes wrong.

The test I apply now: can I describe each subtask to a contractor who has never seen this project, in one message, and get back something I can use without a conversation? If yes, delegate. If I'd need a back-and-forth, the work isn't independent and one agent should do it. Muse Spark's training makes the delegate side of that line more reliable. It doesn't move where the line is.