ietf-draft-analyzer/workspace/drafts/gap-analysis/draft-nennemann-agent-consensus-00.md

---
title: "Multi-Agent Consensus and Capability Negotiation Protocols"
abbrev: "Agent Consensus"
category: std
docname: draft-nennemann-agent-consensus-00
area: "OPS"
workgroup: "NMOP"
submissiontype: IETF
v: 3

author:
  - fullname: Christian Nennemann
    organization: Independent Researcher
    email: ietf@nennemann.de

normative:
  RFC2119:
  RFC8174:
  RFC7519:
  RFC7515:
  RFC9110:
  I-D.nennemann-wimse-ect:
    title: "Execution Context Tokens for Distributed Agentic Workflows"
    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
  I-D.nennemann-agent-dag-hitl-safety:
    title: "Agent Context Policy Token: DAG Delegation with Human Override"
    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

informative:
  RFC8126:
  I-D.nennemann-agent-gap-analysis:
    title: "Gap Analysis for Autonomous Agent Protocols"
    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/

--- abstract

This document defines standardized protocols for multiple AI agents to
reach consensus on shared decisions and negotiate capabilities dynamically
during runtime collaboration. As autonomous agent systems increasingly
operate in multi-agent configurations, the need for formal agreement
mechanisms and capability discovery becomes critical. This specification
addresses the lack of consensus protocols and capability negotiation
standards identified in the gap analysis for AI agent infrastructure.

--- middle

# Introduction

When multiple AI agents collaborate on shared tasks such as network
management, resource allocation, or policy enforcement, they must
frequently agree on joint decisions. Currently, no standardized protocol
exists for agents to propose actions, vote on alternatives, reach
quorum, or handle disagreements.

This document addresses Gap 3 (Multi-Agent Consensus) and Gap 10
(Capability Negotiation) from the gap analysis {{I-D.nennemann-agent-gap-analysis}}.
Gap 3 identifies the absence of formal consensus mechanisms for
multi-agent coordination, while Gap 10 highlights the lack of dynamic
capability negotiation during runtime collaboration.

The protocols defined here enable agents to:

- Propose actions and gather votes from participating agents.
- Reach agreement using multiple consensus mechanisms suited to
  different operational contexts.
- Advertise, discover, and negotiate capabilities dynamically.
- Record consensus and negotiation outcomes in verifiable
  evidence chains via the Execution Chain Trace (ECT)
  framework {{I-D.nennemann-wimse-ect}}.

The human-in-the-loop override protocol defined in
{{I-D.nennemann-agent-dag-hitl-safety}} serves as the ultimate
escalation path when consensus cannot be reached or when decisions
exceed agent authority.

# Terminology

{::boilerplate bcp14-tagged}

The following terms are used throughout this document:

Consensus Round:
: A bounded period during which agents exchange proposals and votes
  to reach agreement on a specific decision.

Quorum:
: The minimum number of participating agents required for a consensus
  round to produce a valid outcome.

Proposal:
: A structured message submitted by an agent that describes a
  candidate action or decision for group consideration.

Vote:
: A response to a proposal indicating approval, rejection, or
  abstention, optionally accompanied by a rationale.

Leader Agent:
: An agent designated as the coordinator for a consensus round,
  responsible for collecting votes and declaring outcomes.

Capability Advertisement:
: A structured declaration by an agent of the capabilities it offers
  to other agents in a collaboration.

Capability Offer:
: A message proposing the use of a specific capability under
  defined terms during a negotiation session.

Capability Acceptance:
: A binding confirmation that an agent agrees to the terms of a
  capability offer.

Negotiation Session:
: A bounded interaction between two or more agents for the purpose
  of agreeing on capability usage terms.

# Consensus Protocols

## Consensus Model Overview

The consensus protocol follows a three-phase commit model: propose,
vote, and commit. The following diagram illustrates the message flow
for a typical consensus round.

~~~ ascii-art
  Agent A          Leader           Agent B         Agent C
    |                 |                |                |
    |--- Propose ---->|                |                |
    |                 |-- Vote Req --->|                |
    |                 |-- Vote Req ------------------>  |
    |                 |                |                |
    |                 |<-- Vote -------|                |
    |                 |<-- Vote ----------------------  |
    |                 |                |                |
    |                 |--- Tally & Decide ---------->   |
    |<-- Commit ------|                |                |
    |                 |-- Commit ----->|                |
    |                 |-- Commit ------------------->   |
    |                 |                |                |
