Protocol positioning

ASP occupies a specific position in the agent protocol stack: the session and presentation layers (OSI Layers 5-6) between application protocols like MCP and A2A above, and transport protocols like npayload below. This page explains that positioning in detail, compares ASP to both modern and historical protocols, and shows how they work together.

OSI layer positioning

ASP is designed to fill the session and presentation layers of the OSI model. This is a deliberate architectural choice. Layer 7 protocols define what agents do. Layer 1-4 protocols define how messages move. ASP defines how agents conduct structured conversations in between.

Understanding the layer split

ASP spans two OSI layers because agent sessions require both session management and data representation:

• Layer 5 (Session) handles the conversation structure: opening and closing sessions, managing phases, enforcing turn-taking, tracking which performative is valid at which point in the lifecycle.
• Layer 6 (Presentation) handles data representation: trust score computation, context object serialization, SHA-256 hash chain construction, and Ed25519 signature verification.

These two concerns are tightly coupled in practice. A trust score (Layer 6) determines which session transitions (Layer 5) are permitted. A hash chain (Layer 6) ensures message integrity across session phases (Layer 5). Splitting them into separate protocols would create unnecessary complexity.

Protocol comparison

The following table compares ASP with both modern agent protocols and historical predecessors across seven dimensions.

When to use which

The protocols are complementary, not competing. Each answers a different question about agent interaction.

Understanding protocol boundaries

A common question is where one protocol ends and another begins. The boundaries are clean:

• MCP operates within a single request-response cycle. "Call this tool with these parameters, return the result." There is no concept of a preceding negotiation or a subsequent trust update.
• A2A operates within a task lifecycle. "Here is a task. Work on it. Tell me when it is done." There is no concept of terms, penalties, or dispute resolution.
• ASP operates across the full conversation. "Let us establish a session, negotiate terms, form commitments, execute, verify, learn, and close." MCP calls and A2A tasks happen inside this container.

Complementary usage: procurement example

In practice, all three protocols work together. Here is a detailed example of a procurement negotiation between a purchasing agent and three supplier agents.

{
  "performative": "INFORM",
  "phase": "DISCOVERY",
  "context": {
    "sessionType": "competitive-bid",
    "itemCategory": "industrial-sensors",
    "quantity": 5000,
    "deliveryRegion": "EU-West"
  }
}

{
  "performative": "OBSERVE",
  "phase": "TRUST_ASSESSMENT",
  "trustScores": {
    "supplierA": { "composite": 0.89, "reliability": 0.92, "latency": 0.87 },
    "supplierB": { "composite": 0.76, "reliability": 0.78, "latency": 0.81 },
    "supplierC": { "composite": 0.82, "reliability": 0.95, "latency": 0.61 }
  }
}

{
  "performative": "COMMIT",
  "phase": "COMMITMENT",
  "terms": {
    "quantity": 5000,
    "unitPrice": 9.25,
    "deliveryDays": 7,
    "penaltyRate": 0.01,
    "escrow": 500
  },
  "commitmentId": "asc_k7m9x2p4"
}

Comparison with historical protocols

ASP draws from four traditions in protocol design. Understanding these predecessors clarifies why ASP makes the choices it does.

Understanding FIPA ACL

The Foundation for Intelligent Physical Agents published an Agent Communication Language (FIPA ACL, IEEE 2002) based on speech act theory. FIPA's performatives (INFORM, REQUEST, PROPOSE, ACCEPT-PROPOSAL) directly influenced ASP's thirteen performatives.

ASP differs from FIPA ACL in three significant ways:

Understanding SIP (RFC 3261)

SIP pioneered session lifecycle management for real-time communication. Its dialog model (INVITE, ACK, BYE, session timers) directly influenced ASP's eight-phase lifecycle. Both protocols treat sessions as first-class objects with explicit setup, maintenance, and teardown.

ASP extends SIP's model with negotiation semantics, trust scoring, and commitment tracking that real-time voice and video calls do not require. SIP sessions last minutes. ASP sessions may last hours, days, or weeks.

Understanding OAuth 2.0 and DPoP (RFC 9449)

OAuth 2.0 and DPoP established patterns for identity binding and cryptographic proof-of-possession. ASP applies these patterns to agent identity within sessions: session participants are cryptographically bound to their messages via Ed25519 signatures, preventing impersonation and message replay.

The key insight from DPoP is that possession of a token is insufficient proof of identity. The proof must be bound to the specific request. ASP applies this principle at the session level: each message is signed, and each signature is bound to the session context and hash chain.

Understanding economic game theory

ASP's commitment model draws from mechanism design theory: the study of designing rules so that rational agents behave in desirable ways. Binding commitments with penalties, escrow mechanisms, and dispute resolution create credible consequences for defection, making cooperation the rational strategy.

Without economic mechanisms, agent cooperation relies on good faith. With them, cooperation becomes the equilibrium outcome regardless of whether agents are "well-behaved" by design.

Conformance levels

Not every implementation needs every feature. ASP defines three conformance levels:

Next steps