One Loop, Three Modes: A Practical Guide to Multi‑Agent Orchestration

If you have used AI coding assistants, you may have noticed that conversations start clear but become chaotic after about ten exchanges as the model’s context fills with noisy intermediate results.

The problem is not the model’s intelligence but the architecture: asking a single agent to carry an entire project leads to overload, similar to a project manager trying to write code, run tests, and update plans in one continuous thought stream.

Instead, view the AI as multiple agents: a parent orchestrator that plans and delegates, and child agents that receive focused prompts, perform a task, and return concise results. The parent never sees the clutter; it only sees summaries.

Running the Universal Agent Loop

Every agent—whether orchestrator, worker, or reviewer—executes the same loop: receive a prompt (with its tools), send it to the language model, get a response (text or tool request), execute any requested tool, feed the result back, and repeat until the task is marked complete or a round limit is hit.

Thus there is no separate “coordinator runtime” or “worker runtime”; the difference lies in each agent’s configuration: model choice, accessible tools, system prompt, and round limit.

This insight removes the need for distinct frameworks for different roles; a single loop with a flexible configuration interface can express all three orchestration modes.

Mode 1: Delegation

When the parent encounters a sub‑task it should not handle itself (e.g., searching a codebase for API endpoints or summarizing test coverage), it creates a self‑contained prompt and spawns a fresh child agent.

The child starts with a clean context, accesses the required tools, completes the work, and returns a concise summary instead of raw, verbose output.

The key is prompt self‑containment: the child can only act on information explicitly provided, forcing the parent to formulate clear, well‑scoped tasks. Delegation can be synchronous (parent blocks for the result) or asynchronous (parent receives an ID and polls later).

Mode 2: Swarm

For tasks that can be split into independent parallel parts (e.g., reviewing three modules, performing security, performance, and documentation audits), a swarm defines a team: a shared task description plus a list of agents, each with its own name, role, optional custom prompt, and tool set.

All agents launch simultaneously; when they finish, their outputs are collected into a structured result mapping each agent’s name to its findings.

Unlike multiple asynchronous delegations, the swarm treats distribution and aggregation as a single atomic operation, handling bookkeeping automatically.

Each swarm member should have a distinct configuration (e.g., a security‑focused system prompt, a performance‑focused one) while sharing the same underlying loop.

Mode 3: Coordinator

Complex, multi‑stage tasks (e.g., refactoring an authentication system) require a coordinator agent that plans, delegates, collects, synthesizes, and iterates without performing the implementation itself.

The coordinator follows a four‑stage rhythm: Research , Synthesis , Implementation , Verification . In research it spawns worker agents to gather information; in synthesis it merges findings and identifies gaps; in implementation it delegates concrete changes; in verification it creates validator agents to run tests and review diffs.

This rhythm is driven by prompts rather than a strict state machine, allowing the coordinator to skip or repeat stages based on intermediate results.

Hard Enforcement: Tool Partitioning

To prevent runaway delegation and context bloat, tools are partitioned into three categories:

Orchestration tools (agent creation, messaging, cancellation) – exclusive to the coordinator.

Execution tools (shell commands, file operations, search) – exclusive to workers.

Shared tools (e.g., task tracking) – available to both.

This guarantees that the coordinator cannot read files or run commands directly, forcing it to delegate, and workers cannot spawn further agents, preventing infinite delegation cascades.

Without these boundaries two failure modes appear: the “busy manager” (coordinator does work itself, polluting its context) and infinite delegation (agents recursively spawning sub‑agents, exploding API cost and context usage).

Choosing the Right Mode

The three modes form a complexity gradient; use the simplest effective one:

Clear, narrow tasks → Delegation.

Independent parallel subtasks → Swarm.

Multi‑stage, iterative tasks with dependencies → Coordinator.

When a single agent can answer within a few rounds, orchestration is unnecessary. The power of multi‑agent systems lies not in smarter individual models but in combining identical loops with distinct configurations, clear boundaries, and proper tool partitioning.