Requirements for Agent Session Establishment and Capability Negotiation

Introduction Autonomous agents collaborating across administrative domains require a common understanding of when a session begins, what each side is capable of, and which capabilities are in effect for a given interaction. This document states requirements for session establishment and capability negotiation that follow from these needs. Session establishment is orthogonal to peer location. Two entities may come to know of each other through intent routing, through directory-based discovery, or because one side cached the other's information from a previous session. In all cases, the same session establishment flow applies. This document therefore assumes that the entities already know of each other and does not presuppose any particular locating mechanism. The need for this document follows from gaps stated by adjacent work. The DAWN problem statement explicitly places the exchange that follows discovery outside its scope: "after discovery, an interview-style exchange may be conducted using the communication method indicated by the entity — outside the scope of DAWN" . The DAWN terminology likewise defines capability exchange, negotiation, and selection as out of scope for DAWN . Intent routing addresses how a request reaches an entity, not what happens once it does. Session establishment and capability negotiation, the subject of this document, fall between these efforts.

Scope This document defines requirements for:

the establishment of sessions between entities, and
the negotiation of capabilities within such sessions.

It is assumed that the entities involved already know of each other. How they came to know each other — whether through intent routing, directory-based discovery, information cached from a prior session, or any other mechanism — is outside the scope of this document and does not affect the requirements stated herein. At least one party to a session MUST be an agent as defined in . A session between two deterministic systems, neither of which is an agent, is outside the scope of this document. The following are out of scope:

discovery of entities (covered by DAWN );
routing of intent or requests between entities (covered by );
the transport protocol over which a session is carried; and
any mechanism or protocol design for session establishment.

This document is a requirements document, not a solution document. It deliberately does not specify how the requirements are to be met.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Agent: An autonomous software entity capable of perceiving its environment, making decisions, and acting to achieve goals on behalf of a user or another agent.
Entity: A party to a session. An entity MAY be an agent, a deterministic program such as an MCP server, a human, or a system acting on a human's behalf. The term is consistent with its use in the DAWN work .
Originator: An entity that initiates a session with another entity in order to request an action or obtain a result.
Handler: An entity that may be selected by an originator to perform an action or provide a result.
Capability: A function, service, or behavior that an entity is able to offer.
Capability Card: A structured description of an entity's capabilities, as defined in the DAWN work . A capability card is a container; its content format is not specified by DAWN.
Capability Description Language (CDL): The machine-readable language used in this document to describe the capabilities contained in a capability card. A CDL is a concrete description of a capability card's content. The CDL concept originates from the AIN architecture .
Session: An association established between two entities for the purpose of collaboration, encompassing the negotiated capabilities and the interactions that take place under them.

Requirements

REQ-1: Timing of Capability Negotiation Capability negotiation MUST be completed before the session is considered established. A session MUST NOT be presented as usable for collaboration unless capability negotiation has succeeded. Rationale: An originator cannot meaningfully commit to a session if it does not know whether the handler can satisfy the intended action. Negotiation is a precondition of the session, not a detail of it.

REQ-2: Endpoint Autonomy Capability declaration and negotiation MUST be decided by the entities that hold them. Discovery and routing layers MUST NOT make or substitute for capability decisions on behalf of either entity. Rationale: Capability is a property of the entity. Any party that does not hold the capability cannot truthfully declare it, and any intermediate layer that preselects on capability inserts itself into an autonomy boundary it does not own.

REQ-3: Negotiation over the Direct Connection Once a direct connection between the two entities is established, capability negotiation MUST take place over that connection and MUST NOT traverse any intermediate intent routing or discovery layer. Rationale: Negotiation content is private to the session entities. Routing layers are involved only in getting the entities to each other; once they are connected, the negotiation proceeds directly between them. An implementation in which negotiation traverses an intermediate layer violates this requirement.

REQ-4: Mutual Selection Rights Both entities MUST retain selection rights. The originator selects the handler it wishes to engage, and the handler MAY choose to connect to the originator actively, to respond passively, or to decline. Rationale: Selection is not one-directional. A handler is an autonomous party with its own interests and constraints; its choice of whether and how to engage is part of the negotiation, not an outcome imposed by the originator.

REQ-5: Authorization Boundary Successful session establishment MUST NOT be presented as authorization to execute the requested action. Execution authorization is a separate decision that MUST be made explicitly. Rationale: Routing and session establishment answer "can these entities talk to each other"; they do not answer "may this action be performed". Conflating the two creates a security boundary violation, particularly when a routing layer is involved in getting the entities together.

REQ-6: Session Lifecycle Management Session revocation, transfer of session ownership, and the termination of negotiated capabilities MUST be expressible explicitly by either entity. Rationale: Sessions are not static. A handler may lose a capability, an originator may need to transfer a session to another entity, and either side may revoke. A session model that cannot express these transitions cannot be managed safely.

Security Considerations The security properties of this document follow from REQ-3 and REQ-5. Because negotiation occurs over the direct connection (REQ-3), intermediate layers have no opportunity to observe or tamper with capability content. Because session establishment does not confer execution authority (REQ-5), the blast radius of a compromised routing or discovery layer is limited to connection establishment, not to the actions performed within the session. Entities SHOULD authenticate each other before engaging in capability negotiation. Capability declarations are claims made by the declaring entity and are subject to its own trust and verification policies. Where one entity is a human, execution authorization is ultimately a human decision; session establishment must not be presented to the human as having authorized execution.

IANA Considerations This document has no IANA actions.