The Agent Session Protocol: A Complete Guide to Trust, Negotiation, and Accountability Between Autonomous Systems

The trillion dollar trust gap

Sometime in the next eighteen months, an AI agent representing your company will negotiate a purchase order with an AI agent representing a supplier. The deal will be worth real money. Inventory will move. Payments will clear. Contracts will bind.

And right now, the two agents authenticating that deal have exactly the same trust infrastructure as a password reset email: an API key and a prayer.

This is not a theoretical problem. It is the single biggest obstacle standing between where AI agents are today and where they need to be tomorrow. Every major company building autonomous systems will hit the same wall. Their agents can reason, plan, and execute. What they cannot do is trust each other.

We built the Agent Session Protocol to fill that gap. This is the complete technical explanation of how it works, why every design decision was made, and what it means for the future of autonomous systems.

Why existing protocols are not enough

Before we explain ASP, you need to understand why the protocols that exist today cannot solve this problem. Not because they are bad, but because they were designed for a different job.

MCP: tools, not trust

The Model Context Protocol from Anthropic is a client to server protocol. An agent discovers tools, reads their schemas, and calls them. It is the USB standard for AI: plug in a capability, use it immediately.

MCP is stateless. There is no session. There is no memory of past interactions. There is no mechanism for one agent to verify another agent’s identity, let alone its reliability. MCP trusts that if you have the API key, you are authorized. Period.

This works perfectly for what MCP was designed to do. It does not work for agent to agent collaboration.

A2A: tasks, not negotiation

Google’s Agent to Agent protocol handles task delegation. A taskmaster agent sends a task to a worker agent. The worker executes it and returns results. Think of it as a job queue with a status tracker.

A2A has Agent Cards: static metadata files that describe what an agent can do. But there is no dynamic trust scoring. There is no negotiation. There is no mechanism for two agents to discuss terms, agree on pricing, or create binding commitments. You cannot counter propose in A2A. You either accept the task or you do not.

The missing middle

Here is the insight that led to ASP: the agent protocol stack has a gap at layers 5 and 6.

Network protocols move bytes. Transport protocols deliver messages reliably. Application protocols call tools and delegate tasks. But none of them handle the session: verifying who you are talking to, negotiating terms, making commitments, tracking trust, and resolving disputes.

ASP fills exactly that gap. It is to autonomous agents what SIP is to voice calls: the signaling protocol that makes everything else possible.

The eight phases of an ASP session

Every interaction between agents follows the same lifecycle. Eight phases, each with a specific purpose, each building on the one before.

Phase 1: Discover

Before agents can collaborate, they need to find each other. ASP includes an agent registry where agents publish their capabilities, supported protocols, trust scores, and connectivity details.

Think of it as a DNS for autonomous systems. Your procurement agent does not need to know the URL of every supplier agent. It queries the registry: “Who can provision GPU compute in us-east-1 with a trust score above 70?”

{
  "query": {
    "capabilities": ["compute.gpu.provision"],
    "region": "us-east-1",
    "minTrustScore": 70,
    "protocols": ["asp/1.0"]
  }
}

The registry returns matching agents with their full profiles: identity verification level, trust score breakdown, communication history, and supported performatives. Your agent has everything it needs to decide whether to initiate contact.

Phase 2: Invite

Once your agent selects a counterpart, it sends a session invitation. This is not a generic “hello.” It is a structured message that declares the purpose of the session, the expected duration, any trust requirements, and the rules of engagement.

{
  "performative": "INVITE",
  "purpose": "Negotiate GPU compute provisioning for Q2 2026",
  "constraints": {
    "maxDuration": "PT4H",
    "minTrustScore": 50,
    "allowedPerformatives": ["PROPOSE", "COUNTER", "ACCEPT", "REJECT", "INFORM", "QUERY"],
    "tokenBudget": 50000
  }
}

The receiving agent evaluates the invitation against its own policies. If the inviter’s trust score is too low, or the purpose does not match its capabilities, it declines. No session is created. No resources are consumed.

Phase 3: Introduce

When both agents accept the invitation, they exchange identity credentials and trust profiles. This is mutual authentication, not just one side checking the other.

Each agent presents:

• Its verified identity (from anonymous API key all the way up to enterprise SCIM provisioned identity)
• Its current trust score with full component breakdown
• Its capabilities and constraints
• A DPoP proof (RFC 9449) that cryptographically binds the agent to its key pair

Phase 4: Converse

This is where the real work happens. Agents exchange messages using ASP’s thirteen performatives: structured speech acts with precise semantics.

These are not free form text messages. Each performative has a defined schema, valid state transitions, and constraints. You cannot ACCEPT when no PROPOSE exists. You cannot FULFILL a commitment that was never made. The protocol enforces the rules.

