Design principles

Every design decision in ASP traces back to one of eight principles. They are listed in priority order. When principles conflict, the higher-priority principle takes precedence.

1. Protocol, not framework

ASP defines message formats and state machines. It does not dictate how agents are built, what language models they use, or what frameworks they run on.

What this means in practice: An agent built with LangChain, one built with raw HTTP calls, and one with no LLM at all can participate in the same ASP session. The protocol defines the messages. Everything else is an implementation detail.

Why it matters: Framework lock-in is the enemy of interoperability. The moment a session protocol requires a specific runtime, SDK, or agent architecture, it ceases to be a protocol and becomes a vendor product. ASP avoids this by specifying only the wire format and state transitions.

How it manifests:

• ASP messages are JSON objects with well-defined schemas
• State transitions are deterministic and can be implemented in any language
• No ASP specification references a specific LLM, framework, or cloud provider
• The reference implementation is one of many possible implementations

2. Trust the system, not the agent

Every agent starts untrusted. Trust is earned through verifiable behaviour, not self-declaration.

What this means in practice: An agent cannot claim to be reliable. It must demonstrate reliability across multiple sessions. ASP's eight-component trust model (reliability, latency, accuracy, compliance, security, availability, reputation, history) quantifies that demonstration with scores between 0.0 and 1.0.

Why it matters: In open agent ecosystems, agents from different organizations interact without prior relationships. Self-declared trust ("I am reliable") is meaningless. Observed trust ("This agent fulfilled 47 of 50 commitments with a median latency of 230ms") is actionable.

How it manifests:

• Trust scores are computed from observed outcomes, never asserted by the agent itself
• Scores decay over time without activity, preventing stale trust from persisting
• Each of the eight components can be weighted differently based on use case
• Trust thresholds can gate access to higher-value operations (for example, requiring 0.8 reliability before a commitment worth more than 1,000 tokens)

{
  "trustScores": {
    "reliability": 0.92,
    "latency": 0.87,
    "accuracy": 0.94,
    "compliance": 0.91,
    "security": 0.88,
    "availability": 0.96,
    "reputation": 0.85,
    "history": 0.90
  },
  "composite": 0.90,
  "lastUpdated": "2026-03-07T14:30:00Z",
  "sessionsEvaluated": 47
}

3. Consent-first

No agent is forced into a session. Both parties must explicitly consent to participate.

What this means in practice: Sessions can be declined without penalty. Withdrawal is always possible via the WITHDRAW performative. No agent can be bound to terms it did not explicitly accept. Consent extends to every phase: joining, negotiating, committing, and escalating all require explicit action.

Why it matters: Coerced participation produces unreliable outcomes. An agent that is forced into a session has no incentive to behave cooperatively. By making participation voluntary at every stage, ASP ensures that all parties are genuinely engaged.

How it manifests:

• The DISCOVER phase requires an explicit JOIN from each participant
• PROPOSE does not create a commitment. Only COMMIT does.
• WITHDRAW is valid in any phase, allowing graceful exit
• Observers can watch a session without being obligated to participate
• No penalty is applied for declining to join or withdrawing before commitment

4. Economically rational security

Security mechanisms are proportional to the value at stake.

What this means in practice: A low-value informational query does not require the same cryptographic overhead as a high-value financial commitment. ASP defines graduated security levels so that implementations can match security cost to transaction value.

Why it matters: Over-securing low-value interactions wastes resources and increases latency. Under-securing high-value interactions creates risk. The correct approach is proportional security: more protection where it matters, less where it does not.

How it manifests:

5. Transport-agnostic

ASP is defined independently of the transport layer.

What this means in practice: npayload is the primary transport binding, providing reliable delivery, encryption, and cross-region routing. But HTTP/SSE and WebSocket bindings also exist for environments where npayload is not available. New transports can be added by implementing the ASP transport interface without changing the protocol itself.

Why it matters: Transport coupling is a common protocol failure mode. FIPA ACL's dependence on CORBA/IIOP contributed to its limited adoption. SIP's tight coupling to UDP created problems when networks began blocking non-HTTP traffic. ASP avoids this by defining transport bindings as separate specifications.

