<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-consensus-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Consensus">Multi-Agent Consensus and Capability Negotiation Protocols</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    

    <abstract>


<?line 35?>

<t>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.</t>



    </abstract>



  </front>

  <middle>


<?line 45?>

<section anchor="introduction"><name>Introduction</name>

<t>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.</t>

<t>This document addresses Gap 3 (Multi-Agent Consensus) and Gap 10
(Capability Negotiation) from the gap analysis <xref target="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.</t>

<t>The protocols defined here enable agents to:</t>

<t><list style="symbols">
  <t>Propose actions and gather votes from participating agents.</t>
  <t>Reach agreement using multiple consensus mechanisms suited to
different operational contexts.</t>
  <t>Advertise, discover, and negotiate capabilities dynamically.</t>
  <t>Record consensus and negotiation outcomes in verifiable
evidence chains via the Execution Chain Trace (ECT)
framework <xref target="I-D.nennemann-wimse-ect"/>.</t>
</list></t>

<t>The human-in-the-loop override protocol defined in
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> serves as the ultimate
escalation path when consensus cannot be reached or when decisions
exceed agent authority.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<t>The following terms are used throughout this document:</t>

<dl>
  <dt>Consensus Round:</dt>
  <dd>
    <t>A bounded period during which agents exchange proposals and votes
to reach agreement on a specific decision.</t>
  </dd>
  <dt>Quorum:</dt>
  <dd>
    <t>The minimum number of participating agents required for a consensus
round to produce a valid outcome.</t>
  </dd>
  <dt>Proposal:</dt>
  <dd>
    <t>A structured message submitted by an agent that describes a
candidate action or decision for group consideration.</t>
  </dd>
  <dt>Vote:</dt>
  <dd>
    <t>A response to a proposal indicating approval, rejection, or
abstention, optionally accompanied by a rationale.</t>
  </dd>
  <dt>Leader Agent:</dt>
  <dd>
    <t>An agent designated as the coordinator for a consensus round,
responsible for collecting votes and declaring outcomes.</t>
  </dd>
  <dt>Capability Advertisement:</dt>
  <dd>
    <t>A structured declaration by an agent of the capabilities it offers
to other agents in a collaboration.</t>
  </dd>
  <dt>Capability Offer:</dt>
  <dd>
    <t>A message proposing the use of a specific capability under
defined terms during a negotiation session.</t>
  </dd>
  <dt>Capability Acceptance:</dt>
  <dd>
    <t>A binding confirmation that an agent agrees to the terms of a
capability offer.</t>
  </dd>
  <dt>Negotiation Session:</dt>
  <dd>
    <t>A bounded interaction between two or more agents for the purpose
of agreeing on capability usage terms.</t>
  </dd>
</dl>

</section>
<section anchor="consensus-protocols"><name>Consensus Protocols</name>

<section anchor="consensus-model-overview"><name>Consensus Model Overview</name>

<t>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.</t>

<figure title="Consensus Round Message Flow" anchor="fig-consensus-flow"><artwork type="ascii-art"><![CDATA[
  Agent A          Leader           Agent B         Agent C
    |                 |                |                |
    |--- Propose ---->|                |                |
    |                 |-- Vote Req --->|                |
    |                 |-- Vote Req ------------------>  |
    |                 |                |                |
    |                 |<-- Vote -------|                |
    |                 |<-- Vote ----------------------  |
    |                 |                |                |
    |                 |--- Tally & Decide ---------->   |
    |<-- Commit ------|                |                |
    |                 |-- Commit ----->|                |
    |                 |-- Commit ------------------->   |
    |                 |                |                |
]]></artwork></figure>

<t><list style="numbers" type="1">
  <t><strong>Propose</strong>: An agent submits a proposal to the leader agent.</t>
  <t><strong>Vote</strong>: The leader distributes the proposal to all participants
and collects votes within the timeout window.</t>
  <t><strong>Commit/Abort</strong>: The leader evaluates votes against the quorum
and consensus mechanism rules, then issues a commit or abort
signal to all participants.</t>
</list></t>

</section>
<section anchor="consensus-mechanisms"><name>Consensus Mechanisms</name>

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

<section anchor="simple-majority-voting"><name>Simple Majority Voting</name>

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

<t><list style="symbols">
  <t>Quorum: A minimum of ceil(N/2) votes must be received, where N
is the number of eligible voters.</t>
  <t>Ties result in rejection of the proposal.</t>
