Orchestrating parallel agents without Durable Functions

The moment a system grows past one AI agent, the instinct is to reach for an orchestration runtime — something durable, stateful, with a workflow engine. Sometimes that instinct is right. More often it answers a question nobody asked, and the real problem goes untouched.

I learned this building a trading-research assistant as a family of skills. Ask it to analyze a ticker and an orchestrator dispatches five specialist agents in parallel — technical, fundamental, sentiment, and the rest — then folds their findings into one composite score. There is no workflow engine anywhere in it. There is also nothing fragile about it, and the reasons why generalize.

The real problem is decomposition

A single agent asked to do a large, multi-faceted job produces confident mush. Not because the model is weak — because the job was never one job. "Analyze this" is really five questions wearing a trench coat: each with its own method, its own data, its own idea of what a good answer looks like.

The first move in any multi-agent system is honest decomposition. Name the independent dimensions. Give each one an agent that does that one thing well. The quality of the whole system is set here, before a line of orchestration code exists. Anthropic's Building Effective Agents makes the same point from the other direction: find the simplest structure that fits the task, and only add machinery when the task demands it. Their taxonomy is worth internalizing — parallelization when the subtasks are known up front (my case), orchestrator-workers when a lead model has to discover the subtasks at runtime.

And decomposition has a failure mode worth naming, because it's the strongest argument against multi-agent systems in circulation. Cognition's Don't Build Multi-Agents documents what happens when parallel subagents share context they can't see: each one fills the gaps with assumptions, the assumptions conflict, and the synthesis step inherits compounded errors. Their conclusion — keep work single-threaded — is right for their domain, which is writing code, where every subtask touches the same evolving artifact. The line I draw from both essays: decompose along dimensions whose results merge as data — scores, findings, structured facts. If the outputs can only merge as interleaved edits to one artifact, the dimensions weren't independent, and parallelism will manufacture conflicts instead of saving time.

Three things you actually need

Once the work is decomposed, reliable multi-agent behavior comes from three capabilities — none of which requires a durable workflow engine.

Routing. Not every request needs every agent. A small routing layer reads the request and dispatches it to the skills that actually apply — and it can be embarrassingly simple: a keyword map, a switch on request type, at most one cheap model call. This keeps cost and latency proportional to the question, and the proportionality matters more than it looks. Anthropic reports that multi-agent runs burn around 15x the tokens of a chat interaction, which is why their production research system scales effort explicitly: one agent and a few tool calls for simple fact-finding, ten-plus subagents only for genuinely complex research (How we built our multi-agent research system). Routing is where you encode that judgment.

Parallel execution. The independent agents are, by construction, independent — so run them at the same time. The wall-clock cost of the system becomes the cost of its slowest agent, not the sum of all of them. This is the multi-agent payoff with actual evidence behind it: Anthropic's orchestrator-worker system beat a single-agent baseline by 90.2% on their internal research eval, and cut research time on complex queries by up to 90% — precisely because research, like analysis, is read-heavy work that parallelizes cleanly.

A scoring discipline. Five agents return five answers. If you stop there, you have opinions, not a decision. A synthesis step combines them into a composite result on one scale, with weights you wrote down and can defend. In the trading system it looks like this:

composite = 0.30·technical + 0.30·fundamental + 0.20·sentiment + 0.20·risk
# every sub-score normalized 0–100 before weighting; weights versioned with the code

The exact numbers matter less than the properties: every agent reports on the same scale, the weights live in one visible place, and when the composite surprises you, you can trace which dimension moved it. This is the part teams skip, and it is the part that makes the output trustworthy.

One refinement worth stealing: treat disagreement as signal, not noise. When the technical agent scores 80 and the fundamental agent scores 35, the weighted average is the least interesting fact about that run — the divergence is the finding. A good synthesis step reports the composite and flags the spread, because a stock that's technically strong and fundamentally weak is a different decision than one that's mediocre everywhere, even when the two average out identically.

Multi-agent reliability is routing, parallel execution, and a scoring discipline. The workflow engine is optional. The scoring discipline is not.

Skills that compose

Build each agent as a skill that works two ways: standalone, callable on its own, and as a participant in an orchestrated run. When skills compose like this, growing the system means adding a skill — not rewiring the orchestrator.

The trading system proved the property twice. It started with five core analyses and grew to fifteen skills — screening, earnings previews, options strategy, portfolio review — without the orchestrator changing, because adding the sixth never touched the other five. And the dual-mode design pays off in use, not just in growth: mid-conversation, reviewing a shortlist of candidate positions, I can invoke the same technical and options skills directly on each one — no orchestrated run, no ceremony. The skill doesn't know whether an orchestrator or a human called it. That indifference is the composability test.

Where this ends

Be honest about the boundary. This lightweight pattern is the right answer when the work fits inside a request: fan out, run in parallel, synthesize, return. It is the wrong answer when you genuinely need durability — workflows that run for days, that pause for human approval and resume next week, that must survive process restarts mid-run. That is what a durable orchestration runtime is for, and when you need it, use it.

And it's worth saying plainly: the durable side of this trade-off has gotten genuinely good since I first wrote this. Azure's Durable Task Scheduler — a managed backend for durable execution — went GA, removing most of the operational tax that used to make Durable Functions feel heavy (Durable Task Scheduler). Microsoft now documents agentic patterns on the Durable Task framework directly — fan-out/fan-in for parallel agents, orchestrator-workers, evaluator-optimizer loops, human-in-the-loop via external events — the same taxonomy Anthropic sketched, with checkpointing under it. The boundary hasn't moved, but crossing it costs less than it did.

I've designed on that side of the line too — a multi-round deliberation system with human approval gates between rounds, exactly the shape that earns durable execution. Even there, the discipline held: the engine is a host-agnostic library, the console runner hosts it locally, and the durable runtime is a hosting decision for the phase that needs replay and external events. The orchestration runtime is something the system wears, not something it is.

Most multi-agent systems are not that. They are a hard question that decomposes into parallel parts and needs to come back as one scored answer. For those — and there are a lot of them — routing, parallelism, and a scoring discipline are the whole architecture.