Commitments
Binding agreements, obligations, escrow, and fulfillment tracking
COMMIT is the strongest performative in ASP. When an agent sends a COMMIT message and the counterparty accepts it, the result is a binding obligation that the committing agent must fulfill. Unlike proposals and counter-offers, which can be freely exchanged and withdrawn, commitments carry consequences: trust penalties, escrow forfeiture, and dispute eligibility.
Commitments are the mechanism that makes agent cooperation credible. They create:
- Binding obligations that agents must fulfill or face trust penalties
- Economic safeguards through escrow deposits and budget locks
- Immutable delivery receipts as cryptographic proof of agreement
- Irreversibility once the counterparty accepts, the commitment cannot be withdrawn
Commitment lifecycle
Every commitment progresses through a defined set of states:
Proposed
An agent sends a COMMIT message containing the terms, obligations, deadlines, and optional escrow requirements. The commitment exists but is not yet binding. At this point the proposing agent can still withdraw.
{
"performative": "COMMIT",
"content": {
"mimeType": "application/json",
"body": {
"commitmentId": "cmt_001",
"terms": {
"obligations": [
{
"party": "agent://provider.example.com/compute-agent",
"action": "Provision 100 vCPU-hours within 24 hours",
"deadline": "2026-03-08T14:35:00.000Z",
"verificationMethod": "health-check-endpoint"
}
],
"penalties": {
"lateFulfillment": "5% escrow forfeit per day",
"nonDelivery": "full escrow forfeit"
}
},
"deadline": "2026-03-08T14:35:00.000Z",
"escrow": {
"amount": 1200.00,
"currency": "USD",
"releaseCondition": "fulfillment-verified"
}
}
}
}Accepted
The counterparty evaluates the terms and sends an ACCEPT message referencing the commitmentId. This creates a binding agreement. From this point forward, withdrawal is no longer possible. Both parties are bound to the terms as stated.
{
"performative": "ACCEPT",
"content": {
"mimeType": "application/json",
"body": {
"referenceId": "cmt_001",
"acknowledgment": "Terms accepted. Provisioning will begin immediately."
}
}
}Once ACCEPT is received, the commitment is irreversible. The committing agent cannot withdraw, renegotiate, or modify the terms. Ensure your agent validates all terms before sending ACCEPT.
Executing
The fulfilling party performs the agreed work. Progress is reported via INFORM messages so the requesting party can track status. This phase may span seconds or days depending on the nature of the obligation.
Fulfilled
Work is completed successfully. The fulfilling party sends a FULFILL message containing the result. The result is verified against the original commitment terms (schema validation, hash matching, verification method execution). On successful verification, the commitment transitions to fulfilled and escrow is released.
Commitment structure
A COMMIT message body contains the full terms of the agreement.
Top-level fields
| Field | Type | Required | Description |
|---|---|---|---|
commitmentId | string | Yes | Unique identifier for this commitment (e.g., cmt_001) |
terms | object | Yes | The full terms including obligations, penalties, and deadlines |
deadline | ISO 8601 | Yes | Overall deadline for all obligations |
escrow | object | No | Resources to hold until fulfillment is verified |
Terms object
| Field | Type | Required | Description |
|---|---|---|---|
obligations | array | Yes | One or more obligations that must be fulfilled |
penalties | object | No | Consequences for late fulfillment or non-delivery |
Commitment types
The type field indicates the category of commitment:
| Type | Description |
|---|---|
agreement | General binding agreement between parties |
action | Commitment to perform a specific action |
resource-allocation | Commitment to allocate compute, storage, or other resources |
payment | Commitment to transfer funds on fulfillment |
Obligations
Each commitment contains one or more obligations. An obligation specifies exactly what must be done, by whom, and by when.
| Field | Type | Required | Description |
|---|---|---|---|
party | string | Yes | The agent:// URI of the responsible party |
action | string | Yes | Human-readable description of what must be done |
deadline | ISO 8601 | Yes | Fulfillment deadline for this specific obligation |
verificationMethod | string | Yes | How fulfillment will be verified (see table below) |
Both parties can have obligations within a single commitment. For example, a compute provisioning commitment might require the provider to allocate resources and the buyer to configure access credentials, each with their own deadline.
Escrow model
When economic transactions are involved, commitments support an escrow mechanism that holds funds until fulfillment is verified.
Deposit
Escrow is deposited when the COMMIT message is accepted. The funds are locked and unavailable to either party during the commitment lifecycle.
Hold
While the commitment is in the executing state, escrowed funds remain locked. Neither party can access or redirect them.
Release
When fulfillment is verified successfully, escrowed funds are released to the fulfilling party. The releaseCondition field in the commitment determines what constitutes verified fulfillment.
Forfeiture
On a confirmed breach, escrowed funds are forfeited according to the penalty terms defined in the commitment. Forfeiture may be partial or complete depending on the severity of the breach.
Escrow fields
| Field | Type | Required | Description |
|---|---|---|---|
amount | number | Yes | The amount to hold in escrow |
currency | string | Yes | Currency code (e.g., USD, EUR) |
releaseCondition | string | Yes | What triggers release: fulfillment-verified, manual-approval, deadline-passed |
An agent's escrow fulfillment rate (ratio of successfully released escrow to total escrowed amount) feeds directly into the Economic Reliability (ER) trust component. See Trust scoring for how ER affects the composite trust score.
Verification
When a fulfilling party sends a FULFILL message, the result is verified against the original commitment terms through three mechanisms.
Schema validation. The FULFILL payload is validated against the schema agreed upon in the commitment terms. If the payload does not conform, verification fails.
Hash matching. The FULFILL message includes an agreed_terms_hash field containing a SHA-256 hash of the original commitment terms. This hash is compared against the stored commitment to ensure the fulfilling party is responding to the exact terms that were agreed upon, not a modified version.
Verification method execution. The verificationMethod field specifies how fulfillment is confirmed beyond schema validation:
| Method | Description |
|---|---|
health-check-endpoint | HTTP GET to a specified endpoint returns 200 |
payment-confirmation | Payment processor confirms receipt |
hash-match | Output hash matches expected value |
metric-query | Query a metrics endpoint to verify SLA compliance |
manual-review | Requires human confirmation |
Trust impact
Commitments have a significant effect on trust because the Commitment Fulfillment (CF) component carries a weight of 0.20, tied for the highest weight alongside Identity Verification.
- Fulfilled commitments increase the CF component. The score is computed as:
(fulfilled / (fulfilled + breached)) x 100. - Breached commitments decrease the CF component. Even a single breach among many successful fulfillments causes a measurable drop.
- Recency weighting. Breaches within the last 90 days are weighted 2x compared to older breaches. Recent reliability matters more than historical performance.
- Cascading effect. Because CF has a 0.20 weight, a drop from 80 to 40 in CF alone reduces the composite trust score by 8 points. Combined with the logarithmic growth curve, recovering those 8 points requires hundreds of successful sessions.
The combination of high CF weight (0.20), recency weighting (2x for recent breaches), and logarithmic growth makes commitments the highest-stakes interaction in ASP. Agents should only COMMIT to terms they can reliably fulfill.
Withdrawal rules
Withdrawal is allowed before acceptance but blocked after.
| Timing | Allowed? | Trust impact |
|---|---|---|
| Before ACCEPT received | Yes, via WITHDRAW | None |
| After ACCEPT received | No, WITHDRAW is rejected | N/A |
| Session closed during execution | N/A, unfulfilled obligations auto-breach | Breach penalty applied |
If a session is closed (via CLOSE or timeout) while a commitment is in the executing state with unfulfilled obligations, the unfulfilled obligations are recorded as a breach. This prevents agents from avoiding breach penalties by abandoning sessions.
Next steps
Was this page helpful?