Agent Orchestration Platforms Explained

An agent orchestration platform is a runtime layer that sits above individual coding agents and coordinates many of them at once: it decides who works on what, gives them a place to share state, and tracks the work to completion. This note explains the idea, takes Ruflo (formerly Claude Flow) as the lead example, compares it with three other ways people run agents in parallel, and lays out when the whole category is the wrong answer.

All tool-specific facts were checked against primary sources on 2026-10-13; URLs are in the References section. Where a claim comes only from a project’s own marketing, it is labeled as such.

1. Why this category exists

A single coding agent has two hard limits. Its context window fills up and degrades over a long task (see Context-Rot-and-Governing-Context), and it works serially, one tool call after another. Orchestration platforms attack both limits the same way a cluster attacks the limits of one node: split the job, run the pieces on separate workers, and add a control plane to keep the pieces consistent.

  • The analogy that fits best is a batch scheduler. Slurm takes a job, places tasks on nodes, tracks their state, and collects results. An orchestrator does the same with agents instead of processes, and a task list instead of a job queue.
    • The difference that matters: Slurm’s workers are deterministic programs. An orchestrator’s workers are language models that may misread the task, report success falsely, or wander off scope. Most of the trade-offs in section 5 follow from that one fact.

2. The core concept: orchestration versus a single agent with subagents

The distinction people blur most often is between a single agent that delegates and a system that coordinates peers.

  • Single agent with subagents. One main agent spawns helpers, each with a fresh context, and each returns its result to the agent that spawned it. This is essentially hub-and-spoke: the main agent holds the control flow and decides what happens with each result. Think fork() plus wait(), with one qualification: in current Claude Code, subagents that were given a name when spawned can send each other messages, so the spokes are not fully isolated. There is still no shared task list or work queue, and results still return to the caller.
  • Orchestrated multi-agent system. Several agents run as peers or in a managed hierarchy, coordinate through shared structures (a task list, a message bus, a memory store), and may claim work on their own. Think a thread pool pulling from a shared work queue, with message passing between threads.
    • The extra machinery is exactly what a distributed system needs: a scheduler, shared state with some consistency model, and a way to detect stalled or failed workers.

Topologies

Orchestrators borrow network and cluster vocabulary for how agents are wired together. The terms below are the ones Ruflo’s own docs use, and they are general enough to apply elsewhere.

TopologyShapeSystems analogyGood for
Hierarchical (“queen/workers”)One coordinator assigns tasks, workers report backMaster/worker, a head node and compute nodesSmall teams with clear decomposition
MeshPeers talk directly, no central authorityPeer-to-peer overlayExploratory work where agents challenge each other
Hierarchical-meshCoordinator over clusters of peersRack-level switches under a spineLarger teams split into sub-groups
Ring / pipelineEach agent hands off to the nextA Unix pipelineStaged work (design, implement, test)
StarA hub routes messages but does not commandA message brokerLoose coordination

The “queen” and “hive mind” language that shows up around Ruflo is branding for the hierarchical case: the queen is the scheduler, the hive is the worker pool.

The shared pieces every platform needs

  • A task queue. Work items with states (pending, in progress, done) and dependencies, so that finishing one item unblocks the next.
    • The hard part is the same as in any queue: two workers must not claim the same item. Claude Code’s agent teams, for instance, use file locking on task claims for exactly this reason.
  • Shared memory. A store all agents can read and write, so findings survive beyond any one agent’s context.
    • Treat it like a shared filesystem or key-value store, with all the consistency problems that implies. Two agents writing the same key, or one agent reading a stale fact another has since corrected, are ordinary failure modes, not edge cases.
  • Tool access. Agents reach tools and data through the Model Context Protocol (MCP, covered in the AI Agents primer course). An orchestrator often exposes its own control functions (spawn an agent, store a memory, check status) as MCP tools, so the coding agent drives the orchestrator through the same interface it uses for everything else.
    • Coordination across organizations, between agents you don’t own, is a different problem with its own protocol, Agent2Agent (A2A), also covered in the AI Agents primer course.

3. Ruflo in depth

What it is, verified

  • Name and lineage. Ruflo is the current name of the project formerly called Claude Flow. Its README opens by announcing the rename, and the GitHub repository is now ruvnet/ruflo.
    • The maintainer is Reuven Cohen, GitHub handle ruvnet (npm author “RuvNet”).
    • Old names persist: the npm metadata still points at the claude-flow repository URL, and the project publishes three packages together (ruflo, claude-flow, and @claude-flow/cli).
    • Secondary sources date the rename to the v3.5 release in February 2026 and attribute it to trademark concerns. I could not confirm either the date or the reason in the project’s own release notes, so treat both as unverified.
  • Version. The npm latest tag is 3.56.9, matching a GitHub release dated 12 October.
    • The README and wiki still mention older version numbers (v3.8.0 and v3.10.1) in places. The docs lag the code, which is worth knowing before trusting any specific page.
  • License and activity. MIT. The GitHub API reported about 74,500 stars and 8,900 forks on 2026-10-13, with commits pushed that day. The repository was created in June 2025.
  • How it describes itself. The README calls Ruflo an “agent meta-harness for Claude Code and Codex.” The GitHub description frames it as a harness for multi-agent swarms, autonomous workflows, adaptive memory, and federation across machines.