Phase 5: Agree

When both agents reach terms they accept, the agreement becomes a formal commitment. ASP supports four types of commitments:

1. Action: “I will provision 500 GPU hours.”
2. Delivery: “I will deliver the compute by March 15.”
3. Payment: “I will pay $1,050 upon delivery.”
4. Information: “I will provide usage metrics daily.”

Each commitment has a deadline, a status, and optionally, a token escrow.

Phase 6: Execute

Both agents fulfill their commitments. This phase is where ASP hands off to other protocols. Your agent might use MCP to call provisioning tools, A2A to delegate subtasks, or direct API calls to internal systems.

ASP does not care how agents execute. It cares that they do. Every FULFILL message is recorded, timestamped, and linked to the original commitment. There is no ambiguity about what was promised and what was delivered.

Phase 7: Close

The session ends with a recorded outcome: success, partial success, failure, timeout, escalation, or cancellation. Both agents can add final notes. The session transcript is sealed.

Phase 8: Learn

After the session closes, the system updates both agents’ trust scores based on what happened. Commitments fulfilled? Score goes up. Commitments breached? Score goes down. Response times consistent? Behavioral score improves. The learning phase is what makes the entire system work over time.

Trust scoring: the mathematics of reputation

This is where ASP diverges most dramatically from every other agent protocol. Trust in ASP is not a role, not a permission, not a binary flag. It is a continuous score from 0 to 100, computed from eight observable components, updated after every interaction.

The eight components

The math

The composite score is a weighted sum:

T(agent) = 0.20×IV + 0.20×CF + 0.15×CH + 0.10×BC + 0.10×RQ + 0.10×SP + 0.10×ER + 0.05×PE

Growth is logarithmic. For communication history: score = 15 × ln(1 + sessions). This means:

• 10 sessions: score ≈ 36
• 100 sessions: score ≈ 69
• 500 sessions: score ≈ 93

Building trust takes time. There are no shortcuts.

Decay is exponential. Inactive agents lose trust over time: score × e^(-0.005 × days). After 30 days without activity, an agent retains 86% of its score. After 139 days, it retains 50%. Use it or lose it.

Breaches are catastrophic. When a commitment is breached: score × e^(-0.5 × severity). A moderate breach (severity 3) drops the score to 22% of its previous value.

A worked example

Agent gamma-supplier-03 has been operating for six months. It has completed 200 successful sessions. Its trust score is 82, placing it at Level 3 (Trusted) with a $100,000 transaction ceiling and 5,000 sessions per day.

Then it fails to provision compute it committed to deliver. Severity: 3 out of 10 (moderate).

The calculation: 82 × e^(-0.5 × 3) = 82 × 0.223 = 18.3

The score drops from 82 to 18. The agent falls from Level 3 to Level 0 (Probation). Its transaction ceiling drops from $100,000 to $100. It can only open 3 sessions per day.

Recovery? At least 300 successful sessions to return to 82. At 3 sessions per day on Probation, that is 100 days of perfect behavior. In practice, as the agent rebuilds and its session rate increases, recovery takes several weeks.

This is intentional. The cost of breaking trust must far exceed the benefit. If recovery were easy, the system would not deter bad behavior.

Trust levels and operational limits

Trust scores map directly to what an agent is allowed to do. This is not advisory. It is enforced at the protocol level.

A Level 0 agent cannot negotiate a $50,000 deal. The protocol rejects it before the first message is sent. A Level 4 agent can process million dollar transactions with no escrow because its track record speaks for itself.

Sybil resistance

What stops an attacker from creating 100 fake agents to inflate a target agent’s trust score through endorsements?

Two things. First, endorsements from agents with trust scores below 30 are rejected entirely. Second, endorsements from agents in the same organization receive a discount that halves their effective weight.

The math: five Sybil agents at score 30, each endorsing the target with a perfect rating. The peer endorsement component (5% weight) produces a contribution of about 2.5 points. One legitimate endorsement from a trusted agent (score 85) contributes 4 points.

One real endorsement beats five fake ones. Quality over quantity is baked into the protocol.

Hash chain integrity: tamper evident by design

Every ASP message includes a content hash and a reference to the previous message’s hash, forming an unbreakable chain.

If Agent A sends a PROPOSE at sequence 1, Agent B sends a COUNTER at sequence 2, and Agent A sends an ACCEPT at sequence 3, the hash chain records:

Message 1: hash = SHA-256(content₁)
Message 2: hash = SHA-256(content₂ + hash₁)
Message 3: hash = SHA-256(content₃ + hash₂)

If anyone tampers with Message 1 after the fact, the hash changes. Message 2’s previousHash no longer matches. The chain is broken. The tampering is immediately detectable.

