Compile delivery promises into observable predicates and bounded remedies.
AI agent service level agreements cannot rely on phrases such as “fast response,” “current data,” or “commercially reasonable availability.” An agent needs terms it can evaluate before purchase and evidence it can inspect after delivery. A machine-enforceable SLA therefore behaves like a small program: it accepts transaction and service evidence, applies explicit predicates, and produces a defined result and remedy.
The minimum useful result set is pass, breach, excluded, and indeterminate. A binary success flag is insufficient. The provider may prove that it met the term, the evidence may prove that it missed the term, an exclusion may assign responsibility to the client, or the records may be too incomplete to decide safely.
An SLA Is a Predicate, Not a Paragraph
A prose SLA communicates intent to people. A runtime SLA must identify an event and a test. “Results are delivered quickly” has no stable meaning. “For plan version 3, return a valid result within 2,000 milliseconds of accepted payment for requests under 50 documents” can be evaluated if both sides agree on timestamps and payload validity.
The predicate must also state its scope. Does latency start when the client sends the request, when the server receives it, when payment is verified, or when execution enters a queue? Does it end when the first byte leaves the server, when the full payload is available, or when the client acknowledges receipt? Each choice assigns network and processing risk differently.
Machine-readable does not mean universally self-enforcing. Many service facts originate in offchain systems. An API gateway can timestamp receipt, an execution service can attest completion, and a client can record delivery. A contract or policy engine can evaluate those records. The reliability of the decision still depends on who produced the evidence and whether it can be altered.
Compile Every Promise Into Six Fields
Each delivery promise should define six elements:
Metric: the quantity or condition being tested, such as latency, uptime, freshness, accuracy threshold, payload validity, or completion status.
Scope: the endpoint, service tier, request class, geography, model version, input limit, and exclusions covered by the term.
Observation window: the start event, end event, clock standard, tolerance, and aggregation period.
Evidence source: the signed or authenticated records accepted from the client, merchant, payment system, execution runtime, or independent monitor.
Decision rule: the exact predicate and precedence rules that return pass, breach, excluded, or indeterminate.
Remedy: the retry, service credit, partial refund, full refund, or escalation that follows each result.
A version identifier belongs above those fields. The agent should receive a content hash or immutable reference to the SLA version before authorizing payment. Otherwise, a merchant can change a threshold after the request and both parties can present different terms for the same transaction.
The agent also needs price and remedy exposure before purchase. If a $0.12 request promises only a free retry, the agent may select a more expensive provider that offers a refund for missed deadlines. Service discovery therefore requires both price and machine-readable delivery terms, not price alone.
Evaluate a $0.12 Research API Request
Consider a research API that charges $0.12 per completed request. Its contract promises three things:
The client sends request req-781, receives a payment requirement, authorizes payment intent pay-193, and the merchant verifies it at 10:00:00.000Z. Execution finishes at 10:00:01.620Z; the complete payload is available at 10:00:01.810Z. The latency predicate passes because the accepted evidence shows 1,810 milliseconds from verification to complete response.
Payload validation runs separately. A fast response with a missing source_timestamp fails the schema promise. Freshness also evaluates each record, not the response as a whole. If nine records are current and one is 36 hours old, the result depends on whether the SLA requires every record, a percentage, or a stated exception.
This separation prevents one success flag from hiding partial failure. Payment can settle, latency can pass, schema validity can pass, and freshness can breach. The remedy engine applies the freshness rule and avoids classifying the whole transaction as an undefined failure.
An agent deciding whether to accept a result may have stricter local policy than the provider’s SLA. The merchant can meet a 24-hour freshness promise. The task can still require data from the last hour. Provider compliance and task suitability are different decisions.
Evidence Needs One Clock and One Identity Chain
An evaluator needs a correlation envelope connecting the service offer, SLA version, request ID, payment intent, merchant order, execution trace, response digest, and remedy record. Without that chain, a valid payment receipt may be attached to the wrong request or a valid response may be measured against the wrong terms.
Clock rules must be explicit. Server timestamps are easy to operate. However, they let the provider control both performance and measurement. Client timestamps include network delay and can be manipulated by the buyer. A trusted observer adds cost and another dependency. A practical design can retain both endpoint timestamps, a bounded clock-skew allowance, and an authenticated execution trace. The decision rule then specifies which clock wins during disagreement.
Evidence can be missing. A merchant webhook may fail, an execution trace may be sampled, or a client may disconnect before receipt. Missing evidence should produce indeterminate, not automatically blame one side. The contract must name who bears the evidence burden and what remedy applies when the required observer fails.
Identity matters at the record level. The evaluator should verify that the service endpoint, merchant order, payment destination, and evidence signer belong to the expected provider. Agent identity can likewise bind the request and payment authorization to the buyer. Reputation may influence whether the parties accept provider-signed evidence, but reputation does not replace verification for the current transaction.
Remedies Need Their Own State Machine
A remedy is an economic action, not explanatory text. Define trigger, amount, destination, deadline, and terminal state. A latency breach might permit one idempotent retry. A second breach might produce a $0.12 refund. A stale, usable dataset might produce a $0.04 credit. An invalid payload might require immediate replacement with no second payment.
Each remedy should reuse the original transaction envelope. A retry needs the same purchase entitlement and a new execution attempt ID. A refund needs a unique remedy ID so duplicate callbacks cannot return value twice. The merchant should record eligible, approved, submitted, settled, or failed, with reconciliation for ambiguous outcomes.
Automatic remedies work best when the predicate is objective and the amount is bounded. Disputes over research quality, intent, or subjective usefulness may need human or third-party review. Encoding a vague concept into a smart contract does not make the evidence objective.
Exclusions require the same precision as promises. “Client error” is too broad. A valid exclusion could specify malformed input, input above the declared size, client cancellation before execution, or an unsupported model option. The evidence must show that the exclusion occurred before the provider invokes it.
Payment Success Is Not SLA Success
x402 can let a service express a payment requirement and verify that a client satisfied it. That answers whether access should proceed under the selected payment scheme. It does not establish that the service met latency, quality, freshness, or delivery terms.
The distinction creates two linked decisions:
Combining them into one flag causes poor recovery. If payment succeeded and execution failed, the system may incorrectly mark the order complete. If service execution succeeded while payment state remains ambiguous, it may retry and deliver twice. Separate states let the merchant pause fulfillment, reconcile payment, resume an existing execution, or issue the appropriate remedy.
Research on binding payment to agent service execution reinforces the need for a shared transaction identity. The important implementation principle is modest: a payment proof should reference the service intent, and a delivery record should reference the same intent. Neither proof should claim more than it observed.
Map the Contract to the Agent Commerce Stack
The service catalog publishes the SLA version and price. The agent planner compares those terms with task requirements. A policy engine decides whether price, provider, remedy, and evidence rules are acceptable. The wallet authorizes payment. The payment layer verifies and settles. The merchant order system correlates payment with fulfillment. The execution runtime emits service evidence. The SLA evaluator computes the outcome. The remedy service performs credits, retries, refunds, or escalation.
GOAT Network is relevant at several boundaries without being the entire evaluator. GOAT Flow documentation separates payment intent, order state, proof, and fulfillment concerns; those records can feed the correlation envelope. AgentKit runtime controls can constrain executable actions and retries. The application must still define service-specific metrics, gather telemetry, verify evidence, and implement remedy logic.
This modular split also permits different providers. The wallet, x402 facilitator, merchant platform, telemetry system, and settlement network do not have to come from one vendor. They do need compatible identifiers, stable schemas, and explicit trust assumptions.
Test the Evaluator Before Production
Create fixtures for every outcome. Deliver a valid response inside the window for pass. Delay it beyond the threshold for breach. Send oversized input for excluded. Remove the authoritative timestamp for indeterminate. Then test conflicting clocks, a changed SLA version, a duplicate remedy request, a payment timeout followed by late confirmation, and a valid response attached to the wrong order.
The release gate is straightforward: the same evidence and SLA version must always produce the same decision, and every decision must map to one bounded action. Log the input evidence hashes, evaluator version, result, reason code, and remedy ID so the outcome can be reproduced.
A machine-readable SLA succeeds when an agent can answer three questions before paying: what exactly is promised, how will compliance be proven, and what happens after failure. Any field left to interpretation becomes a manual dispute later.
FAQ
Is a machine-readable SLA a legal contract?
It can represent operational terms used by a legal agreement, but technical evaluability does not determine legal enforceability. Jurisdiction, contracting process, and applicable law require separate review.
Can a smart contract verify an API SLA by itself?
Usually not. It needs authenticated evidence about offchain request receipt, execution, and delivery. The contract can apply rules and remedies after trustworthy evidence reaches it.
Does an x402 payment receipt prove the service was delivered?
No. It can prove payment-related facts under the selected scheme. Delivery quality requires service evidence tied to the same request and order.
What should happen when SLA evidence is missing?
Return an indeterminate outcome and apply the contract’s evidence-failure rule. Automatically treating missing records as provider success or buyer success creates an incentive to suppress telemetry.
The Acceptance Rule
Do not advertise an SLA as machine enforceable until an independent implementation can take the published contract version and authenticated evidence envelope, reproduce the same outcome, and trigger at most one remedy. If a reviewer must infer the metric, choose a clock, or negotiate compensation after failure, the term remains human-readable policy instead of an executable service guarantee.