</list></t>

</section>
<section anchor="weighted-consensus"><name>Weighted Consensus</name>

<t>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).</t>

<t><list style="symbols">
  <t>Weights <bcp14>MUST</bcp14> be distributed and agreed upon before the consensus
round begins.</t>
  <t>Weight assignments <bcp14>SHOULD</bcp14> be recorded in the ECT for
auditability.</t>
</list></t>

</section>
<section anchor="leader-based-consensus"><name>Leader-Based Consensus</name>

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

<t><list style="symbols">
  <t>The leader <bcp14>MUST</bcp14> provide a rationale when overriding participant
recommendations.</t>
  <t>Leader designation <bcp14>SHOULD</bcp14> rotate or be determined by a
higher-level policy.</t>
  <t>This mechanism is appropriate for time-critical decisions where
full consensus would introduce unacceptable delay.</t>
</list></t>

</section>
<section anchor="optimistic-consensus"><name>Optimistic Consensus</name>

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

<t><list style="symbols">
  <t>Any single objection blocks the proposal.</t>
  <t>The objecting agent <bcp14>MUST</bcp14> provide a rationale.</t>
  <t>Optimistic consensus <bcp14>SHOULD</bcp14> only be used for low-risk,
reversible decisions.</t>
</list></t>

</section>
</section>
<section anchor="consensus-message-format"><name>Consensus Message Format</name>

<section anchor="proposal-message-structure"><name>Proposal Message Structure</name>

<t>A proposal message <bcp14>MUST</bcp14> contain the following fields:</t>

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

</section>
<section anchor="vote-message-structure"><name>Vote Message Structure</name>

<t>A vote message <bcp14>MUST</bcp14> contain the following fields:</t>

<t><list style="symbols">
  <t><strong>proposal_id</strong>: The identifier of the proposal being voted on.</t>
  <t><strong>voter</strong>: The identity of the voting agent.</t>
  <t><strong>decision</strong>: One of "approve", "reject", or "abstain".</t>
  <t><strong>rationale</strong>: A human-readable explanation for the vote
(<bcp14>REQUIRED</bcp14> for "reject", <bcp14>OPTIONAL</bcp14> for others).</t>
  <t><strong>timestamp</strong>: The time the vote was cast.</t>
  <t><strong>signature</strong>: A JWS <xref target="RFC7515"/> signature over the vote content
for non-repudiation.</t>
</list></t>

</section>
<section anchor="commit-and-abort-signals"><name>Commit and Abort Signals</name>

<t>After vote collection, the leader issues either a commit or abort
signal:</t>

<t><list style="symbols">
  <t><strong>Commit</strong>: Indicates the proposal was accepted. All participants
<bcp14>MUST</bcp14> execute the agreed action.</t>
  <t><strong>Abort</strong>: Indicates the proposal was rejected. Participants <bcp14>MUST
NOT</bcp14> execute the proposed action.</t>
</list></t>

<t>Both signals <bcp14>MUST</bcp14> include the proposal_id, the final tally, and a
JWS signature from the leader.</t>

</section>
</section>
<section anchor="quorum-and-timeout-rules"><name>Quorum and Timeout Rules</name>

<section anchor="quorum-calculation"><name>Quorum Calculation</name>

<t>The quorum for a consensus round is determined by the consensus
mechanism in use:</t>

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

</section>
<section anchor="timeout-semantics-and-fallback-behavior"><name>Timeout Semantics and Fallback Behavior</name>

<t>Each consensus round <bcp14>MUST</bcp14> specify a timeout. If quorum is not
reached before the timeout:</t>

<t><list style="numbers" type="1">
  <t>The leader <bcp14>MUST</bcp14> issue an abort signal.</t>
  <t>The proposing agent <bcp14>MAY</bcp14> re-submit the proposal with a longer
timeout or reduced quorum.</t>
  <t>If the decision is time-critical, the leader <bcp14>MAY</bcp14> escalate to
a human operator via the override protocol defined in
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
</list></t>

<t>Implementations <bcp14>SHOULD</bcp14> use exponential backoff for re-submissions
with a maximum retry count of 3.</t>

</section>
<section anchor="split-brain-prevention"><name>Split-Brain Prevention</name>

<t>In distributed deployments where network partitions may occur:</t>

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

</section>
</section>
<section anchor="conflict-resolution"><name>Conflict Resolution</name>

