The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

2. Introduction

An artificial-intelligence agent operated on behalf of a human principal periodically reaches a point at which it has synthesised a position and must obtain the principal's commitment before acting: whether to release a scoped view of the principal's data to a third party, whether to accept or decline a delegated action, whether to acknowledge a recommendation, whether to proceed with a step that changes external state. This memo names that point a binding moment and specifies the wire-level structure through which a binding moment is delivered and resolved.¶

In current practice the structure of a binding moment is per-tool ad hoc. One agent tool returns a free-text question; another returns a list of options with no synthesis; a third returns a state dump and leaves the principal to perform the synthesis themselves. The consequence is twofold. First, the principal cannot acquire a stable scanning habit, because the shape of the decision changes with every tool. Second, and more seriously, an agent that returns a bare menu of options has pushed the cost of deliberation back onto the principal: the agent has measured but not committed, and the interface has become soft-coercive: the principal must either pick from a frame they did not author or abandon the interaction.¶

This memo specifies a single delivery contract, the briefing-and- binding envelope, that resolves both problems by construction. The envelope has a fixed eight-slot grammar. The first four slots are the briefing: a pre-synthesised, scannable account of what the agent observed and what it concluded. The last four slots are the binding: a quantised decision, a recommended path, and two escape hatches. The envelope is emitted as a structured field of a Model Context Protocol [MCP] tool result, and any consuming surface (a command-line client, a mobile consent sheet, a desktop notifier, an agent-runtime hook) renders the same eight slots into its native user interface. One contract, many renderers.¶

The load-bearing innovation is the dual-veto handshake. A binding moment is consensual only if both parties can refuse it. The agent refuses by declining to emit a binding moment at all when it cannot commit to a position: a binding moment with a hedged synopsis is malformed. The principal refuses through two distinct escape hatches: one revises the answer space (the principal accepts the question but answers on their own terms), the other revises the question space (the principal rejects the question itself and reopens deliberation). Without both hatches the envelope degrades to a forced-choice interface and the briefing slots stop carrying their weight. Section 6 specifies the handshake.¶

This memo specifies a delivery contract and a veto handshake. It does NOT specify a persistent log of binding moments, a signed event history between identifiers, or any derivation of signing authority; those concerns are out of scope and are addressed by separate work. The envelope is a transient payload: it is emitted, rendered, resolved, and the resolution is returned. What an implementation durably records of that exchange, and under what attribution, is a matter for the audit-signal mechanism of [POLICYPROV] and is not constrained here.¶

3. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are defined for the purposes of this document.¶

Principal

The human on whose behalf an agent acts, identified by a Sovereign- tier ~handle as defined by [IDPRONOUNS].¶

Agent

An artificial-intelligence runtime acting for a principal, identified by an Instrument-tier ~handle per [IDPRONOUNS]. The agent is the party that emits a briefing-and-binding envelope.¶

Binding moment

A point in an agent's operation at which it has synthesised a position and requires the principal's commitment, decline, amendment, or rejection before proceeding.¶

Briefing-and-binding envelope

The eight-slot structured payload defined by this memo, emitted by an agent at a binding moment as a field of an MCP tool result.¶

Briefing slots

The first four slots of the envelope (synopsis, findings, recommendations, offer). Pre-synthesised material the principal scans.¶

Binding slots

The last four slots of the envelope (question stem, options, recommended option, escape hatches). The quantised decision the principal resolves.¶

Escape hatch

A binding-slot affordance through which the principal declines the question as posed. Two are defined: the answer-space hatch, which accepts the question and revises the answer; and the question-space hatch, which rejects the question and reopens deliberation.¶

Dual veto

The property that a binding moment may be refused by either party: the agent by withholding a malformed binding moment, the principal by invoking either escape hatch.¶

Consuming surface

A client that receives an MCP tool result carrying a briefing-and- binding envelope and renders the eight slots into a native user interface.¶

Resolution

The principal's response to a binding moment: selection of an option, invocation of the answer-space hatch with an answer, or invocation of the question-space hatch.¶

4. Architecture

The briefing-and-binding envelope is a payload, not a protocol. It is carried by the existing request/response semantics of the Model Context Protocol [MCP] and introduces no new transport, no new handle category, and no new discovery mechanism.¶

The arrangement has three roles and one round trip.¶

The agent reaches a binding moment in the course of operating for its principal. Instead of returning an ad hoc question, it constructs a briefing-and-binding envelope and emits it as a structured field of the MCP tool result.¶

