Performatives

Every ASP message carries a performative: a declaration of what the sender intends to accomplish by sending it. A PROPOSE is not just data. It is an act of proposing. An ACCEPT is not a status update. It is the act of agreeing. This distinction, rooted in speech act theory (Austin, 1962; Searle, 1969), is what separates structured negotiation from unstructured message passing.

ASP defines 13 performatives across four categories. Each has defined semantics, a body schema, and a set of allowed transitions that determine which performatives may follow it in a session.

Negotiation

The core back-and-forth of agent interaction. These four performatives handle proposals, agreements, rejections, and counter-offers.

PROPOSE

Suggest terms, actions, or session invitations. This is the primary initiating performative in most sessions. A PROPOSE creates a proposal that the recipient can accept, reject, counter, or request clarification on.

{
  "performative": "PROPOSE",
  "content": {
    "mimeType": "application/json",
    "body": {
      "proposalId": "prop_019478a3",
      "type": "service-agreement",
      "subject": "Data processing pipeline setup",
      "terms": {
        "throughput": "10000 events/sec",
        "latency": "< 200ms p99",
        "price": { "amount": 0.001, "currency": "USD", "per": "event" }
      },
      "validUntil": "2026-03-08T00:00:00.000Z"
    }
  }
}

Understanding the PROPOSE body

Field	Type	Required	Description
`proposalId`	string	Yes	Unique identifier for this proposal, used by ACCEPT, REJECT, and COUNTER to reference it
`type`	string	Yes	Proposal category: `service-agreement`, `data-exchange`, `session-invitation`, `resource-allocation`
`subject`	string	Yes	Human-readable summary of what is being proposed
`terms`	object	Yes	The proposed terms. Structure varies by proposal type.
`validUntil`	ISO 8601	No	Expiration timestamp. After this time, the proposal is void and cannot be accepted.

Allowed responses: ACCEPT, REJECT, COUNTER, CLARIFY

ACCEPT

Agree to a proposal as stated. An ACCEPT is a binding response that creates obligations for both parties based on the accepted terms. The referenceId links back to the proposal being accepted.

{
  "performative": "ACCEPT",
  "content": {
    "mimeType": "application/json",
    "body": {
      "referenceId": "prop_019478a3",
      "acknowledgment": "Terms accepted. Ready to begin data pipeline provisioning."
    }
  }
}

Understanding the ACCEPT body

Field	Type	Required	Description
`referenceId`	string	Yes	The `proposalId` of the proposal being accepted
`acknowledgment`	string	No	Optional confirmation message for the counterparty

May be followed by: INFORM, COMMIT, DELEGATE, CLOSE

REJECT

Decline a proposal with a reason and a machine-readable code. A REJECT is terminal for that specific proposal but does not end the session. The sender may issue a new PROPOSE with different terms.

{
  "performative": "REJECT",
  "content": {
    "mimeType": "application/json",
    "body": {
      "referenceId": "prop_019478a3",
      "reason": "Latency requirement cannot be met in the requested region",
      "code": "capacity_unavailable",
      "retryable": true
    }
  }
}

Understanding the REJECT body

Field	Type	Required	Description
`referenceId`	string	Yes	The `proposalId` of the proposal being rejected
`reason`	string	Yes	Human-readable explanation of why the proposal was rejected
`code`	string	Yes	Machine-readable rejection code from the table below
`retryable`	boolean	No	Whether a modified proposal on the same topic has a reasonable chance of acceptance. Defaults to `false`.

Rejection codes

Code	Meaning
`insufficient_trust_score`	Sender's trust score is below the required threshold
`unauthorized`	Sender lacks permission for the requested action
`schema_unsupported`	The proposal uses a schema the recipient cannot process
`budget_exceeded`	The proposed cost exceeds the recipient's budget
`capacity_unavailable`	The recipient cannot meet the capacity requirements
`policy_violation`	The proposal violates the recipient's policies
`timeout`	The proposal expired before it could be evaluated
`duplicate`	An equivalent proposal is already active
`escalation_required`	The proposal requires human approval before the agent can respond
`unspecified`	No specific reason provided. Use sparingly.

May be followed by: PROPOSE, INFORM, CLOSE

COUNTER

