GOP 3 Orchestration

GOP-3 · Orchestration

Answers: who does the work next?

Capable agents with no coordinator do not self-organise — they thrash. GOP-3 defines routing and, critically, the hard ceiling that stops an endless retry.

The five invariants

ID	Requirement
GOP-3.1	Decompose with done_when — no sub-task without checkable completion criteria
GOP-3.2	Capability-match routing — assign by fit, never by availability
GOP-3.3	Loop guard enforced — hard ceilings on attempts/handoffs/steps; on trip → human
GOP-3.4	Orchestrator obeys the gates — cannot override a GPS-2 DENY, a GTS-1 done_when, or a human gate
GOP-3.5	Human-visible close — every workflow ends with a summary a human can audit

The coordinator is not a superuser

GOP-3.4 is the invariant people are most tempted to break, because an orchestrator that can override gates is convenient — it unblocks stuck workflows. It is also the single change that converts a governed system into an unaccountable one: every permission decision becomes advisory the moment one component can wave it away.

The loop guard

Unbounded retry is how a multi-agent system burns budget and produces nothing. The guard sets hard ceilings; when it trips, the workflow escalates to a human rather than retrying:

#   ✅ inv3: loop guard escalates (human_gate set)
#   ✅ inv3: loop guard event logged

The trip is itself an audit event — "this workflow could not converge" is information, not noise.

Honest failure over fake completion

An agent that cannot proceed sets status blocked with a reason. It does not mark the task done. The suite verifies this directly:

✅ honest failure: status blocked, not fake-done

⚠️ GOP-3.2 (routing-by-fit) and GOP-3.5 (human-visible close) are not yet automated — an open item tracked honestly in Conformance §5.1.

---

📖 Spec: spec/GOP-3-orchestration.md → Next: GOS-0 Constitution