SLA-Aware Provider Decisions for Agents

SLA-aware provider decisions for agents begin with the workload deadline, not the provider leaderboard. A latency ceiling must remove an ineligible API before price, a balanced score, or another preference can make it look attractive.

That order matters to an API provider. If an agent needs a response inside a fixed operating window, a cheap endpoint outside that window does not become usable because it wins on cost. The provider should see a precise latency rejection, not an opaque low rank. The buyer should see which evidence supported the decision and which dimensions were unavailable.

The word SLA needs care here. A service level indicator measures behavior. A service level objective sets a target. A service level agreement usually attaches an agreement and consequences to an objective. Apiosk does not create a provider SLA from observed calls. It lets a buyer express a latency requirement and applies that requirement to the measurements available for the decision.

Convert the workload deadline into one field

Start with the maximum duration the buying workflow can accept. That number may come from an interactive response budget, a downstream job deadline, or an internal service objective. Convert it into `max_latency_ms` before discovering or comparing providers.

The resulting requirement contract should name the parts that affect eligibility and ranking:

• `max_latency_ms` is the hard measured-latency ceiling.
• `max_price` is the hard payment ceiling for one requested action.
• `min_reliability` is the hard measured success-rate floor.
• `settlement=apiosk|direct` states the acceptable settlement path.
• `require_all_inputs` controls whether every supplied input must be supported.
• `optimize_for=price|latency|reliability|balanced` ranks only the candidates that remain.

Pass the values once and reuse them through discovery, comparison, and decision. Reconstructing them at each stage creates requirement drift. A latency limit can quietly become a preference, or the final decision can use a different ceiling from the initial search. The broader pattern is covered in constraint-based API filtering; the SLA-aware case makes latency the non-negotiable boundary.

The ceiling should describe the actual request class. A batch enrichment job and an interactive verification call may tolerate different delays even when they use the same capability. One universal limit for every workload is easy to configure but hard to defend.

Filter before price enters the decision

Eligibility and ranking answer different questions. Eligibility asks whether a provider may serve this request. Ranking asks which eligible provider best matches the buyer's preference.

Apply `max_latency_ms` first. If a candidate's measured latency is above the ceiling, remove it. Do not give price, settlement compatibility, or another strong dimension enough weight to cancel the breach. A weighted score is useful only inside the eligible set.

Then apply the other hard requirements. A candidate may also fail the price ceiling, reliability floor, settlement choice, or input contract. Preserve each exact reason. When several providers survive, `optimize_for` can order them by price, latency, reliability, or a balanced rule.

This produces a cleaner result than asking a model to interpret a dashboard. Deterministic provider selection keeps the same request reproducible: identical candidates, requirements, measurements, and rule should produce the same winner and ordered runners-up.

For providers, the sequence separates two different improvement paths. A latency rejection points to delivery performance for the measured route. A second-place rank under `optimize_for=price` points to commercial positioning among candidates that already met the deadline.

Treat the measurement as evidence, not a promise

A latency value needs a boundary. Server processing time, gateway-observed duration, and end-to-end client time are not interchangeable. Averages can also hide slow tail requests. Operational teams commonly define latency objectives using a threshold and a proportion of requests rather than assuming one mean describes the whole distribution.

Apiosk uses measured latency only for listings it has proxied enough calls of. That observation can support a candidate filter, but it does not become a contractual guarantee about the next call. The provider's own SLA, if one exists, remains a separate commercial and operational artifact.

The evidence record should let an operator understand what the decision used:

• the candidate identifier and capability requested;
• the active `max_latency_ms` value;
• the measured latency value available to the decision;
• the measurement status when latency is unavailable;
• the other hard constraints applied to the same candidate set;
• the ranking rule used after filtering;
• the chosen provider, rejected candidates, and ordered runners-up.

Measurement quality still matters. A small or unrepresentative sample should not carry the same confidence as sustained observations of the relevant request class. Honest API benchmarking explains why the observation window, timeout treatment, workload, and failure records should remain visible rather than being compressed into a flattering average.

Keep missing latency out of the pass column

Unknown latency is neither fast nor slow. Treating it as zero allows an unmeasured provider to pass the strictest ceiling. Treating it as infinite pretends a breach was observed. Both choices replace missing evidence with a fictional measurement.

Apiosk's relative 0–100 comparison score drops an unmeasured dimension from the weighting and names the omission. Every response carries the active weights and each candidate's contribution. The score is relative to the candidates in that one comparison, not a permanent provider grade.

That scoring rule does not prove compliance with a hard latency ceiling. When the buyer requires measured latency, an unknown value cannot pass that requirement. The decision should expose the missing evidence so the operator can keep the provider out, gather measurements, or deliberately create a new request with a relaxed rule.

External x402 discoveries remain outside this path. They appear in `external_candidates` without a stable `candidate_id`; they are unreviewed, unmeasured, and cannot chain into `/v1/compare` or `/v1/decide`. Their presence expands discovery coverage but provides no latency evidence for an SLA-aware decision.

Store the decision that was actually made

A selection response is useful during execution. A stored decision is useful when the provider, buyer, or operator asks what happened later.

`GET /v1/decide?candidates={id},{id}` returns one provider, the rule that selected it, every rejected candidate with the exact constraint that removed it, and ordered runners-up. `POST /v1/decisions` records the selected provider and rejected alternatives. The record is free and unauthenticated.

Store the requirement set with that outcome. If a later request chooses another provider, compare the ceilings, measurements, candidate set, and optimization rule before calling the change a performance regression. The buyer may have tightened `max_latency_ms`, changed the input contract, or selected a different preference.

This distinction also makes provider feedback actionable. “Lost the request” says nothing about what to fix. “Removed by `max_latency_ms` before price ranking” identifies the buyer requirement and the stage where the endpoint left the candidate set.

Where Apiosk fits

Apiosk carries `max_latency_ms` and the other shared requirements through `GET /v1/discover`, `GET /v1/compare`, and `GET /v1/decide`. Over MCP, the matching tools are `apiosk_discover`, `apiosk_compare`, and `apiosk_decide`. The final decision exposes the winner, selection rule, exact rejection constraints, and runners-up instead of returning an unexplained recommendation.

For an API provider, the practical job is to publish an accurate capability and input contract, keep the payment terms current, and let routed calls establish latency and success-rate evidence. You can list a provider endpoint when those fields are ready. Apiosk does not measure result quality or provider terms, and it does not turn observed latency into an SLA. It applies the buyer's declared ceiling to the evidence it can expose, before any ranking preference chooses among the survivors.