Methodology · Multi-Agent Designprovenverified

Orchestration Pattern Selection

also known as workflow-vs-autonomous selection, multi-agent orchestration taxonomy

Applies to: multi-agent-systemagent

Tags: orchestrationtaxonomyselectionhybrid-composition

Before you wire agents together, decide how they will be coordinated. There are two families. In a Workflow the steps are fixed and you can see the control flow, such as run in order, branch on a condition, or fan out in parallel. In an Autonomous setup the agents decide the flow themselves, such as planning, handing off, or chatting as a group. Compare the two on a few things: how predictable they are, how fast, how easy to observe, how much they cost, and how they tend to fail. Pick the simplest one that does the job. If neither family fits on its own, mix them. You can wrap a fixed workflow around an autonomous core, or drop autonomous agents inside workflow stages. The common mistake is to skip this comparison and reach straight for full autonomy. That gives you an agent graph nobody can watch or debug.

Methodology process overview

flowchart TD start[Task decomposition + constraints] --> classify[Classify candidate topologies] classify --> wf{Workflow family fits?} wf -- yes --> wfpick[Pick sequential / conditional / parallel] wf -- no --> auto{Autonomous family fits?} auto -- yes --> autopick[Pick plan-execute / handoff / group-chat] auto -- no --> hybrid[Compose hybrid: workflow shell over autonomous core] wfpick --> score[Score against predictability, latency, observability, cost] autopick --> score hybrid --> score score --> pick[Apply selection criteria: weakest topology that solves] pick --> doc[Document rejected alternatives] doc --> out[Selected orchestration + rationale]

Intent. Make a deliberate choice between a fixed workflow and a self-directing setup, judged against named criteria, before any agent graph is written in code.

When to apply. Use this when you design a multi-agent system from scratch. Also use it when an existing system fails in ways its current coordination cannot handle. Apply it when you can name the task but cannot yet defend one topology over the others. Don't apply it for a single agent with one tool, because there is no coordination choice to make. One exception: if your platform forces one family, such as a strict workflow engine or a swarm-only runtime, then you only choose within that family.

Example scenario

A platform team at a B2B analytics company is wiring up an internal 'data question' assistant. Here is the task. A user asks a plain-language question about their warehouse. The system fetches the right slice of schema, drafts SQL, runs it against a sandboxed replica, and returns a chart with prose. The team's instinct was 'multi-agent group chat with a planner, an analyst, and a charter agent.' Applying the methodology, they classified that candidate as Autonomous (group-chat). When they scored it, group-chat lost on predictability, because the planner kept reopening decisions. It also lost on observability, because there was no clean per-stage trace. A workflow alternative ran the steps in order: schema-fetch, then SQL-draft, then SQL-execute, then chart-render. It won on every criterion except the rare 'multi-warehouse join' query class. They picked the workflow as the main topology. They added a single autonomous escape hatch that the planner could trigger for joins. They documented the mix: a workflow shell, with a self-directing sub-team called only for the join class. What they learned: writing down the rejected group-chat design, and the criteria it lost on, mattered. Four months later it stopped a junior engineer from 'simplifying things by going group-chat again.' The reasoning, not the topology, was the lasting artefact. Per-stage P95 latency dropped from 38s to 11s once they stopped paying for emergent coordination on every query.

Inputs

Task decomposition — The user-facing task broken down into jobs that single agents could own.
Operating constraints — The limits you have to live with. How much latency you can spend, how much cost you can spend, what you need to be able to observe, and how much unpredictability you can accept.
Candidate patterns — The set of coordination shapes you can choose from, such as run in order, branch, run in parallel, plan-and-execute, hand off, group chat, or a mix.

Outputs

Selected orchestration pattern — The chosen pattern, with its family stated outright as Workflow or Autonomous.
Selection rationale — A written case for the choice. It scores the chosen pattern against the alternatives on each criterion.
Hybrid composition (optional) — If neither family fits alone, the exact way you combined them. For example, workflow stages wrapping a self-directing sub-team.

Steps (5)

Classify candidate orchestrations into the taxonomy
Tag each plausible topology. It is Workflow if the steps are fixed: run in order, branch, or run in parallel. It is Autonomous if the agents decide the flow: plan, hand off, or group chat. If a topology cannot be tagged, it is too vague. Go back and break it down further.
usesOrchestrator-Workers Handoff Group-Chat Manager Parallel Fan-Out / Gather
Score against comparative criteria
Score each candidate on five things: how predictable it is, how fast, how easy to observe, how much it costs, and how it tends to fail. Workflow usually wins on predictability and on being easy to watch. Autonomous usually wins on flexibility and on handling tasks you did not script.
usesPlan-and-Execute
Apply selection criteria
Pick the most constrained, most explicit shape that still solves the task. Autonomy costs you in observability and in guardrails. Only buy as much of it as the task actually needs.
Compose hybrids when no single pattern fits
Sometimes you need both predictability and the ability to handle unscripted tasks. Then wrap a self-directing sub-team inside a fixed workflow, or slot workflow stages between autonomous segments. That combination becomes its own named topology.
usesOrchestrator-Workers Group-Chat Manager
Document the rejected alternatives
Record what you considered and why you turned it down. The next team inherits both the choice and the reasoning. Without the reasoning, the design drifts back to whatever feels fashionable.

Framework-specific instructions

Pick a framework and generate a framework-targeted rewrite of this methodology's steps.

Choose framework

AI-generated for Agent Development Kit (ADK) (Google) — verify against official docs.

Principles

Pick the most constrained coordination that still solves the task. You pay for autonomy in observability.
Hybrids are named, documented combinations. They are not undocumented escape hatches.
Every choice writes down what it rejected. Without that, the choice cannot be audited.
Workflow and Autonomous are families, not answers. Never pick 'multi-agent' without naming the actual pattern.

Orchestration Pattern Selection

Methodology process overview

Steps (5)

Classify candidate orchestrations into the taxonomy

Score against comparative criteria

Apply selection criteria

Compose hybrids when no single pattern fits

Document the rejected alternatives

Framework-specific instructions

Principles

Known failure modes (3)

Related patterns (5)

Sources (2)

Provenance