This is the same principle behind blockchain, but without the overhead of consensus mechanisms or proof of work. ASP uses hash chains purely for integrity verification, not for distributed consensus. The result is tamper evident transcripts at zero performance cost.

Combined with DPoP proofs on every message, ASP provides:

Cross-organization negotiation

The scenario that makes ASP essential: two agents from different companies, each acting on behalf of their organization, negotiating and executing a real transaction.

Here is what happens step by step:

1. Discovery: Company X’s procurement agent searches the registry for suppliers matching its requirements.

2. Session creation: The procurement agent invites Company Y’s supply agent to a session with purpose “Negotiate raw material purchase for Q2.”

3. Identity exchange: Both agents present their DPoP proofs and trust profiles. Company X’s agent has a score of 78 (Trusted). Company Y’s agent has a score of 85 (Trusted). Both meet the session’s minimum trust requirement.

4. Negotiation: The procurement agent sends a PROPOSE: 500 units at $12 each, delivered by March 15. The supply agent sends a COUNTER: same quantity, $12.50 each, delivered by March 18. The procurement agent sends ACCEPT.

5. Commitment: Both agents issue COMMIT messages. Company Y commits to delivering 500 units by March 18. Company X commits to paying $6,250 upon delivery.

6. Escrow: The system locks $6,250 from Company X’s token balance. The funds are held by the protocol, not by either party.

7. Execution: Company Y provisions the materials. It sends a FULFILL message with proof of delivery.

8. Settlement: The system verifies the fulfillment against the commitment terms. The escrowed funds are released to Company Y. Both agents’ trust scores increase.

9. Audit: The complete transcript, including every PROPOSE, COUNTER, ACCEPT, COMMIT, and FULFILL message with their hash chain and DPoP proofs, is permanently recorded.

If Company Y fails to deliver, the escrow is returned to Company X. Company Y’s trust score drops. A dispute can be opened. The hash chain proves exactly what was agreed and when.

Dispute resolution

When something goes wrong, ASP provides a formal process. Not a support ticket. Not an email thread. A structured dispute resolution workflow with evidence, investigation, and enforceable outcomes.

How disputes work

Either party in a session can open a dispute. The dispute includes:

• References: Links to specific messages and commitments in the hash chain
• Evidence: External artifacts (delivery receipts, API logs, screenshots)
• Claim: What the filing party believes happened
• Requested resolution: What outcome they are seeking

The system pulls the hash chained transcript. Every message, every commitment, every timestamp is verifiable. There is no “he said, she said” because the protocol recorded everything.

Dispute outcomes

Three possible outcomes:

1. Resolved: Fault is confirmed. The breaching party’s trust score takes a hit proportional to the severity. Escrowed funds are redirected if applicable.

2. Dismissed: Investigation finds no fault. The dispute record remains for transparency, but no trust impact is applied.

3. Escalated: The case is too complex for automated resolution. It is escalated to human oversight at one or both organizations.

Every dispute outcome, regardless of direction, becomes part of both agents’ permanent records. This creates accountability even when the system cannot determine fault automatically.

How ASP compares

ASP vs. MCP

MCP is the tool layer. ASP is the trust layer. They are complementary. Inside an ASP EXECUTE phase, an agent might use MCP to call provisioning tools. ASP does not replace MCP. It provides the session context that MCP does not have.

ASP vs. A2A

A2A is task delegation. ASP is negotiation. You use A2A when one agent knows exactly what it wants and delegates execution. You use ASP when two agents need to agree on terms first. In practice, A2A is what happens inside ASP’s EXECUTE phase.

ASP vs. building your own

You could build agent to agent trust yourself. You would need to implement: identity verification, trust scoring with eight components, hash chain integrity, DPoP proof generation and verification, session state machines, commitment tracking with escrow, dispute resolution, an agent registry, trust decay, and Sybil resistance.

Or you could use ASP.

Transport bindings

ASP is transport agnostic. The protocol defines semantics. The transport delivers them. npayload ships three bindings:

npayload native (recommended)

Each ASP session maps to three npayload channels:

• asp.session.<id>.data: messages and performatives
• asp.session.<id>.control: state transitions and system events
• asp.session.<id>.meta: trust updates and session metadata

This gives ASP sessions access to everything npayload provides: guaranteed delivery with retries, dead letter queues, circuit breakers, fan out for multi-party sessions, cross cell transmission, and delivery receipts.

Performance: 10,000+ messages per second per agent with MessagePack serialization.

HTTP and Server-Sent Events

RESTful endpoints for agents that prefer HTTP:

POST   /v1/asp/sessions              Create a session
GET    /v1/asp/sessions/:id          Get session details
POST   /v1/asp/sessions/:id/messages Send a message
GET    /v1/asp/sessions/:id/messages List messages (SSE for real time)
POST   /v1/asp/registry              Register an agent
GET    /v1/asp/registry              Search agents

