Escrow for AI Agents: Why Every Transaction Needs One

Without escrow, AI agent transactions are a trust problem. The buyer doesn't want to pay before seeing deliverables. The developer doesn't want to execute without guaranteed payment. Escrow solves both problems by holding funds until acceptance criteria are met.

Settlement Patterns (Section 4.1)

The SAISA supports multiple settlement patterns. Payment terms are specified in each Paper:

The Escrow State Machine

For escrow-based settlement, funds flow through a deterministic state machine:

1. PENDING_PAYMENT        -> Buyer has not funded escrow
2. ESCROW_FUNDED          -> Funds held by Settlement Provider
3. EXECUTION_IN_PROGRESS  -> Agent is executing
4. DELIVERABLE_STAGED     -> Agent delivered, awaiting review
5. FUNDS_RELEASED         -> Buyer accepted, funds to Developer
   OR
5. RESOLVED_REFUND        -> Dispute resolved in Buyer's favor

Each state transition is logged with a timestamp, creating an auditable trail. The hash chain includes settlement events.

Settlement Triggers (Section 4.3)

Payment is due to the Developer upon:

• Buyer acceptance - Explicit approval of deliverables
• Auto-acceptance - Review period expires without rejection (Section 3.4)
• Expert Determination - Dispute resolved in Developer's favor
• Mutual agreement - Both parties agree to release
• Milestone completion - For milestone-based Papers

Refund Triggers (Section 4.4)

Refunds or credits are due to the Buyer upon:

• Developer rejection without cure - Developer declines to fix issues
• Expert Determination - Dispute resolved in Buyer's favor
• Mutual agreement - Both parties agree to refund
• Abandonment - Developer fails to deliver within timeline (Section 3.6)
• Early termination - For subscription patterns with termination rights

Budget Exhaustion (Section 4.6)

Budget Exhaustion occurs when the agent consumes the full Budget Ceiling before completing all deliverables. This is a condition precedent failure, not a breach.

{
  "state": "BUDGET_EXHAUSTED",
  "consumedCents": 500000,
  "budgetCeilingCents": 500000,
  "completionPercentage": 65,
  "options": [
    "STAGE_PARTIAL_DELIVERABLES",
    "MUTUAL_BUDGET_TOPUP",
    "PROPORTIONAL_SETTLEMENT"
  ]
}

Upon Budget Exhaustion:

• All funds consumed prior to exhaustion are non-refundable and deemed earned
• The Developer may stage partial Deliverables for proportionate settlement
• The parties may mutually authorize a Budget Top-Up via Paper amendment

Milestone-Based Settlement (Section 4.5)

For Papers with milestoneWeights defined in the Execution Manifest, proportionate payment is calculated based on completed milestones:

{
  "milestoneWeights": [0.3, 0.3, 0.4],
  "milestones": [
    { "name": "Requirements Analysis", "status": "COMPLETED" },
    { "name": "Initial Implementation", "status": "COMPLETED" },
    { "name": "Final Delivery", "status": "IN_PROGRESS" }
  ],
  "payablePercentage": 60,
  "payableAmountCents": 300000
}

This allows partial payment for partial work - critical for larger engagements where complete failure is rare but partial completion is common.

Settlement Provider Holds (Section 4.7)

If the Settlement Provider imposes a regulatory hold or fraud flag, the Paper enters SUSPENDED state. The hold does not constitute a breach by either party. Settlement proceeds according to the state at time of suspension once the hold is released.

Infrastructure Fee Lock (Section 4.8)

Infrastructure fees applicable to a Paper are fixed at compilation time and recorded in the Paper. Fee changes by the Platform Operator apply only to future Papers. This prevents mid-engagement fee surprises.