~~~
{: #fig-consensus-flow title="Consensus Round Message Flow"}

1. **Propose**: An agent submits a proposal to the leader agent.
2. **Vote**: The leader distributes the proposal to all participants
   and collects votes within the timeout window.
3. **Commit/Abort**: The leader evaluates votes against the quorum
   and consensus mechanism rules, then issues a commit or abort
   signal to all participants.

## Consensus Mechanisms

This specification defines four consensus mechanisms. Implementations
MUST support simple majority voting and SHOULD support at least one
additional mechanism.

### Simple Majority Voting

A proposal is accepted if more than half of the votes received are
approvals. Abstentions do not count toward the total.

- Quorum: A minimum of ceil(N/2) votes must be received, where N
  is the number of eligible voters.
- Ties result in rejection of the proposal.

### Weighted Consensus

Each agent is assigned a weight reflecting its trust score, domain
expertise, or capability level. A proposal is accepted if the sum
of approval weights exceeds a configured threshold (default: 50%
of total weight).

- Weights MUST be distributed and agreed upon before the consensus
  round begins.
- Weight assignments SHOULD be recorded in the ECT for
  auditability.

### Leader-Based Consensus

A designated leader agent makes the final decision after soliciting
input from participants. Participant votes serve as advisory input
rather than binding decisions.

- The leader MUST provide a rationale when overriding participant
  recommendations.
- Leader designation SHOULD rotate or be determined by a
  higher-level policy.
- This mechanism is appropriate for time-critical decisions where
  full consensus would introduce unacceptable delay.

### Optimistic Consensus

A proposal is considered accepted unless an objection is raised
within the timeout window. This mechanism minimizes communication
overhead for routine decisions.

- Any single objection blocks the proposal.
- The objecting agent MUST provide a rationale.
- Optimistic consensus SHOULD only be used for low-risk,
  reversible decisions.

## Consensus Message Format

### Proposal Message Structure

A proposal message MUST contain the following fields:

- **proposal_id**: A globally unique identifier for the proposal
  (UUID format).
- **proposer**: The identity of the proposing agent.
- **consensus_round_id**: Identifier for the consensus round.
- **mechanism**: The consensus mechanism to use (one of "majority",
  "weighted", "leader", "optimistic").
- **subject**: A human-readable summary of the proposal.
- **action**: A structured description of the proposed action.
- **timeout**: The deadline for vote collection (as an absolute
  timestamp per {{RFC9110}} Section 5.6.7).
- **quorum**: The minimum number of votes required.
- **participants**: List of agent identifiers eligible to vote.

### Vote Message Structure

A vote message MUST contain the following fields:

- **proposal_id**: The identifier of the proposal being voted on.
- **voter**: The identity of the voting agent.
- **decision**: One of "approve", "reject", or "abstain".
- **rationale**: A human-readable explanation for the vote
  (REQUIRED for "reject", OPTIONAL for others).
- **timestamp**: The time the vote was cast.
- **signature**: A JWS {{RFC7515}} signature over the vote content
  for non-repudiation.

### Commit and Abort Signals

After vote collection, the leader issues either a commit or abort
signal:

- **Commit**: Indicates the proposal was accepted. All participants
  MUST execute the agreed action.
- **Abort**: Indicates the proposal was rejected. Participants MUST
  NOT execute the proposed action.

Both signals MUST include the proposal_id, the final tally, and a
JWS signature from the leader.

## Quorum and Timeout Rules

### Quorum Calculation

The quorum for a consensus round is determined by the consensus
mechanism in use:

- **Simple majority**: ceil(N/2) where N is the number of
  eligible voters.
- **Weighted**: Agents representing at least 50% of total weight
  must participate.
- **Leader-based**: No quorum required; leader decides
  independently.
- **Optimistic**: All eligible agents are considered participants;
  silence counts as approval.

### Timeout Semantics and Fallback Behavior

Each consensus round MUST specify a timeout. If quorum is not
reached before the timeout:

1. The leader MUST issue an abort signal.
2. The proposing agent MAY re-submit the proposal with a longer
   timeout or reduced quorum.
3. If the decision is time-critical, the leader MAY escalate to
   a human operator via the override protocol defined in
   {{I-D.nennemann-agent-dag-hitl-safety}}.

Implementations SHOULD use exponential backoff for re-submissions
with a maximum retry count of 3.

### Split-Brain Prevention

In distributed deployments where network partitions may occur:

- A consensus round is valid only if the leader can verify
  connectivity to a majority of participants.
- If a partition is detected, all in-progress consensus rounds
  MUST be suspended until connectivity is restored.
- Agents MUST NOT accept commit signals from multiple leaders
  for the same consensus round.

## Conflict Resolution

### Priority-Based Resolution

When multiple competing proposals address the same resource or
decision:

- Proposals are ranked by a priority score derived from the
  urgency of the decision, the authority level of the proposer,
  and the specificity of the proposed action.
- Higher-priority proposals are evaluated first.
- Lower-priority proposals that conflict with an accepted
  higher-priority proposal are automatically rejected.

### Escalation to Human Operator

If consensus cannot be reached after the maximum number of retries,
or if agents are deadlocked:

- The leader MUST escalate to a human operator using the override
  protocol defined in {{I-D.nennemann-agent-dag-hitl-safety}}.
- The escalation message MUST include the proposal, all votes
  received, and the reason for escalation.
- The human operator's decision is binding and MUST be recorded
  in the ECT.

### Deadlock Detection and Breaking

A deadlock exists when:

- Two or more proposals mutually block each other (circular
  dependency).
- A consensus round cannot reach quorum due to persistent
  abstentions or non-responsive agents.

Deadlock breaking strategies:

1. **Timeout-based**: The oldest proposal takes precedence.
2. **Random selection**: A verifiable random function selects
   the winning proposal.
3. **Escalation**: The deadlock is escalated to a human operator.

The leader MUST detect deadlocks within two consecutive failed
consensus rounds on related proposals.

# Capability Negotiation

## Capability Advertisement Format

### Extending Agent Discovery with Capability Descriptors

Agents MUST advertise their capabilities using a structured
descriptor format. Capability advertisements extend the agent
discovery mechanism and SHOULD be published during agent
registration.

A capability descriptor MUST include:

- **agent_id**: The identity of the advertising agent.
- **capabilities**: An array of capability objects, each containing:
  - **type**: The capability type from the capability registry
    (see {{capability-registry}}).
  - **version**: The version of the capability implementation.
  - **parameters**: Capability-specific configuration parameters.
  - **constraints**: Limitations on capability usage (e.g., rate
    limits, maximum payload size).
  - **availability**: Current availability status ("available",
    "busy", "degraded", "unavailable").

### Capability Categories

Capabilities are organized into the following categories:

- **Compute**: Processing power, model inference, data
  transformation.
- **Knowledge**: Domain expertise, access to knowledge bases,
  training data coverage.
- **Tool Access**: Integration with external tools, APIs, or
  services.
- **Authorization Scope**: Permissions and access levels the agent
  holds in various systems.

### Version and Compatibility Metadata

Each capability advertisement MUST include version information
to enable compatibility checking:

- **min_version**: The minimum protocol version supported.
- **max_version**: The maximum protocol version supported.
- **deprecated_versions**: A list of versions that are supported
  but deprecated.

Agents MUST negotiate a mutually supported version before
initiating capability usage.

## Dynamic Negotiation Protocol

### Negotiation Initiation and Session Management

A negotiation session is initiated when an agent requires a
capability that it does not possess but has identified in another
agent's advertisement.

1. The initiating agent sends a **Negotiation Request** specifying
   the desired capability type and parameters.
2. The target agent responds with a **Negotiation Response**
   indicating willingness to negotiate.
3. A **session_id** is established for tracking the negotiation.

Sessions have a configurable timeout (default: 60 seconds) and
MUST be explicitly closed by either party.

### Offer/Counter-Offer Exchange

Once a session is established:

1. The initiating agent sends a **Capability Offer** specifying
   the desired terms of use (duration, rate limits, data handling
   requirements).
2. The target agent may respond with:
   - **Accept**: Agreement to the offered terms.
   - **Counter-Offer**: Modified terms for the initiator to
     consider.
   - **Reject**: Refusal to provide the capability, with a
     rationale.
3. Counter-offers may continue for a maximum of 5 rounds before
   the negotiation MUST be concluded or abandoned.

### Acceptance and Binding

When both parties agree on terms:

- A **Capability Agreement** is created containing the final terms,
  signed by both parties using JWS {{RFC7515}}.
- The agreement includes a unique **agreement_id**, the agreed
  capability parameters, duration, and any usage constraints.
- Both agents MUST honor the agreement until its expiration or
  explicit revocation.

### Re-Negotiation During Runtime

Either party MAY initiate re-negotiation of an active agreement
when:

- Resource availability changes.
- New constraints are imposed by external factors.
- The original terms are no longer adequate.

Re-negotiation follows the same offer/counter-offer protocol but
references the existing agreement_id.

## Capability Registry {#capability-registry}

### Well-Known Capability Types

The following capability types are defined as initial entries in
the capability registry:

| Type ID | Category | Description |
|---|---|---|
| compute.inference | Compute | Model inference execution |
| compute.transform | Compute | Data transformation and processing |
| knowledge.domain | Knowledge | Domain-specific expertise |
| knowledge.retrieval | Knowledge | Information retrieval from knowledge bases |
| tool.api | Tool Access | External API integration |
| tool.execution | Tool Access | Tool or script execution |
| authz.delegate | Authorization | Delegated authorization scope |
| authz.verify | Authorization | Credential and permission verification |
{: #tab-capability-types title="Well-Known Capability Types"}

### Extension Mechanism for Custom Capabilities

Organizations MAY define custom capability types using a reverse
domain name prefix (e.g., "com.example.custom-capability"). Custom
capability types:

- MUST NOT conflict with well-known capability type identifiers.
- SHOULD be registered with IANA for interoperability when intended
  for broad use.
- MUST include a human-readable description and a machine-readable
  schema for parameters.

# ECT Integration

Consensus and capability negotiation events MUST be recorded in the
Execution Chain Trace (ECT) framework defined in
{{I-D.nennemann-wimse-ect}} to provide a verifiable audit trail.

## Consensus Evidence in ECT Nodes

The following exec_act values are defined for consensus operations:

- **consensus_propose**: Records the submission of a proposal.
  The ECT node MUST include the proposal_id, proposer identity,
  and proposal summary.
- **consensus_vote**: Records a vote cast by an agent. The ECT
  node MUST include the proposal_id, voter identity, decision,
  and rationale (if provided).
- **consensus_commit**: Records the outcome of a consensus round.
  The ECT node MUST include the proposal_id, final tally,
  outcome (commit or abort), and the leader's signature.

## Capability Negotiation Records in ECT

Capability negotiation events are recorded using the ECT ext
(extension) claims mechanism:

- The **ext** claim MUST include a "capability_negotiation" object
  containing the session_id, capability type, and negotiation
  outcome.
- Agreement creation and revocation events MUST each produce an
  ECT node with the agreement_id and relevant terms.
- Re-negotiation events MUST reference the original agreement_id
  and include both the previous and updated terms.

# Security Considerations

## Sybil Resistance

To prevent an attacker from creating multiple fake agent identities
to influence consensus outcomes:

- Agents MUST authenticate using verifiable credentials bound to
  their operational identity.
- The leader MUST verify agent identities before accepting votes.
- Consensus mechanisms SHOULD incorporate identity verification
  scores that penalize newly registered or unverified agents.
- Rate limiting on agent registration prevents rapid creation of
  sybil identities.

## Byzantine Fault Tolerance Considerations

The consensus mechanisms defined in this document do not provide
full Byzantine fault tolerance (BFT). Deployments requiring BFT
guarantees SHOULD:

- Use weighted consensus with trust scores that reflect agent
  reliability history.
- Implement cross-validation of votes through independent
  verification channels.
- Set quorum thresholds to at least 2f+1 where f is the maximum
  number of potentially faulty agents.
- Consider established BFT protocols (e.g., PBFT) as an
  alternative consensus mechanism for high-security environments.

## Capability Spoofing

Agents MUST NOT advertise capabilities they do not possess.
Mitigations include:

- Capability advertisements MUST be signed using the agent's
  verified credentials.
- Consumers SHOULD validate capability claims through test
  invocations before relying on them for critical operations.
- Agents that fail to deliver advertised capabilities MUST have
  their trust scores reduced.
- Repeated capability spoofing SHOULD result in exclusion from
  future consensus rounds and negotiation sessions.

## Coercion and Collusion Detection

To detect coordinated manipulation of consensus outcomes:

- Vote patterns SHOULD be analyzed for statistical anomalies
  (e.g., identical rationales, synchronized timing).
- Agents SHOULD be required to submit votes independently without
  knowledge of other agents' votes until the tally is complete
  (sealed-bid voting).
- The ECT audit trail enables post-hoc analysis of voting patterns
  to identify potential collusion.
- Human operators SHOULD be notified when anomalous voting patterns
  are detected.

# IANA Considerations

## Consensus exec_act Values

This document requests registration of the following exec_act
values in the ECT exec_act registry:

| Value | Description | Reference |
|---|---|---|
| consensus_propose | Agent submits a consensus proposal | This document |
| consensus_vote | Agent casts a vote on a proposal | This document |
| consensus_commit | Leader commits or aborts a consensus round | This document |
{: #tab-exec-act title="Consensus exec_act Values"}

## Capability Type Registry

This document requests IANA to create a new "Agent Capability
Types" registry with the following initial entries as defined in
{{tab-capability-types}}.

New entries in this registry require Specification Required
(per {{RFC8126}}) and MUST include:

- A unique type identifier.
- The capability category.
- A human-readable description.
- A reference to the defining specification.

--- back

# Acknowledgments
{:numbered="false"}

The author thanks the contributors to the NMOP working group
discussions on AI agent orchestration and multi-agent coordination
challenges.