<section anchor="priority-based-resolution"><name>Priority-Based Resolution</name>

<t>When multiple competing proposals address the same resource or
decision:</t>

<t><list style="symbols">
  <t>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.</t>
  <t>Higher-priority proposals are evaluated first.</t>
  <t>Lower-priority proposals that conflict with an accepted
higher-priority proposal are automatically rejected.</t>
</list></t>

</section>
<section anchor="escalation-to-human-operator"><name>Escalation to Human Operator</name>

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

<t><list style="symbols">
  <t>The leader <bcp14>MUST</bcp14> escalate to a human operator using the override
protocol defined in <xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
  <t>The escalation message <bcp14>MUST</bcp14> include the proposal, all votes
received, and the reason for escalation.</t>
  <t>The human operator's decision is binding and <bcp14>MUST</bcp14> be recorded
in the ECT.</t>
</list></t>

</section>
<section anchor="deadlock-detection-and-breaking"><name>Deadlock Detection and Breaking</name>

<t>A deadlock exists when:</t>

<t><list style="symbols">
  <t>Two or more proposals mutually block each other (circular
dependency).</t>
  <t>A consensus round cannot reach quorum due to persistent
abstentions or non-responsive agents.</t>
</list></t>

<t>Deadlock breaking strategies:</t>

<t><list style="numbers" type="1">
  <t><strong>Timeout-based</strong>: The oldest proposal takes precedence.</t>
  <t><strong>Random selection</strong>: A verifiable random function selects
the winning proposal.</t>
  <t><strong>Escalation</strong>: The deadlock is escalated to a human operator.</t>
</list></t>

<t>The leader <bcp14>MUST</bcp14> detect deadlocks within two consecutive failed
consensus rounds on related proposals.</t>

</section>
</section>
</section>
<section anchor="capability-negotiation"><name>Capability Negotiation</name>

<section anchor="capability-advertisement-format"><name>Capability Advertisement Format</name>

<section anchor="extending-agent-discovery-with-capability-descriptors"><name>Extending Agent Discovery with Capability Descriptors</name>

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

<t>A capability descriptor <bcp14>MUST</bcp14> include:</t>

<t><list style="symbols">
  <t><strong>agent_id</strong>: The identity of the advertising agent.</t>
  <t><strong>capabilities</strong>: An array of capability objects, each containing:
  <list style="symbols">
      <t><strong>type</strong>: The capability type from the capability registry
(see <xref target="capability-registry"/>).</t>
      <t><strong>version</strong>: The version of the capability implementation.</t>
      <t><strong>parameters</strong>: Capability-specific configuration parameters.</t>
      <t><strong>constraints</strong>: Limitations on capability usage (e.g., rate
limits, maximum payload size).</t>
      <t><strong>availability</strong>: Current availability status ("available",
"busy", "degraded", "unavailable").</t>
    </list></t>
</list></t>

</section>
<section anchor="capability-categories"><name>Capability Categories</name>

<t>Capabilities are organized into the following categories:</t>

<t><list style="symbols">
  <t><strong>Compute</strong>: Processing power, model inference, data
transformation.</t>
  <t><strong>Knowledge</strong>: Domain expertise, access to knowledge bases,
training data coverage.</t>
  <t><strong>Tool Access</strong>: Integration with external tools, APIs, or
services.</t>
  <t><strong>Authorization Scope</strong>: Permissions and access levels the agent
holds in various systems.</t>
</list></t>

</section>
<section anchor="version-and-compatibility-metadata"><name>Version and Compatibility Metadata</name>

<t>Each capability advertisement <bcp14>MUST</bcp14> include version information
to enable compatibility checking:</t>

<t><list style="symbols">
  <t><strong>min_version</strong>: The minimum protocol version supported.</t>
  <t><strong>max_version</strong>: The maximum protocol version supported.</t>
  <t><strong>deprecated_versions</strong>: A list of versions that are supported
but deprecated.</t>
</list></t>

<t>Agents <bcp14>MUST</bcp14> negotiate a mutually supported version before
initiating capability usage.</t>

</section>
</section>
<section anchor="dynamic-negotiation-protocol"><name>Dynamic Negotiation Protocol</name>

<section anchor="negotiation-initiation-and-session-management"><name>Negotiation Initiation and Session Management</name>

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

<t><list style="numbers" type="1">
  <t>The initiating agent sends a <strong>Negotiation Request</strong> specifying
