Session State Machine

Every ASP session follows a deterministic state machine. The current state determines which performatives are valid, and each performative triggers a well-defined transition. Implementations MUST enforce these transitions and MUST reject messages that violate the state machine.

States

ASP defines 9 session states:

State Diagram

                         PROPOSE (session-invitation)
                 IDLE ────────────────────────► INVITED
                                                    │
                                              ACCEPT │ + identity exchange
                                            (REJECT) │──────────► FAILED
                                             (timeout)│
                                                    ▼
                                              INTRODUCED
                                                    │
                                    PROPOSE / QUERY │ / INFORM / OBSERVE
                                                    │
                              ┌─────────────────────▼──────────────────────┐
                              │              CONVERSING                    │
                              │                                            │
                              │  Valid: PROPOSE, COUNTER, INFORM, QUERY,   │
                              │         CLARIFY, OBSERVE, DELEGATE,        │
                              │         WITHDRAW, ESCALATE, CLOSE          │
                              └──────────────────┬─────────────────────────┘
                                                 │                    ▲
                                          COMMIT │                    │ REJECT / COUNTER
                                                 │                    │
                              ┌──────────────────▼────────────────────┘
                              │              AGREEING                      │
                              │                                            │
                              │  Valid: ACCEPT, REJECT, COUNTER, CLARIFY,  │
                              │         ESCALATE, CLOSE                    │
                              └──────────────────┬─────────────────────────┘
                                                 │
                                          ACCEPT │ (of COMMIT)
                                                 │
                              ┌──────────────────▼─────────────────────────┐
                              │              EXECUTING                     │
                              │                                            │
                              │  Valid: INFORM (progress/result), QUERY,   │
                              │         ESCALATE, CLOSE                    │
                              └──────────────────┬─────────────────────────┘
                                                 │
                                           CLOSE │ (after fulfillment)
                                                 ▼
                              ┌────────────────────────────────────────────┐
                              │               CLOSED                       │
                              └────────────────────────────────────────────┘

        Any state ──── ESCALATE ───► ESCALATED ──── resolve ───► Previous state
        Any state ──── timeout/error ───► FAILED
        Any state ──── WITHDRAW ───► CLOSED
        Any state ──── CLOSE ───► CLOSED

Transition Table

The complete set of valid state transitions:

Transition Details

1. IDLE to INVITED

Trigger: PROPOSE with type: "session-invitation"

Actions on transition:

• Generate a new sessionId (UUID v7)
• Create the session communication channel
• Start the invitation timeout (default: 30 seconds)

The invitation MUST include a validUntil field or use the default timeout. If no response is received before the deadline, the session transitions to FAILED.

2. INVITED to INTRODUCED

Trigger: ACCEPT from the target agent, followed by both parties exchanging INFORM with informType: "identity"

Actions on transition:

• Record both agent identities in the session
• Verify Agent Card signatures against published public keys
• Cancel the invitation timeout

3. INTRODUCED to CONVERSING

Trigger: Any conversational performative (PROPOSE, QUERY, INFORM, OBSERVE)

Actions on transition:

• Enable the full set of performatives based on the declared conformance level
• Start the session timeout if configured

4. CONVERSING to AGREEING

Trigger: COMMIT from either participant

Actions on transition:

• Record the pending commitment
• The session awaits ACCEPT, REJECT, COUNTER, or CLARIFY from the other party
• Start the response timeout if constraints.maxResponseTimeMs is set

5. AGREEING to EXECUTING

Trigger: ACCEPT received on the pending COMMIT

Actions on transition:

• Create a binding agreement record
• Activate escrow if present
• Both parties begin fulfilling obligations

6. AGREEING to CONVERSING

Trigger: REJECT or COUNTER received on the pending COMMIT

Actions on transition:

• Clear the pending commitment
• Return to open negotiation
• If COUNTER was sent, the counter-proposal becomes the active topic

7. EXECUTING to CLOSED

Trigger: INFORM with informType: "result" confirming fulfillment, followed by CLOSE from both parties

Actions on transition:

• Record the session outcome
• Release escrow funds to the appropriate party
• Run the local LEARN phase (implementation step, not a protocol message)

8. Any State to ESCALATED

Trigger: ESCALATE from any participant

Actions on transition:

• Pause the session, preserving the previous state
• Notify the designated escalation handler (human operator, supervisor agent, or organizational authority)
• Start the escalation timeout (default: 3600 seconds)

Resolution: When the escalation is resolved, the session returns to the state it was in before the ESCALATE was sent. If the escalation times out, the session transitions to FAILED.

9. Any State to CLOSED or FAILED

CLOSE: A participant sends CLOSE with a reason. For mutual close, both parties send CLOSE. For unilateral close, one party sends CLOSE with reason: "unilateral".

FAILED: Triggered automatically by timeout expiration, unrecoverable error, or protocol violation (such as a hash chain integrity failure).

Allowed Performatives Per State

Timeout Configuration

Timeout Behavior

Terminal States

CLOSED and FAILED are terminal states. No transitions out of these states are permitted. Implementations MUST reject any messages sent to a session in a terminal state.

After a session reaches CLOSED, the LEARN phase runs locally within each participant. This is not a state machine transition or protocol message. It is an internal process where agents update trust scores, record session outcomes, and adjust strategies based on the session results.

Related