The consuming surface receives the tool result, detects the envelope field, and renders the eight slots into its native interface. The consuming surface performs no synthesis: the briefing slots are rendered as written; the binding slots are rendered as the interactive decision element the surface natively supports.¶

The principal observes the rendered briefing, resolves the binding, and the resolution is returned to the agent as the input to the next tool invocation.¶

The round trip is therefore: agent emits envelope -> surface renders -> principal resolves -> resolution returns to agent. No state is held between trips by the envelope itself. An envelope is valid only for the single resolution it solicits; an agent that requires a further commitment emits a further envelope.¶

This memo specifies the envelope (Section 4), the slot grammar (Section 5), the dual-veto handshake (Section 6), the MCP delivery binding (Section 7), and the renderer contract (Section 8).¶

5. The Briefing-and-Binding Envelope

An agent at a binding moment SHALL emit a briefing-and-binding envelope as a structured field, named binding_moment, of the MCP tool result it returns. The field's value is a JSON [RFC8259] object with exactly the members specified below.¶

{
  "binding_moment": {
    "synopsis":        <string>,
    "findings":        [ <string>, ... ],
    "recommendations": [ <string>, ... ],
    "offer":           <string>,
    "question": {
      "stem":            <string>,
      "options": [
        { "label": <string>, "reasoning": <string> },
        ...
      ],
      "recommended_idx": <integer>,
      "hatches": {
        "free_text": <boolean>,
        "dialogue":  <boolean>
      }
    },
    "meta": {
      "decision_class":   <string>,   ; OPTIONAL
      "calibration_note": <string>    ; OPTIONAL
    }
  }
}

The members synopsis, findings, recommendations, offer, and question are REQUIRED. The member meta is OPTIONAL; when present, both of its members are individually OPTIONAL.¶

A consuming surface that receives a tool result with a binding_moment field that is not a well-formed envelope (a missing REQUIRED member, an out-of-range recommended_idx, an options list with fewer than two entries) SHALL treat the binding moment as malformed. A malformed binding moment SHALL NOT be rendered as a decision; the surface SHOULD instead render the underlying tool result in its fallback non-envelope form (Section 8.2) and SHOULD surface a diagnostic indicating the envelope was discarded.¶

The eight slots referenced throughout this memo are: (1) synopsis, (2) findings, (3) recommendations, (4) offer, (5) question stem, (6) options with per-option reasoning, (7) the recommended option, and (8) the escape hatches. Slots 1 through 4 are the briefing slots; slots 5 through 8 are the binding slots.¶

6. Slot Grammar

This section specifies the content contract for each slot. The contract is partly machine-checkable (cardinality, type) and partly a construction discipline the agent SHALL observe for the envelope to be well-formed in the sense Section 4 requires.¶

7. The Dual-Veto Handshake

The defining property of a binding moment, as opposed to a notification, is that either party may refuse it. This section specifies the handshake.¶

8. MCP Delivery Binding

The briefing-and-binding envelope is delivered as a structured field of a Model Context Protocol [MCP] tool result. This section specifies the binding.¶

9. Renderer Contract

A consuming surface renders the eight slots into its native interface. This section specifies what the rendering SHALL preserve and what it MAY vary.¶

10. Relationship to Companion Memos

This memo composes with the Morrison-family Internet-Drafts as follows.¶

[IDPRONOUNS] supplies the ~handle namespace and the Sovereign / Instrument trust-tier taxonomy. The principal is a Sovereign-tier handle and the agent an Instrument-tier handle; this memo introduces no new handle category.¶

[POLICYPROV] supplies the Model Context Protocol tool surface over an identity substrate from which an agent retrieves policy and to which it emits audit signals. The briefing-and-binding envelope is carried by a tool result on that same surface; a binding moment and its resolution are among the runtime events an implementation MAY record through the audit-signal mechanism that memo specifies. This memo specifies the transient delivery contract; [POLICYPROV] specifies the durable audit channel. The two are deliberately separated: the envelope does not itself persist.¶

[IDCOMMITS] supplies the attribution grammar. Where an implementation records a resolved binding moment, the attribution of that record (the Sovereign-tier handle that resolved it and the Instrument-tier handle that drafted the envelope) follows the trailer grammar of [IDCOMMITS]. This memo does not place attribution slots in the envelope itself; attribution is a property of any durable record, not of the transient payload.¶

