Coordination loops

Different problems want different shapes of coordination. A research task might plan, run workers, verify their findings, and replan until coverage holds. A hard question might have several agents argue it over a few rounds and reduce their answers to one. A high-stakes answer might be drafted many times in parallel and the consensus kept. apomesh treats that coordination shape as a first-class, selectable thing — a coordination loop — not something baked into the agent. This section explains the loops the platform ships, how one is chosen, and why the choice is reproducible.

For where sessions sit overall, see the architecture overview.

What it governs

Every session runs under exactly one coordinator — the component that drives the agents through their phases and owns the session’s loop. The orchestration-strategy plane governs which coordination a session gets, along two axes:

• The skeleton — the control-flow topology itself (plan-execute-verify-replan; fan-out-and-reduce; a multi-round debate). A skeleton is substrate code with its own flow contract; you pick from the ones the platform ships. On the wire a skeleton is a SessionKind value.
• The configuration — an addressable, versioned StrategyConfiguration layered on a skeleton: its parameters and plug-ins (how many lanes, how many rounds, how answers are reduced), named like io.descoped/deep-research-vmao@1.0.0.

What the plane deliberately does not govern: what the work is (the domain — research, coding) and how each model call is composed (the context plane). Those are separate axes, so the same domain can run under different loops.

The shipped loops

apomesh ships four coordination loops, each registered in the daemon and each standing on a recognizable, proven pattern:

Loop	What it does	Pattern
VMAO	plan → execute → verify → replan | synthesize — the default	plan-execute-verify generator-critic loop
Evaluator-optimizer	one draft, graded against a rubric, refined until it passes	Self-Refine / Reflexion / CRITIC
Parallel-sample	K independent samples, reduced to one answer	self-consistency / best-of-N
Debate	N agents argue over R rounds, then a reducer decides	multi-agent debate (MAD)

Each loop has its own page above. The shipped Deep Research domain runs under either VMAO or debate — same domain, different loop — which is the whole point of separating the two axes.

How selection works

Rendering diagram…

A session's loop = a skeleton bound by a configuration, selected at launch or locked by a published agent, then pinned for the session's life

Selected at launch. A start request — from the console’s Configure & Launch picker, the SDK, or REST — can name the strategy configuration it wants. When it doesn’t, apomesh folds through the bound agent in a fixed precedence: an explicit configuration reference wins; then a bound manifest’s strategy lock; then an explicit SessionKind; then the manifest’s declared kind. So an agent’s intended loop is honored rather than ignored, and an explicit choice always overrides.

Locked by a published agent. A published agent is a fully pre-configured, version-pinned shape, and its coordination loop is part of what’s sealed at publish time. Starting from a published agent gives you that locked loop exactly — it is not selectable at launch, because the point of publishing is a reproducible, tamper-proof shape.

The shipped configurations

The substrate seeds two named configurations into the dev tenant at boot, so the launch picker offers real choices out of the box — the same Deep Research domain under two different loops:

Configuration	Skeleton	Locked parameters
io.descoped/deep-research-vmao@1.0.0	VMAO	domain defaults
io.descoped/deep-research-debate@1.0.0	Debate	N = 3 lanes, R = 2 rounds, majority-vote reducer

Two shipped published agents lock these in turn: io.descoped/deep-research locks the VMAO configuration, and io.descoped/deep-research-mad locks the debate configuration.

Guarantees

• One coordinator per session. Loops combine only by nesting a sub-session, never by interleaving phases within a session.
• Fixed phases. A loop’s phases run in a fixed order at fixed positions — a strategy cannot synthesize before it verifies, or skip planning.
• Deterministic and reproducible. On start, the resolved SessionKind and the folded parameters are pinned into the durable SessionStarted event. A resume replays that pin without re-resolving, so a recovered session runs the same loop it started — and two runs of the same configuration are the same coordination. See Reconstruction & recovery.
• Open, not black-boxed. Each loop implements a pattern the closed platforms keep behind an API — inspectable on the event log, reproducible from the pin.

Where this heads next

The plane is built to grow: additional skeletons are on the roadmap as directional work, not shipped today — a blackboard loop (reactive triggers over shared state), a deliberative-search family (scored frontier with backtracking, in the tree-of-thoughts lineage), and a router / swarm family (conditional dispatch and handoff). Each is a new SessionKind peer over the same governed core; none is available yet.

Where this shows up

• Operate: The operator console selects a strategy configuration on the Configure & Launch surface.
• Build: Deep Research is the worked domain that ships under both the VMAO and debate configurations.
• Reference: the orchestrator coordinator and catalog crates under Reference.