Reject and simultaneously propose alternative terms. A COUNTER combines the semantics of REJECT and PROPOSE in a single atomic message, avoiding the ambiguity of sending them separately.

{
  "performative": "COUNTER",
  "content": {
    "mimeType": "application/json",
    "body": {
      "referenceId": "prop_019478a3",
      "originalTerms": {
        "throughput": "10000 events/sec",
        "latency": "< 200ms p99",
        "price": { "amount": 0.001, "currency": "USD", "per": "event" }
      },
      "counterTerms": {
        "throughput": "10000 events/sec",
        "latency": "< 500ms p99",
        "price": { "amount": 0.0008, "currency": "USD", "per": "event" }
      },
      "rationale": "Can meet throughput but need higher latency tolerance. Offering reduced price to compensate."
    }
  }
}

Understanding the COUNTER body

Field	Type	Required	Description
`referenceId`	string	Yes	The `proposalId` of the proposal being countered
`originalTerms`	object	No	Echo of the original terms for clarity. Useful in multi-round negotiations.
`counterTerms`	object	Yes	The alternative terms being proposed
`rationale`	string	No	Explanation of why the original terms were rejected and how the counter addresses the gap

Counters can include a "final": true field to signal last-offer semantics. When final is true, the sender indicates this is their best offer and further countering is not productive. The recipient should ACCEPT or REJECT rather than COUNTER again.

Allowed responses: ACCEPT, REJECT, COUNTER, CLARIFY

Information

Performatives for sharing data, requesting data, and resolving ambiguity.

INFORM

Share information without requesting a response. INFORM is the most flexible performative and can carry status updates, progress reports, identity assertions, factual statements, computation results, or error notifications.

{
  "performative": "INFORM",
  "content": {
    "mimeType": "application/json",
    "body": {
      "topic": "execution-progress",
      "data": {
        "stage": "data-ingestion",
        "percentComplete": 73,
        "estimatedCompletion": "2026-03-07T15:45:00.000Z"
      },
      "format": "progress-report"
    }
  }
}

Understanding the INFORM body

Field	Type	Required	Description
`topic`	string	Yes	What the information is about: `status`, `progress`, `identity`, `fact`, `result`, `error`
`data`	object	Yes	The information payload. Structure varies by topic.
`format`	string	No	Hint for how the recipient should interpret the data

Any performative may follow an INFORM. It places no constraints on the conversation flow.

QUERY

Request specific information from another agent. A QUERY expects an INFORM response containing the requested data. Queries can include a responseFormat that tells the recipient the expected shape of the answer.

{
  "performative": "QUERY",
  "content": {
    "mimeType": "application/json",
    "body": {
      "question": "What throughput can you sustain for JSON event processing?",
      "responseFormat": {
        "type": "object",
        "properties": {
          "maxThroughput": { "type": "number" },
          "unit": { "type": "string" }
        }
      },
      "context": "Evaluating providers for high-volume event pipeline"
    }
  }
}

Understanding the QUERY body

Field	Type	Required	Description
`question`	string	Yes	The information being requested, in natural language or structured form
`responseFormat`	object	No	JSON Schema describing the expected shape of the response
`context`	string	No	Additional context to help the recipient provide a relevant answer

Expected response: INFORM

CLARIFY

Request clarification on an ambiguous message. CLARIFY does not accept or reject the referenced message. It pauses evaluation until the ambiguity is resolved.

{
  "performative": "CLARIFY",
  "content": {
    "mimeType": "application/json",
    "body": {
      "referenceId": "prop_019478a3",
      "questions": [
        {
          "field": "terms.latency",
          "question": "Does the latency requirement apply to median or p99?",
          "options": ["p50", "p95", "p99", "p999"]
        }
      ],
      "ambiguities": [
        "The 'latency' field specifies '< 200ms' without a percentile qualifier"
      ]
    }
  }
}

Understanding the CLARIFY body

Field	Type	Required	Description
`referenceId`	string	Yes	The `messageId` or `proposalId` of the ambiguous message
`questions`	array	Yes	Structured questions, each with a `field` path, `question` text, and optional `options`
`ambiguities`	array	No	Plain-text descriptions of what is unclear

Expected response: INFORM (with the clarifying information)

Action