[MCPDNS] supplies the discovery mechanism by which a consuming surface locates the MCP server whose tools emit envelopes. This memo introduces no new discovery surface.¶

[SUBSTRATE] supplies the coordination posture for the case in which a principal operates several agent sessions concurrently. A binding moment emitted by one session and a binding moment emitted by another are independent payloads; this memo does not coordinate them, and an implementation that surfaces concurrent binding moments deconflicts them under the substrate-observation posture of that memo rather than through any mechanism specified here.¶

11. IANA Considerations

This memo requests no IANA action.¶

The structured-field name binding_moment (Section 4) and the tool-manifest annotation name emits_binding_moment (Section 7.2) are illustrative of the reference implementation operated by the present author. They are member names within a Model Context Protocol tool result and tool manifest respectively; they are not protocol identifiers requiring registration. A conforming implementation MAY name these fields by any convention consistent with its MCP tool schema. If a future revision of this memo, or a companion specification, proposes a registry for canonical tool-result field names, that revision will request the corresponding IANA action.¶

No new transport, port number, URI scheme, media type, or DNS record type is introduced by this memo.¶

12. Security Considerations

The briefing-and-binding envelope is a delivery contract for decisions a principal makes about an agent's behaviour. Its security considerations concern the integrity of the decision, not the confidentiality of a stored record; the envelope holds no durable state.¶

13. Privacy Considerations

The briefing-and-binding envelope is a transient payload. It is emitted, rendered, resolved, and discarded; this memo specifies no durable store of envelopes and no log of resolutions. An implementation that does record resolved binding moments does so through the audit-signal mechanism of [POLICYPROV], and the privacy considerations of that mechanism (significance-predicate scope, argument redaction) apply to such records. This memo adds two considerations specific to the envelope.¶

First, the briefing slots may contain, in the agent's findings, an account of observations the agent has made about the principal or about third parties. An agent SHOULD construct the findings slot to the minimum needed for the principal to validate the decision, and SHOULD NOT use the findings slot as an incidental disclosure channel for material unrelated to the binding moment at hand.¶

Second, the principal's resolution, including a free-form answer submitted through the answer-space hatch, is principal- authored content returned to the agent. An implementation SHALL treat an answer-space response with the same care as any other principal input and SHALL NOT persist it beyond what the audit-signal significance predicate of [POLICYPROV] requires.¶

14. Implementation Status

This section records implementation experience in the spirit of [RFC7942] and is expected to be removed before the document advances beyond the Independent Stream.¶

A reference implementation of the briefing-and-binding envelope is operated by the present author against a production Model Context Protocol substrate. An agent tool that surfaces the next question of a conversational identity-discovery flow emits the envelope as an additive binding_moment field of its tool result, behind a feature flag, alongside the tool's conventional payload. The envelope's eight slots are populated as specified in Section 5: the synopsis and findings report the state of the discovery flow, the recommended option is selected by an information-gain heuristic over the available answers, and the escape hatches are set per Section 5.8 with the question-space hatch open. A second tool that records a submitted discovery answer emits a follow-on envelope soliciting whether to continue. Consuming surfaces render the envelope to a plain-text multiple-choice block with a visibly marked recommended option and both escape hatches.¶

No claim of interoperability is made; the reference deployment is a single substrate operated by the specification's author.¶

15. Document History

draft-morrison-binding-moment-envelope-00 (May 2026):¶

• Initial submission.¶

• Specifies the eight-slot briefing-and-binding envelope (Section 4): synopsis, findings, recommendations, offer, question stem, options with per-option reasoning, recommended option, and dual escape hatches.¶

• Specifies the per-slot grammar and construction discipline (Section 5), including the no-hedge rule on the synopsis and the leading-stem prohibition.¶

• Specifies the dual-veto handshake (Section 6): the agent-side veto by withheld emission and the two principal-side escape hatches refusing the answer space and the question space respectively.¶

• Specifies the MCP delivery binding (Section 7): additive binding_moment field, tool-manifest advertisement, staged adoption, single-surface delivery.¶

• Specifies the renderer contract (Section 8): rendering invariants, permitted native variation, and fallback rendering.¶

16. References

Acknowledgements

This memo grew out of internal design work on the structure of agent- to-principal decision moments and the recognition that a binding moment is consensual only when both parties are able to veto it: the agent by declining to pose a question it cannot commit to, and the principal by two distinct refusals. The articulation of the dual-veto handshake as the load-bearing element of the delivery contract is the insight behind this specification.¶

Author's Address