Comparison Layer for Agentic Commerce: Neutral Ranking

A comparison layer for agentic commerce answers a question no single API provider can answer: which eligible offer best fits this buyer's declared requirements right now? The provider sells one offer. The comparison layer must evaluate several without changing its method when a different one wins.

That separation is not a branding choice. It determines whether an agent receives evidence it can inspect or a recommendation shaped by the seller that produced it.

Selling an offer and ranking a market are different jobs

An API provider is the authority for its own endpoint. It can publish the capability, required inputs, price unit, response contract, and current payment terms. It can operate the service and correct inaccurate listing data.

It cannot create a market-relative ranking from that position. The provider does not control the schemas, prices, or availability of every alternative. Its internal latency timer does not share a boundary with a competitor's public benchmark. It also has a direct interest in the conclusion.

This is the structural reason API providers cannot compare themselves. The issue is not that every seller is dishonest. The issue is that a seller owns one row of the comparison and benefits from deciding how all rows are scored.

A comparison business has another obligation. It must preserve a common method when the cheapest provider loses, when the fastest provider is input-incompatible, or when the operator's preferred listing ranks second. Its product is the decision surface, not any single offer on it.

A neutral layer owns the common data model

Side-by-side cards are not yet a comparison. Candidate facts need equivalent meanings before ranking begins.

The layer has to normalize enough information for the offers to become substitutable:

• The capability each endpoint performs.
• The unit attached to one price.
• The buyer inputs each provider requires.
• The mapping from shared inputs to provider-specific fields.
• The observation boundary for latency and successful calls.
• The settlement requirement returned by the live gateway.
• The dimensions that remain unmeasured for each candidate.

Without that work, a low number per call can sit beside a low number per record and appear cheaper. A field called `company` can sit beside `domain` and appear compatible. An internal server timer can sit beside an end-to-end observation and appear faster.

Normalizing API pricing units and mapping input compatibility are therefore core comparison operations. They are not presentation cleanup. They determine whether two candidates belong in the same decision at all.

Eligibility comes before ranking

An agent does not need the universally best provider. It needs a provider that survives the requirements of one purchase.

Price ceilings, latency ceilings, reliability floors, settlement choice, and required inputs should be applied before a score is allowed to decide anything. A candidate that cannot accept the input is not a weaker version of an eligible candidate. It is ineligible for this request.

This distinction protects providers as well as buyers. A specialist endpoint should not receive a poor score merely because it does not support an unrelated input shape. It should be excluded with the exact constraint that failed. The provider can then decide whether to change its listing, extend its schema, or accept that the request is outside its offer.

Good constraint-based API filtering turns a lost call into an explainable result. A single opaque rank turns the same outcome into guesswork.

A score must travel with its arithmetic

Once the eligible set is known, the comparison can rank it. The 0–100 number is useful only inside that candidate set and only with the method attached.

For each result, the buyer needs the weights and each candidate's contribution per dimension. That makes the score recomputable. A buyer optimizing for latency can inspect how a different weighting changes the order instead of accepting a permanent grade assigned by the marketplace.

Missing observations require equal care. If latency or success rate has not been measured for a candidate, the layer should drop that dimension from the weighting and name the omission. Scoring missing data as zero would convert the comparison layer's incomplete evidence into a penalty against the provider.

The boundary must remain explicit. Price, settlement compatibility, and input compatibility can participate in the comparison. Latency and success rate can participate where enough proxied calls have produced measurements. Result quality and provider terms are not measured by Apiosk, so the score must not imply that they are.

Separation changes the commercial incentive

The provider earns revenue when its endpoint is called. A neutral comparison layer earns trust when its method produces a defensible result, including when any particular provider loses.

Those incentives create different product work. The provider improves delivery, documentation, and the offer. The comparison layer improves normalization, observation consistency, constraint handling, and explanation. Combining both roles gives the operator a reason to hide an exclusion, favor a house listing, or choose weights that make its inventory look stronger.

Operational separation does not require pretending the layer has no business model. It requires that buyers can see the decision inputs and reproduce the logic. The candidate set, requirements, weights, contributions, missing dimensions, and rejection reasons should make preferential treatment detectable.

That is a more useful standard than a generic claim of independence. Buyers can audit a response. They cannot audit a slogan.

What an API provider should prepare

Providers do not need to build their own ranking engine. They need to publish an offer that an independent engine can interpret correctly.

Start with a precise capability and a stable input contract. State what one paid request returns. Keep the price unit and payment terms aligned with the live gateway. Supply examples that match production behavior. Allow proxied traffic to accumulate comparable latency and success observations.

Then inspect why the offer was included, excluded, or ranked below another candidate. A clear rejection can reveal a missing input mapping or a price above the buyer's ceiling. A named measurement gap can show why a reliability requirement could not be satisfied. Neither result guarantees traffic, but both are more actionable than a placement in a static directory.

If you want agent buyers to evaluate the endpoint, publish the provider listing with facts the comparison layer can verify. Do not manufacture a self-score. Make the offer legible enough to compete under shared rules.

Where Apiosk fits

Apiosk separates discovery, comparison, and decision. `GET /v1/discover?q=…` returns reviewed candidates with stable `candidate_id` values. `GET /v1/compare?candidates={id},{id}` places price, measured latency, measured success rate, and input compatibility side by side. `GET /v1/decide?candidates={id},{id}` returns one provider, the rule that selected it, rejected candidates with exact constraints, and ordered runners-up.

Requirements including `max_price`, `max_latency_ms`, `min_reliability`, `settlement`, `require_all_inputs`, and `optimize_for` pass through the chain. The comparison score is relative to that request and arrives with weights and per-dimension contributions. Unmeasured dimensions are dropped and named.

External x402 discoveries remain in a separate `external_candidates` block. They are unreviewed, unmeasured, and do not receive a `candidate_id`, so they cannot enter comparison, decision, or settlement. That boundary keeps discovery breadth from weakening comparison evidence.

Apiosk is the ranking layer, not the seller of any one endpoint. Providers supply offers. Agents supply requirements. The response exposes how one became the decision.