Architecture, as the project describes it

The README draws the flow as user, then CLI or MCP, then a router, then a swarm of agents, backed by memory and by LLM providers. The README itself labels this diagram “a conceptual flow, not a live execution trace,” which is a fair warning about how to read the rest.

  • Integration with Claude Code. Ruflo registers as an MCP server inside Claude Code and installs hooks that route tasks and record patterns automatically. It also ships as a set of Claude Code plugins.
    • The README counts 314 MCP tools, 26 CLI commands, and roughly 100 agent definitions (one table says 98, other places say “100+”).
  • Hive mind. The wiki describes a queen-led hierarchy with worker, specialist, and scout roles, started with a hive-mind init command that takes a topology, a maximum agent count, a queen ID, and a consensus algorithm.
    • Offered topologies: hierarchical, mesh, hierarchical-mesh, ring, star, and adaptive.
    • Offered consensus schemes: Byzantine fault tolerance (PBFT), Raft, gossip, CRDTs, and simple quorum voting.
    • All agents can read and write a shared hive memory through hive-mind memory subcommands.
  • Memory. Vector memory in a store called AgentDB with an HNSW index (approximate nearest-neighbor search), plus a local vector and graph store and session save/restore. “Self-learning” components named SONA and ReasoningBank sit on top.
  • Providers. The README lists Claude, GPT, Gemini, Cohere, and Ollama with routing and failover between them.
  • Install. npx ruflo@latest init wizard for a guided setup, or claude mcp add to register the MCP server directly.

Where the claims outrun the evidence

Ruflo’s documentation makes many quantitative claims. None of the following were independently verified for this note, and several are disputed.

  • Project’s own performance claims. The README reports HNSW search roughly 1.9x faster than brute force at 20,000 vectors, “89% accuracy” for its routing, “sub-ms retrieval,” and wins of 1.3 to 1,953 times over LangGraph, AutoGen, and CrewAI on cold start, single-turn latency, and memory use.
    • To its credit, the README notes that approximate search ties or loses at small sizes. The routing-accuracy figure has no published methodology.
  • A user audit disputes how much is real. A GitHub discussion posted on 2026-04-04 against v3.5.51 classified roughly 10 of 300-plus MCP tools as doing real work (memory, embeddings, session persistence, terminal execution) and the rest as stubs that record JSON state without executing anything.
    • Specific allegations: agent spawning creates a map entry rather than a process; all consensus algorithms route to the same handler; signature verification always returns true; and the token-savings claims rest on a hardcoded baseline. The author also estimated that Ruflo adds 15,000 to 25,000 tokens of context per session.
    • No maintainer reply appeared on that discussion. This is one user’s audit of a version six months and dozens of releases old; I did not check the claims against current source code. Later release notes do show stub responses being relabeled as no-ops, which suggests the maintainers are aware of the issue.
  • The docs hedge themselves. Beyond the “conceptual flow” label, the README states that demo media are not evidence of completed swarm work, and that plugin “mods” are not sandboxed.
  • My inference about how work actually executes. The hive-mind wiki example drives work through Claude Code’s own Task and SendMessage calls. Taken with the audit, the likeliest reading is that Claude Code does the generation and Ruflo supplies coordination state, memory, and prompts through MCP. The docs do not say this plainly, so treat it as an inference until you have watched it run.

Bottom line on Ruflo: it is a large, very active, popular project with a real memory subsystem and an ambitious feature list, and its documentation mixes working features, aspirations, and unverified numbers without always marking which is which. Evaluate any specific capability by running it and inspecting what happened, not by reading the feature table.

4. Other approaches, compared