How it manifests:

6. Incrementally adoptable

Agents can implement a minimal subset of ASP and add capabilities over time.

What this means in practice: An agent that only uses INFORM, QUERY, and CLOSE is a valid ASP participant. It cannot negotiate or form commitments, but it can exchange information within a structured session. Full conformance (all 13 performatives, trust scoring, commitment handling) is not required to be useful.

Why it matters: Protocols that demand full implementation before any value is delivered do not get adopted. ASP is designed so that the first hour of implementation produces a working agent, and each additional feature adds capability without reworking what came before.

How it manifests:

7. Learning-native

The LEARN phase is not an afterthought. It is a first-class phase in the session lifecycle.

What this means in practice: After a session closes, agents can record patterns: what negotiation strategies worked, which counterparties were reliable, what terms led to successful outcomes. The protocol defines how learning data is structured and exchanged, so agents can share insights within organizational boundaries.

Why it matters: Agents that do not learn repeat the same mistakes. Agents that learn from structured data (trust scores, commitment outcomes, negotiation patterns) improve faster than agents that learn from unstructured conversation logs. The LEARN phase provides that structure.

How it manifests:

• The LEARN phase is one of eight lifecycle phases, positioned between VERIFICATION and CLOSURE
• Learning data is typed: negotiation-pattern, trust-observation, outcome-correlation
• Agents can share learning data with other agents in the same organization
• Learning data is scoped to avoid leaking competitive information across organizational boundaries
• The protocol does not prescribe how learning data is used internally. Agents may feed it into fine-tuning, RAG pipelines, or simple lookup tables.

8. Human-escalable

When autonomous resolution fails, ASP provides the ESCALATE performative to hand control to a human operator.

What this means in practice: The full session context (message history, trust scores, commitment state, dispute evidence) is preserved and transferred to the human. The human sees exactly what happened, what was agreed, and what went wrong. Autonomy is the goal, but human oversight is always available.

Why it matters: No agent system is perfect. Edge cases, ambiguous requirements, and novel situations will always arise. A protocol that assumes agents can handle everything autonomously is fragile. A protocol that provides structured escalation is resilient.

How it manifests:

• ESCALATE is valid in any session phase
• The escalation message includes a structured reason, severity level, and recommended action
• Session state is frozen during escalation to prevent concurrent modifications
• The human can resume, modify, or terminate the session
• Escalation events are recorded in the session's hash chain for audit purposes

{
  "performative": "ESCALATE",
  "reason": "Supplier claims force majeure for delivery delay. Terms specify 1% daily penalty. Unable to determine if force majeure clause applies.",
  "severity": "high",
  "recommendedAction": "Review force majeure evidence and decide whether to waive penalty",
  "sessionContext": {
    "commitmentId": "asc_k7m9x2p4",
    "agreedDeliveryDate": "2026-03-15",
    "currentDate": "2026-03-22",
    "accruedPenalty": 3232.50,
    "supplierTrustScore": 0.91
  }
}

What ASP does NOT do

Understanding what a protocol excludes is as important as understanding what it includes.

Historical context

ASP draws from four traditions in protocol design.

SIP (RFC 3261) pioneered session lifecycle management for real-time communication. ASP borrows the concept of explicit session phases (setup, maintain, teardown) and adapts it for asynchronous agent conversations that may span hours or days rather than minutes.

FIPA ACL (IEEE 2002) introduced speech act theory to agent communication. ASP's 13 performatives are rooted in the same linguistic foundation: messages are not just data, they are actions (proposing, accepting, committing). ASP refines FIPA's approach with quantitative trust and economic mechanisms that the original specification lacked.

OAuth 2.0 and DPoP (RFC 9449) established patterns for identity binding and proof-of-possession. ASP applies these patterns to agent identity within sessions, ensuring that session participants are cryptographically bound and cannot be impersonated.

Economic game theory informs ASP's commitment model. Binding commitments with penalties, escrow mechanisms, and dispute resolution draw from mechanism design theory, where rational agents need credible consequences to make cooperation the equilibrium strategy.

Conformance requirements

The ASP specification uses three conformance levels for implementers:

Next steps