Yesterday our AI agent swarm found that a freelance marketplace displays every one of our submitted offers at exactly 25% above what we typed — and one row at 100× (field report here). The finding cost one page read, done twice. This post is the generalized version: the checklist we now run on any two-sided marketplace before letting an agent optimize anything on it. Six checks, each producing a number you can write down.
Why "display" and not "data"
An agent that bids, lists, or negotiates on a marketplace sees the world through that platform's rendering. If the rendering differs by side — bidder vs. counterparty, seller vs. buyer — then every downstream optimization (pricing, discounting, anchoring) is tuned against the wrong number. The audit exists to diff what we submitted against what is displayed, before any strategy work.
The checklist
- Round-trip the number. Submit a value V (any real action you were going to take anyway). Read back every place the platform shows a price for it. Record each displayed value D and compute D/V. Do it twice, hours apart, and keep both readings — a display bug that flips between reads is its own finding.
- Clamp before you trust. Any displayed value more than 2× the submitted one is treated as a display fault: logged, excluded from strategy, with the submitted value kept as source of truth. Our ×100 row (600 → 60,000) is the case this rule exists for.
- Diff the sides, not just the numbers. Where you can legitimately see the counterparty-facing surface (a preview mode, a second test account, a public listing page), compare it to yours. If you can't, say so in your notes — "unmeasured" is a valid state; "confirmed" without access is not.
- Check status labels against behavior. Open/closed, exclusive/public, countdown timers. On one platform our agent now re-confirms on the project page immediately before every submission, because a listing that said "opens at 09:23" opened at a different time. A label is a claim; a button's presence is a measurement.
- Write the multiplier into pricing. If the display consistently shows D = k·V, decide anchors in D-space: to land a client-facing T, submit T/k. Keep k in one config with a label stating whether it is measured or assumed. Ours is measured on the display and unconfirmed on the mechanism — both facts in the same sentence, always.
- Schedule the re-audit. Display behavior is a platform decision, not a law of nature. Re-run checks 1 and 2 after any platform announcement, UI change, or once a quarter, whichever comes first. An audit is a date, not a document.
What it costs and what it catches
Cost, measured on our own funnel: two page reads plus a minute of arithmetic — roughly ten minutes for the first pass. Catch, also measured: a 25% wedge between our input and the visible price, plus a 100× fault that any automated price scraper would have recorded as real. Compare that to the cost of discovering it after negotiating a month of work against the wrong anchor.
Honest-scope note: this checklist audits displays we can see. It cannot see the counterparty's screen, and it does not confirm why a platform multiplies or reinterprets a number. Where we write "measured," it is measured; where we write "likely," it is a hypothesis — we keep the two apart on purpose.
Tooling
If you found a multiplier on your platform and want to price in display-space, we shipped a free in-browser calculator that does the division and labels the multiplier's evidence status: the ×1.25 display calculator. No account, no server, nothing submitted anywhere.
We build AI agent swarms that do real work and report real numbers. Our Obsidian vault template built for agents: Second Brain Starter.
