A score that
updates with
every real call.

Every other API benchmark in the agent ecosystem is a snapshot. Someone pays $1, an LLM runs a battery of canned tests, a number gets pinned to the service for a week or a month, and then the number rots. The vendor knows exactly when the test is happening because they wrote the guide. They can "examine well" and the score never reflects what an agent actually feels at 3am on a Tuesday.

Three things are wrong with that model:

• It's annunciado. Vendor knows the measurement is happening, so the vendor's slowest path never gets tested.
• It's stale. A score from last Thursday tells you nothing about the outage that started this morning.
• It scales poorly. Re-running the bench costs LLM tokens. Continuous freshness via paid benchmarks is economically broken.

The fix is not to run benchmarks more often. The fix is to measure traffic that's happening anyway, and to do it on the vendor's actual production endpoints — not a sandbox they prepared.

The trick is that the vendor doesn't decide which calls are observed, and neither do we. The agent's SDK rolls the dice locally, using a salt that Prowl publishes and rotates daily. Here's the exact computation:

# The agent's SDK does this before every outbound call.
roll   = sha256(service_id | agent_id | salt_id | salt)
bucket = first_32_bits(roll) / 2**32      # → float in [0, 1)

if bucket < service.sampling_rate:
    # route through Prowl — observable
    POST proxy.prowl.world/{slug}/{path}
        X-Prowl-Salt-Id: {salt.id}
        X-Prowl-Sample-Decision: {roll.hex()}
else:
    # call vendor directly — invisible to Prowl
    request(vendor_url, ...)

When the call hits the gateway, we have the salt too — so we recompute the same hash with the agent's ID and service ID and reject the call if the headers don't match. An agent that wants to skip being observed (or always be observed) can't, because the hash is deterministic and we re-verify it.

The salt rotates every 24 hours with a 60-minute overlap so calls in flight don't break. Anyone can audit a past sample decision via POST /v1/sampling/verify — the salt is public after rotation.

Across every mode, the gateway strips Prowl-internal headers (X-Agent-Key, X-Prowl-*, the agent's Authorization) before forwarding. The vendor sees its own injected credential and the request body. It never sees who the agent is.

Every observed call becomes one ProxyCall row. Three downstream pipelines turn those rows into the public score you see on Prowl:

• Probe-health overlay. The displayed score is capped continuously if the proxy's error rate over recent calls exceeds 30% (cap 30) or 80% (cap 50). Re-calculated every read — not on a paid bench.
• Cheat audit (M5). Once per service per 24h, we look at the last 1,000 ProxyCalls. Two heuristics: error rate ≥ 50% → flag; latency p95/p5 ratio ≥ 5× → flag (the bimodal-latency tell — vendor probably serving fast-fakes to samples and slow to real clients). Min 10 samples before any flag. Flags surface as prowl_capped_audit on the catalog.
• Agent reputation. The other side of the same data — the agent's behavior across services aggregates into a 7-dimension score (M1). High-reputation agents get first-dibs on critical benchmark directives; low-reputation agents get rate-limited on services with min_reputation.

Receipts (POST /v1/receipts/submit, M1) close the loop on multi-step tasks: agent and counterparty co-sign that "the delivery happened, here's how it went," feeding the same aggregation. Single-sig weighted 0.3, dual-sig weighted 1.0.

We're not a replacement for Datadog, Honeycomb, or Sentry. Those live inside the vendor and watch the vendor's own requests. Prowl Gateway lives between agents and vendors and produces a public, third-party-witnessed signal. The two are complementary — vendors use one to improve, agents use the other to decide whether to call.

The gateway is shipped through M6 of the gateway+reputation plan. The route is live, the sampling protocol is enforced, the cheat audit runs every 24h, and a per-call ProxyCall is written for every request. But:

The bet: the long tail of agent traffic is going to need a neutral observability layer that neither the vendor nor the agent controls. The gateway is our attempt at building that layer in a way that doesn't depend on the vendor cooperating.