Performatives that create binding obligations, transfer responsibility, or request human intervention.

COMMIT

Create a binding obligation. COMMIT is the strongest performative in ASP. It transforms a negotiated agreement into a formal obligation with deadlines, verification methods, penalties, and optional escrow.

{
  "performative": "COMMIT",
  "content": {
    "mimeType": "application/json",
    "body": {
      "commitmentId": "cmt_019478c1",
      "terms": {
        "referenceId": "prop_019478a3",
        "obligations": [
          {
            "party": "agent://acme.com/services/data-processor",
            "action": "Process events at 10,000/sec with < 500ms p99 latency",
            "deadline": "2026-04-07T00:00:00.000Z",
            "verificationMethod": "metric-query"
          }
        ],
        "penalties": {
          "lateFulfillment": "5% escrow forfeit per day",
          "nonDelivery": "full escrow forfeit"
        }
      },
      "deadline": "2026-04-07T00:00:00.000Z",
      "escrow": {
        "amount": 500,
        "currency": "USD",
        "releaseCondition": "obligation-met"
      }
    }
  }
}

Understanding the COMMIT body

Field	Type	Required	Description
`commitmentId`	string	Yes	Unique identifier for this commitment
`terms`	object	Yes	The full terms including obligations, penalties, and reference to the accepted proposal
`deadline`	ISO 8601	Yes	Overall deadline for all obligations
`penalties`	object	No	Consequences for late or non-fulfillment
`escrow`	object	No	Resources to hold until fulfillment is verified

A COMMIT cannot be withdrawn after the other party sends ACCEPT. Once both sides have agreed to a commitment, it is binding. Breach triggers the dispute resolution process.

May be followed by: ACCEPT, REJECT, INFORM, CLOSE

DELEGATE

Transfer responsibility for part of a session to another agent. The delegating agent remains accountable for the outcome even after delegation.

{
  "performative": "DELEGATE",
  "content": {
    "mimeType": "application/json",
    "body": {
      "delegateId": "agent://acme.com/specialists/compliance-checker",
      "task": "Verify regulatory compliance of proposed data handling terms",
      "authority": "advisory",
      "constraints": {
        "maxDuration": 300000,
        "protocol": "asp"
      }
    }
  }
}

Understanding the DELEGATE body

Field	Type	Required	Description
`delegateId`	string	Yes	The `agent://` URI of the agent receiving the delegation
`task`	string	Yes	Description of what the delegate should do
`authority`	string	Yes	The level of decision-making power granted
`constraints`	object	No	Limits on the delegation (duration, protocol, scope)

Authority levels:

Level	Meaning
`full`	The delegate can accept, reject, or counter on behalf of the delegating agent
`limited`	The delegate can inform and query but cannot make binding decisions
`advisory`	The delegate provides recommendations only, with no session authority

Protocol options: asp, a2a, mcp

ESCALATE

Escalate the session to a human operator or higher authority. When an agent reaches the limits of its autonomous capability, ESCALATE transfers the session context to a human for resolution. The session enters the ESCALATED state and pauses autonomous processing.

{
  "performative": "ESCALATE",
  "content": {
    "mimeType": "application/json",
    "body": {
      "reason": "authority-limit",
      "context": "Proposed commitment exceeds my authorized spending limit of $1000",
      "severity": "high",
      "suggestedResolution": "Request budget increase or reduce commitment scope to $800"
    }
  }
}

Understanding the ESCALATE body

Field	Type	Required	Description
`reason`	string	Yes	Why escalation is needed (see table below)
`context`	string	Yes	Detailed explanation for the human operator
`severity`	string	Yes	Urgency level: `low`, `medium`, `high`, `critical`
`suggestedResolution`	string	No	The agent's recommendation for how to resolve the situation

Escalation reasons:

Reason	When to use
`authority-limit`	The decision exceeds the agent's authorized scope
`confidence-low`	The agent is not confident enough to proceed autonomously
`policy-ambiguous`	The applicable policy is unclear or contradictory
`adversarial-detected`	The agent suspects the counterparty is acting in bad faith

WITHDRAW

Leave a session or retract a previous proposal without penalty. WITHDRAW is only valid for messages that have not yet been accepted.