the desired capability type and parameters.</t>
  <t>The target agent responds with a <strong>Negotiation Response</strong>
indicating willingness to negotiate.</t>
  <t>A <strong>session_id</strong> is established for tracking the negotiation.</t>
</list></t>

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

</section>
<section anchor="offercounter-offer-exchange"><name>Offer/Counter-Offer Exchange</name>

<t>Once a session is established:</t>

<t><list style="numbers" type="1">
  <t>The initiating agent sends a <strong>Capability Offer</strong> specifying
the desired terms of use (duration, rate limits, data handling
requirements).</t>
  <t>The target agent may respond with:
  <list style="symbols">
      <t><strong>Accept</strong>: Agreement to the offered terms.</t>
      <t><strong>Counter-Offer</strong>: Modified terms for the initiator to
consider.</t>
      <t><strong>Reject</strong>: Refusal to provide the capability, with a
rationale.</t>
    </list></t>
  <t>Counter-offers may continue for a maximum of 5 rounds before
the negotiation <bcp14>MUST</bcp14> be concluded or abandoned.</t>
</list></t>

</section>
<section anchor="acceptance-and-binding"><name>Acceptance and Binding</name>

<t>When both parties agree on terms:</t>

<t><list style="symbols">
  <t>A <strong>Capability Agreement</strong> is created containing the final terms,
signed by both parties using JWS <xref target="RFC7515"/>.</t>
  <t>The agreement includes a unique <strong>agreement_id</strong>, the agreed
capability parameters, duration, and any usage constraints.</t>
  <t>Both agents <bcp14>MUST</bcp14> honor the agreement until its expiration or
explicit revocation.</t>
</list></t>

</section>
<section anchor="re-negotiation-during-runtime"><name>Re-Negotiation During Runtime</name>

<t>Either party <bcp14>MAY</bcp14> initiate re-negotiation of an active agreement
when:</t>

<t><list style="symbols">
  <t>Resource availability changes.</t>
  <t>New constraints are imposed by external factors.</t>
  <t>The original terms are no longer adequate.</t>
</list></t>

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

</section>
</section>
<section anchor="capability-registry"><name>Capability Registry</name>

<section anchor="well-known-capability-types"><name>Well-Known Capability Types</name>

<t>The following capability types are defined as initial entries in
the capability registry:</t>

<texttable title="Well-Known Capability Types" anchor="tab-capability-types">
      <ttcol align='left'>Type ID</ttcol>
      <ttcol align='left'>Category</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>compute.inference</c>
      <c>Compute</c>
      <c>Model inference execution</c>
      <c>compute.transform</c>
      <c>Compute</c>
      <c>Data transformation and processing</c>
      <c>knowledge.domain</c>
      <c>Knowledge</c>
      <c>Domain-specific expertise</c>
      <c>knowledge.retrieval</c>
      <c>Knowledge</c>
      <c>Information retrieval from knowledge bases</c>
      <c>tool.api</c>
      <c>Tool Access</c>
      <c>External API integration</c>
      <c>tool.execution</c>
      <c>Tool Access</c>
      <c>Tool or script execution</c>
      <c>authz.delegate</c>
      <c>Authorization</c>
      <c>Delegated authorization scope</c>
      <c>authz.verify</c>
      <c>Authorization</c>
      <c>Credential and permission verification</c>
</texttable>

</section>
<section anchor="extension-mechanism-for-custom-capabilities"><name>Extension Mechanism for Custom Capabilities</name>

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

<t><list style="symbols">
  <t><bcp14>MUST NOT</bcp14> conflict with well-known capability type identifiers.</t>
  <t><bcp14>SHOULD</bcp14> be registered with IANA for interoperability when intended
for broad use.</t>
  <t><bcp14>MUST</bcp14> include a human-readable description and a machine-readable
schema for parameters.</t>
</list></t>

</section>
</section>
</section>
<section anchor="ect-integration"><name>ECT Integration</name>

<t>Consensus and capability negotiation events <bcp14>MUST</bcp14> be recorded in the
Execution Chain Trace (ECT) framework defined in
<xref target="I-D.nennemann-wimse-ect"/> to provide a verifiable audit trail.</t>

<section anchor="consensus-evidence-in-ect-nodes"><name>Consensus Evidence in ECT Nodes</name>

<t>The following exec_act values are defined for consensus operations:</t>

<t><list style="symbols">
  <t><strong>consensus_propose</strong>: Records the submission of a proposal.
