How should agents allocate contested work?

A specification with no implementation, built on another one.

Status

spec — A specification, and this page. Capability bidding, overlap detection, negotiation, peer voting, leader election under Ra, quorum-validated execution and a reputation ledger are described in detail, and no line of any of it has been written. It is built on the Deliberatic protocol, which is also a specification.

Last verified

2026-08-16

Source

docs/spec/README.md in this repository, v0.2. Every section number cited on this page was checked to resolve in it on 2026-08-16, and the quorum module was counted rather than estimated — 21 lines, after an earlier draft said "forty" because forty sounded like the right size.

Limit

This establishes that a document exists and that it addresses the dimension the cited paper finds absent everywhere. It does not establish that a bid is well-calibrated, that a quorum rule survives an adversary, or that any of it runs. Nothing on this domain executes anything, and the worked trace below is an illustration from the specification rather than a recording of a system.

Next rung

in_tree — Code in a repository that implements the quorum module and passes a test against it. It is 21 lines and needs no cluster to try, which is the reason it is the thing this page asks for.

The dimension nobody encodes.

Five agent interoperability protocols were scored against six governance dimensions in June 2026. Voting came back absent in every one of them. Voting is what this specification is about.

How should agents allocate contested work?

What the specification says happens when two agents want the same thing.

This is the worked example from the specification. It is an illustration and not a recording — no system produced it, the agent names are invented for the example, and the confidences are figures in a document. The section header used to read “Live Deliberation Trace”, which was the one word on this page that could be read as a running system, and it is corrected here rather than left in place.

phase 1 — capability bidding
  legal-analyst    0.87  "Indemnification clauses map to my training domain"
  finance-scorer   0.82  "Can quantify financial exposure from risk clauses"
  summarizer       0.91  "Executive summary is my core capability"
  data-extractor   0.34  "Low relevance — I'll abstain"

phase 2 — overlap detected
  sub-task "risk classification" claimed by Legal and Finance
  → negotiation required

phase 3 — negotiation
  Legal    "Risk classification requires understanding clause intent,
            not just numerical exposure. I should lead — Finance can score after."
  Finance  "Risk without quantification is just a label. The user asked
            about financial risk specifically."

phase 4 — peer vote
  summarizer      → Legal  "Classification should precede quantification"
  data-extractor  → Legal  "Clause semantics are the harder subtask"

phase 5 — consensus reached
  legal-analyst elected leader for "risk classification"
  finance-scorer → support role · summarizer → executive summary
  data-extractor abstained · Raft term #47

Seven phases, and no human routing in the routine ones.

Every task triggers the full cycle. There is no hard-coded assignment anywhere in the specification: the agents organise themselves against each task, and the escalation path in §9 is what happens when they cannot.

Four ways to settle a round, and one of them refuses.

This is the whole quorum module as the specification states it. It is 21 lines — counted, after an earlier draft of this section said “forty” because forty sounded like the right size. It needs no cluster to try, which is why it is the thing this page asks you to implement.

defmodule AgenTroMatic.Quorum do
  @doc "Validates results against quorum policy."
  def validate(results, :majority) do
    approvals = Enum.count(results, & &1.approved)
    if approvals > length(results) / 2, do: :ok, else: {:escalate, :no_majority}
  end

  def validate(results, :unanimous) do
    if Enum.all?(results, & &1.approved), do: :ok, else: {:escalate, :not_unanimous}
  end

  def validate(results, :weighted) do
    weighted_sum = Enum.sum(for r <- results, r.approved, do: r.voter_reputation)
    total_weight = Enum.sum(for r <- results, do: r.voter_reputation)
    if weighted_sum / total_weight >= 0.7, do: :ok, else: {:escalate, :below_threshold}
  end

  def validate(_results, :human_in_the_loop) do
    {:escalate, :requires_human_approval}
  end
end

A domain template binds a different rule per capability. In the specification's financial-services example the default is :weighted, risk_assessment is :unanimous, trade_execution is :human_in_the_loop, and reporting is :majority — with an escalation target and a round cap alongside. That last clause is G5 in the place it actually lives: a rule that returns an escalation instead of a verdict.

Static routing is the wrong abstraction.

When agent capabilities overlap and evolve, a hard-wired graph breaks and nobody notices until the output is wrong. These are the four comparisons the specification makes, stated as positions rather than as results — none of them has been benchmarked, by us or by anyone.

Six components, none of them written.

Three things, and none of them is running it.

The rung is spec. A specification has nothing to run, so this page does not offer a button that pretends otherwise — that rule is enforced by the publication gate, which refuses to emit a page whose calls to action its rung has not earned.