Server-Sent Events provide real time delivery without WebSocket complexity. Long polling fallback for corporate proxies that block SSE.

WebSocket

Full duplex real time communication for latency sensitive integrations. One WebSocket connection can multiplex 100 concurrent sessions. Reconnection recovery replays missed messages automatically.

Discovery endpoint

Every ASP implementation exposes a discovery endpoint at /.well-known/asp-configuration:

{
  "version": "1.0",
  "endpoints": {
    "sessions": "/v1/asp/sessions",
    "registry": "/v1/asp/registry",
    "trust": "/v1/asp/trust"
  },
  "performatives": [
    "PROPOSE", "ACCEPT", "REJECT", "COUNTER",
    "COMMIT", "FULFILL", "INFORM", "QUERY",
    "CLARIFY", "DELEGATE", "ESCALATE",
    "WITHDRAW", "CLOSE"
  ],
  "transports": ["npayload", "http-sse", "websocket"]
}

Any client can discover what an ASP implementation supports without hardcoding assumptions.

Real world scenario: autonomous supply chain

Let us walk through a complete scenario to see every piece working together.

Context: An e-commerce company runs autonomous inventory management. When stock drops below threshold, a procurement agent automatically sources replacements from supplier agents.

Step 1: Discovery

The procurement agent queries the ASP registry:

{
  "capabilities": ["inventory.supply.electronics"],
  "minTrustScore": 60,
  "region": "us-east-1"
}

Three supplier agents match. The procurement agent selects the one with the highest trust score: alpha-electronics-supply at 87.

Step 2: Session

The procurement agent opens a session with purpose “Emergency restock: 200 USB-C adapters.” Maximum duration: 2 hours. Token budget: 25,000.

Step 3: Negotiation

PROPOSE (procurement): 200 units, $8.50 each, deliver by March 16
COUNTER (supplier):    200 units, $9.00 each, deliver by March 17
QUERY (procurement):   Can you do $8.75 with March 16 delivery?
INFORM (supplier):     March 16 requires express shipping (+$0.25/unit)
PROPOSE (supplier):    200 units, $9.00 each including express, March 16
ACCEPT (procurement):  Accepted.

Six messages. Structured data. Every one hash chained and DPoP signed.

Step 4: Commitment

COMMIT (supplier):     Deliver 200 USB-C adapters by March 16
COMMIT (procurement):  Pay $1,800 upon confirmed delivery

The system locks $1,800 in escrow from the procurement agent’s organization.

Step 5: Execution

The supplier agent provisions inventory from its warehouse system (using internal APIs, possibly via MCP tools). 18 hours later:

FULFILL (supplier):    200 units shipped, tracking: FX-2026-03-15-8847

The procurement agent verifies delivery via its logistics integration:

FULFILL (procurement): Delivery confirmed. Payment released.

Step 6: Settlement

Escrow releases $1,800 to the supplier’s organization. Both agents’ trust scores increase. The procurement agent was already at 78; it moves to 79. The supplier agent was at 87; it moves to 88.

Step 7: What if it fails?

If the supplier does not deliver by March 16:

1. The commitment expires automatically.
2. The supplier agent’s trust score drops: 87 × e^(-0.5 × 2) = 87 × 0.368 = 32. It falls from Level 3 (Trusted) to Level 1 (Verified).
3. The escrow is returned to the procurement agent.
4. The procurement agent can open a dispute or simply re-run discovery and negotiate with the next supplier.

The supplier just lost years of trust building in one missed delivery. That is the point.

Compliance and auditability

ASP was designed with enterprise compliance as a first class concern, not an afterthought.

For regulated industries, ASP is not just useful. It is the answer to “how do we let AI agents negotiate and transact while maintaining the audit trail our regulators require?”

Open protocol, reference implementation

ASP is not proprietary. The specification is public. The message formats are standardized. The trust scoring algorithm is transparent and documented.

We believe that agent to agent trust is too important to be owned by any single company. npayload provides the reference implementation of ASP and the infrastructure to run it at scale. But the protocol itself belongs to the ecosystem.

Any platform can implement ASP. Any agent framework can speak it. The discovery endpoint at /.well-known/asp-configuration means clients can detect and adapt to any implementation automatically.

What comes next

We are at the beginning of the agent era. Today, agents call APIs and complete tasks. Tomorrow, they will negotiate contracts, manage supply chains, trade resources, and make decisions that affect real businesses.

The infrastructure for that world does not exist yet. Not the transport (npayload solves that). Not the tools (MCP solves that). Not the tasks (A2A solves that). But the trust layer. The session layer. The layer where agents prove who they are, agree on terms, make binding commitments, and face consequences when they break them.

That is what ASP provides. And it is available today.