{
  "performative": "WITHDRAW",
  "content": {
    "mimeType": "application/json",
    "body": {
      "reason": "Updated pricing model available. Replacing with revised proposal."
    }
  }
}

Understanding the WITHDRAW body

Field	Type	Required	Description
`reason`	string	Yes	Explanation of why the agent is withdrawing

You cannot withdraw an accepted COMMIT. If a commitment has been accepted by both parties, it is binding. Use the dispute resolution process to handle disagreements about active commitments.

Lifecycle

Performatives for recording observations and ending sessions.

OBSERVE

Record facts, patterns, or learnings without expecting a response. OBSERVE is used heavily during the LEARN phase after a session closes, but it can appear at any point in a session.

{
  "performative": "OBSERVE",
  "content": {
    "mimeType": "application/json",
    "body": {
      "patterns": [
        "Counterparty consistently counters with 15-20% price reduction",
        "Response time increases when discussing compliance topics"
      ],
      "metrics": {
        "negotiationRounds": 4,
        "timeToAgreement": 127000
      },
      "notes": "Consider starting 10% above target price in future negotiations with this counterparty"
    }
  }
}

Understanding the OBSERVE body

Field	Type	Required	Description
`patterns`	array	No	Behavioral patterns identified during the session
`metrics`	object	No	Quantitative measurements from the session
`notes`	string	No	Free-form observations for future reference

Visibility: OBSERVE messages are private by default. They are recorded for the sending agent's future reference and are not shared with the counterparty.

CLOSE

End the session. Both parties must send CLOSE for the session to enter the CLOSED state. If only one party sends CLOSE, the session enters a closing state and waits for the other party (10-second timeout).

{
  "performative": "CLOSE",
  "content": {
    "mimeType": "application/json",
    "body": {
      "rating": 4,
      "summary": "Service agreement established at $0.0008/event with 500ms p99 latency",
      "recommendations": [
        "Consider adding SLA monitoring as a commitment term",
        "Response times were excellent during negotiation"
      ]
    }
  }
}

Understanding the CLOSE body

Field	Type	Required	Description
`rating`	integer	Yes	Peer rating from 1 (poor) to 5 (excellent). Feeds into the Response Quality trust component.
`summary`	string	No	Human-readable summary of the session outcome
`recommendations`	array	No	Suggestions for the counterparty or for future sessions

Transition matrix

The following table shows which performatives can follow each performative. This is a simplified view. The full transition matrix, including phase-dependent constraints, is defined in the specification.

After receiving	Valid responses
PROPOSE	ACCEPT, REJECT, COUNTER, CLARIFY
ACCEPT	INFORM, COMMIT, DELEGATE, CLOSE
REJECT	PROPOSE, INFORM, CLOSE
COUNTER	ACCEPT, REJECT, COUNTER, CLARIFY
INFORM	Any performative
QUERY	INFORM
CLARIFY	INFORM
COMMIT	ACCEPT, REJECT, INFORM, CLOSE
DELEGATE	INFORM, ACCEPT, REJECT
ESCALATE	INFORM, CLOSE
WITHDRAW	INFORM, PROPOSE, CLOSE
OBSERVE	Any performative
CLOSE	CLOSE

INFORM and OBSERVE are "open" performatives. They can appear at any point and do not constrain what follows. Most other performatives have restricted transition sets that enforce the negotiation flow.

Quick reference

Performative	Category	Creates obligation?	Expects response?
PROPOSE	Negotiation	No	Yes
ACCEPT	Negotiation	Yes (binds to proposal terms)	No
REJECT	Negotiation	No	No
COUNTER	Negotiation	No	Yes
INFORM	Information	No	No
QUERY	Information	No	Yes
CLARIFY	Information	No	Yes
COMMIT	Action	Yes (binding obligation)	Yes
DELEGATE	Action	No (accountability stays with delegator)	No
ESCALATE	Action	No	No
WITHDRAW	Action	No (removes prior obligation)	No
OBSERVE	Lifecycle	No	No
CLOSE	Lifecycle	No	Yes (mutual close required)

Next steps

Message format

The JSON envelope, field reference, and cryptographic integrity chain that carries every performative

Sessions

The 8-phase lifecycle that governs when each performative is valid

Was this page helpful?

Performatives

Message format

Sessions

On this page