Orchestration is not one product category so much as a spectrum, from “a person running several terminals” to “a framework where you code the control flow yourself.”

  • Claude Code agent teams (native, experimental). One Claude Code session acts as team lead and spawns teammates, each a separate Claude Code instance with its own context. They share a task list with dependencies and talk through per-agent mailboxes, which are JSON files on disk.
    • Off by default; enabled with an environment variable. Documented limits include no nested teams, one team per session, no resume for in-process teammates, and task status that can lag.
    • Anthropic’s docs say plainly that teams use “significantly more tokens” than a single session, that cost scales linearly with teammates, and that subagents or one session are better for sequential work or same-file edits. They suggest starting with three to five teammates.
  • Parallel-session tools built on isolated workspaces. These do not coordinate agents with each other at all. They give each agent its own branch and working copy and give you a dashboard for reviewing and merging the results. The human is the orchestrator.
    • Conductor is a macOS app that runs Claude Code, Codex, and Cursor agents in parallel, each task with its own workspace, branch, terminal, and diff. Its docs did not say whether it uses git worktrees under the hood.
    • Vibe Kanban puts the same idea behind a kanban board and supports ten-plus agent CLIs. Its maker, Bloop, shut down on 2026-04-10; the Apache-2.0 project continues as community-maintained and local-only.
    • Claude Code’s docs describe the do-it-yourself version of this pattern: several sessions in separate git worktrees, no automated coordination.
  • Framework-level orchestration. Here you write the orchestrator yourself in code. This is where orchestration belongs when you are building an agent product rather than driving a coding assistant.
    • LangGraph calls itself “a low-level orchestration framework and runtime” for long-running, stateful agents, with durable execution and human-in-the-loop as core features. You define the control flow as a graph.
    • CrewAI offers sequential and hierarchical processes; the hierarchical one adds a manager agent that plans, delegates, and reviews, which is the queen/worker pattern in framework form.
    • The AI Agents primer course compares LangGraph and CrewAI in depth, explains how runtimes, frameworks, and harnesses differ, and covers Deep Agents, a harness that sits between the two worlds.
ApproachWho coordinatesAgents talk to each other?Shared stateMaturity signal
SubagentsThe main agentLimited: named subagents can message each other; results return to the callerCaller’s contextStable, documented
Claude Code agent teamsA lead sessionYes, via mailboxesTask list on diskExperimental, documented limits
RufloRuflo’s router and queen, through MCP and hooksClaimed, via hive memory and consensusVector memory storeVery active; features partly disputed
Conductor / Vibe KanbanYouNoGit branchesConductor commercial; Vibe Kanban community-maintained
LangGraph / CrewAIYour codeAs you design itAs you design itEstablished frameworks

5. Trade-offs, and when one agent is the better answer

The design-pattern decision tree in the AI Agents primer course makes the general argument: reach for multi-agent only on a demonstrated bottleneck of specialization or scale, never as a preference. Orchestration platforms make that mistake cheaper to commit, so the costs deserve a list.

  • Cost multiplies with fan-out. Every agent carries its own context, its own system prompt, and its own copy of whatever project files it reads. Five agents is roughly five times the tokens before any coordination messages.
    • Platform overhead adds to this: if the audit above is right, Ruflo’s own tool definitions and prompts cost tens of thousands of tokens per session before any work starts.
  • Coordination overhead grows faster than the team. Messages, task handoffs, and consensus rounds are all extra model calls. Anthropic’s guidance on team size boils down to: small, independent tasks, and fewer agents than you think.
    • The consensus menu in Ruflo’s docs is a tell. PBFT exists to tolerate malicious nodes in a replicated state machine; applying it to five instances of the same model on one laptop solves a problem you probably don’t have.
  • Non-determinism compounds. One agent’s output varies run to run. A swarm of them, choosing different decompositions and claiming tasks in different orders, makes reruns diverge and makes “it worked yesterday” uninformative.
  • Debugging a swarm is distributed-systems debugging. When the result is wrong, you need to know which agent produced which change, from which inputs, after which message. Without per-agent transcripts and traces you are reading interleaved logs from a cluster with no timestamps.
    • Concurrent edits are the classic failure: two agents changing the same file overwrite each other. Every tool in section 4 tells you to partition work by file ownership for this reason.
  • Success signals are weak. A worker reporting “done” is a claim, not evidence. Agent teams’ docs note that the lead can declare victory early and task status can lag; the same applies to any swarm. Verify the artifact (tests pass, the file exists, the diff is right), not the status.
  • When one agent wins. Sequential work, anything touching the same files, small tasks where coordination exceeds the work, and any task where you need to understand exactly what happened. A single session with a subagent or two for noisy side-investigations covers most real coding work.
  • When orchestration earns its cost. Genuinely independent pieces of work (separate modules, separate hypotheses, separate review lenses), where wall-clock time matters more than tokens and where you can verify each piece on its own.

6. How this layer relates to the other three

Four kinds of tooling get marketed under overlapping words. They are layers, not competitors, and a team might use one of each.

  • Skills are reusable capabilities an agent loads on demand: packaged instructions and scripts for a recurring job. Module 3 of this course covers them.
  • Spec-driven development systems produce artifacts that pin down what to build before an agent starts writing code: requirements, a design, and a task breakdown that the agent then works through.
  • Methodologies define the process: which roles exist (analyst, architect, developer, reviewer), what order they work in, and what each hands to the next.
  • Orchestration platforms are the runtime that actually runs many agents at once and coordinates them.

The layers stack naturally: a methodology defines the roles, a spec system produces the documents those roles consume, skills give each role its capabilities, and an orchestrator runs several role-agents concurrently. The confusion comes from products that span layers; Ruflo, for example, bundles agent definitions and workflow methodologies alongside its runtime. When evaluating one, ask which layer each feature actually belongs to.

References

All checked 2026-10-13.