The ECT node <bcp14>MUST</bcp14> include the proposal_id, proposer identity,
and proposal summary.</t>
  <t><strong>consensus_vote</strong>: Records a vote cast by an agent. The ECT
node <bcp14>MUST</bcp14> include the proposal_id, voter identity, decision,
and rationale (if provided).</t>
  <t><strong>consensus_commit</strong>: Records the outcome of a consensus round.
The ECT node <bcp14>MUST</bcp14> include the proposal_id, final tally,
outcome (commit or abort), and the leader's signature.</t>
</list></t>

</section>
<section anchor="capability-negotiation-records-in-ect"><name>Capability Negotiation Records in ECT</name>

<t>Capability negotiation events are recorded using the ECT ext
(extension) claims mechanism:</t>

<t><list style="symbols">
  <t>The <strong>ext</strong> claim <bcp14>MUST</bcp14> include a "capability_negotiation" object
containing the session_id, capability type, and negotiation
outcome.</t>
  <t>Agreement creation and revocation events <bcp14>MUST</bcp14> each produce an
ECT node with the agreement_id and relevant terms.</t>
  <t>Re-negotiation events <bcp14>MUST</bcp14> reference the original agreement_id
and include both the previous and updated terms.</t>
</list></t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="sybil-resistance"><name>Sybil Resistance</name>

<t>To prevent an attacker from creating multiple fake agent identities
to influence consensus outcomes:</t>

<t><list style="symbols">
  <t>Agents <bcp14>MUST</bcp14> authenticate using verifiable credentials bound to
their operational identity.</t>
  <t>The leader <bcp14>MUST</bcp14> verify agent identities before accepting votes.</t>
  <t>Consensus mechanisms <bcp14>SHOULD</bcp14> incorporate identity verification
scores that penalize newly registered or unverified agents.</t>
  <t>Rate limiting on agent registration prevents rapid creation of
sybil identities.</t>
</list></t>

</section>
<section anchor="byzantine-fault-tolerance-considerations"><name>Byzantine Fault Tolerance Considerations</name>

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

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

</section>
<section anchor="capability-spoofing"><name>Capability Spoofing</name>

<t>Agents <bcp14>MUST NOT</bcp14> advertise capabilities they do not possess.
Mitigations include:</t>

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

</section>
<section anchor="coercion-and-collusion-detection"><name>Coercion and Collusion Detection</name>

<t>To detect coordinated manipulation of consensus outcomes:</t>

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

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="consensus-execact-values"><name>Consensus exec_act Values</name>

<t>This document requests registration of the following exec_act
values in the ECT exec_act registry:</t>

<texttable title="Consensus exec_act Values" anchor="tab-exec-act">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>consensus_propose</c>
      <c>Agent submits a consensus proposal</c>
      <c>This document</c>
      <c>consensus_vote</c>
      <c>Agent casts a vote on a proposal</c>
      <c>This document</c>
      <c>consensus_commit</c>
      <c>Leader commits or aborts a consensus round</c>
      <c>This document</c>
</texttable>

</section>
<section anchor="capability-type-registry"><name>Capability Type Registry</name>

<t>This document requests IANA to create a new "Agent Capability
Types" registry with the following initial entries as defined in
<xref target="tab-capability-types"/>.</t>

<t>New entries in this registry require Specification Required
(per <xref target="RFC8126"/>) and <bcp14>MUST</bcp14> include:</t>

<t><list style="symbols">
  <t>A unique type identifier.</t>
  <t>The capability category.</t>
  <t>A human-readable description.</t>
  <t>A reference to the defining specification.</t>
</list></t>

</section>
</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7515">
  <front>
    <title>JSON Web Signature (JWS)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7515"/>
  <seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
  <front>
    <title>Agent Context Policy Token: DAG Delegation with Human Override</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC8126">
  <front>
    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
    <author fullname="M. Cotton" initials="M." surname="Cotton"/>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <author fullname="T. Narten" initials="T." surname="Narten"/>
    <date month="June" year="2017"/>
    <abstract>
      <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
      <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
      <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="26"/>
  <seriesInfo name="RFC" value="8126"/>
  <seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>

<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
  <front>
    <title>Gap Analysis for Autonomous Agent Protocols</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

</references>


<?line 608?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

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

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 10431 characters]
A6bi/y8mbyizFlUAAA==

-->

</rfc>

