One-Line Summary: Within the harness category there is a useful sub-distinction between single-agent harnesses (Claude Code, Codex CLI, Cursor) and orchestration frameworks / orchestration platforms (ruflo, OpenHands, AutoGPT-X) — the latter add multi-agent topology, swarms, federation, and autonomous loops on top of the harness loop.
Prerequisites: What is an AI harness, harness vs. framework vs. SDK
What Is an Orchestration Framework?
When the harness category split out as distinct from frameworks, a sub-split happened almost immediately: most harnesses did not orchestrate multiple agents, but a smaller group did, and the group that did had different concerns, different config surfaces, and different failure modes. Orchestration framework is the term that has converged for the second group: a harness that exists primarily to coordinate multiple agents.
The distinction is fuzzy at the edges — Claude Code has sub-agents, which is technically multi-agent — but the center is clear:
- Single-agent harness: one main agent in one loop, possibly with sub-agents that fan out and report back. Optimized for direct productivity. Examples: Claude Code, Codex CLI, Cursor, Aider.
- Orchestration framework / platform: many agents coexist, with topology, consensus, scheduling, sometimes federation. Optimized for long-horizon autonomy. Examples: ruflo, OpenHands, AutoGPT-X, Devin-class.
How They Differ
Think of three axes that separate them:
- Number of agents alive at once. Single-agent harnesses peak at "main agent + a handful of short-lived sub-agents." Orchestration frameworks have many agents, often persistent.
- Whether the user is in the loop on every action. Single-agent harnesses default to step-by-step approval; orchestration frameworks default to autopilot within budgets, with the user reviewing at checkpoints.
- Whether agents talk to each other vs. to the user. Single-agent harnesses funnel everything through user-visible turns; orchestration frameworks have inter-agent traffic the user mostly does not read.
Why It Matters
Choosing the wrong category for the problem is the single most expensive architectural mistake in agent systems. Forcing a multi-day-autonomous workflow into a single-agent harness leads to brittle prompt engineering and constant babysitting; forcing a tight inner-loop coding task into an orchestration framework adds latency, cost, and coordination overhead that the task does not need.
The boundary moves with model capability. As models get more reliable, more workflows can be safely autopilot — pushing more cases into orchestration territory. The course's bias is to teach you both shapes so you can pick deliberately.
Key Technical Details
- Orchestration frameworks usually layer on top of a harness, not next to it. Ruflo runs inside Claude Code; OpenHands runs as its own agentic-OS; both delegate the per-agent loop to lower layers.
- Topology configuration is the orchestration framework's signature. If a harness lets you choose between queen, mesh, and adaptive, it is an orchestration framework. If it does not, it is a single-agent harness.
- Background workers are an orchestration property. Single-agent harnesses can simulate them with hooks but the abstraction is not first-class.
- Cost models differ: orchestration frameworks burn more tokens per task by spawning multiple agents, but trade that for autonomy. Single-agent harnesses are cheaper per task but require user time per turn.
How Harnesses & Frameworks Implement This
| Harness / Framework | Category | Why |
|---|---|---|
| Claude Code | Single-agent (with sub-agents) | One loop; user-in-loop; sub-agents short-lived |
| Codex CLI | Single-agent | One loop; approval modes |
| Cursor | Single-agent | IDE-tight; one loop |
| Aider, Continue | Single-agent | Same shape as above |
| ruflo | Orchestration platform | Many agents, topology, federation, autopilot |
| OpenHands | Orchestration platform | Headless agent OS; multi-agent first-class |
| AutoGPT-X / Devin-class | Orchestration platform | Long-horizon autonomy default |
| LangGraph (with multi-agent) | Framework, not harness | Library you compose |
Connections to Other Concepts
what-is-an-ai-harness.md— The parent category.harness-vs-framework-vs-sdk.md— The orthogonal axis.topology-as-design-decision.md— Where orchestration frameworks differentiate.autopilot-modes.md— The user-experience axis.choosing-your-harness-stack.md— Capstone decision framework.
Further Reading
- Anthropic, "Building Effective Agents" (2024) — Argues for keeping orchestration minimal until proven necessary.
- ruvnet, ruflo documentation — A worked example of a full orchestration framework.