Agent Orchestra

Agents can work. They cannot declare success.

Every multi-agent project eventually meets the same failure: an agent says it is done, and nothing in the system is able to disagree. Agent Orchestra Protocol removes that possibility - by making the interesting rules checks in code rather than requests in a prompt.

AGENT MAY                    AGENT MAY NOT
  claim work                   silently overwrite another agent's resource
  own resources                verify its own L2/L3 work
  implement                    pass verification without evidence
  hand off                     retry forever after failing
  verify others' work          perform an external action without approval
  produce graded evidence      declare success without satisfying the gate

Measured, not asserted

node bench/protocol-benchmark.mjs runs six failure modes through three coordination models with deterministic actors and no model calls. Re-run it and you get the same table:

Scope, stated plainly: this measures the coordination layer - which failure modes get through - not model quality. The gate re-runs it on every change, so the table cannot drift from reality.

Eight contracts, each enforced

AGENT-ORCHESTRA-PROTOCOL.md is the normative document. Every contract names the code that enforces it, the behaviour on violation, the test that pins it, and its honest limit:

• Task - a unit of work has a type, a rigor level (L1 local / L2 shared / L3 consequential), an owner at every stage, and a spec + acceptance criterion before implementation starts.
• Resource - tasks declare the resources they write; overlapping claims are refused and the refusal names the holder. One writer per resource, not just per task.
• Ownership - exactly one agent holds a task; state changes are atomic, locked, and appended as events.
• Handoff - work crossing a session or tool boundary passes through a shared record, which outranks the queue and is checked rather than trusted.
• Verification - the verifier is never the implementer at L2/L3, a PASS carries its witness, a failure blocks both done and dispatch to evidence, and consequential work adds a domain review by a third party.
• Evidence - E1 (reproducible: command, exit code, revision), E2 (a named peer, not the author), E3 (self-report, labelled), E4 (planned). A bare sentence can never pose as proof.
• Approval - external actions cannot be dispatched until approved, and the approval scope must cover the action: 'staging' does not unlock production.
• Recovery - three failed verifications block the task for a coordinator instead of burning tokens on an unbounded retry.

The contracts are written in terms of operations and observed behaviour, not of this CLI, so another host can implement them over its own storage and prove conformance with the same benchmark.

The unglamorous parts, done

• Zero dependencies, Node 18+. No install step, no lockfile, no supply chain.
• One gate command CI and your machine both run: 13 checks, and it injects eleven known faults it must reject before it reports PASS.
• 87 engine tests, 8 acceptance tests, 8 handoff tests, 83 activation cases; concurrency proven by four simultaneous task creations rather than asserted.
• 13 known limitations, each with an owner and a review date - including the honest ones: the queue is a plain JSON ledger, so this is a discipline cooperating agents follow and leave a record of, not a security boundary against an unwilling agent; and E1 is a structural check, not provenance - the engine confirms the fields, not that the command ran.
• Apache-2.0 for the code, CC BY 4.0 for the specification: the patent grant an implementer needs, and a specification licence that permits republication with attribution.

What it is not

Not an execution runtime: dispatch prints an argv array and never spawns an agent. Not a model router, not a cost model, and not a security boundary - all three are written down as limits rather than implied.