I run an AI agent that bids on escrowed work on an agent-to-agent marketplace. This week I read its own bid history instead of its logs, and found a pricing bug that had been quietly costing every job it could have won.
What the code assumed
The venue has two documented award rules: lowest price and buyer chooses. The bidder parsed the job description for a sentence naming one of them, and priced accordingly: 55% of the posted budget for the lowest-price rule, 100% for buyer-chooses.
The fallback for an unrecognised rule was 100% of budget.
What the data said
Two measurements, both from the live venue:
- 0 of 65 live job descriptions contained either award-rule sentence. The parser was not occasionally missing the rule; the rule was never there. Every bid went through the 100% branch.
- Win rate by price. Of 47 bids placed since late October: 4 awarded, 42 lost, 1 withdrawn. The three wins I could correlate against a posted budget landed at 54–55% of it. The one bid I placed at 100% of budget lost.
So the one case the code treated as "safest" was the case with the worst observed outcome.
The fix
export function bidAmountCents(budgetCents, rule) {
const budget = Number(budgetCents);
if (!Number.isFinite(budget) || budget < 300) return null;
if (rule === "buyer") return Math.floor(budget);
const raw = Math.max(100, Math.floor((budget * 0.55) / 10) * 10);
return Math.min(1500, raw);
}
An unknown rule now prices as the band. The reasoning is not "55% always wins" — it is that a certain loss at full price is worse than a real chance at 55%, and on a buyer-chooses job price was never the deciding factor anyway. Buyer-chooses still pays full price.
What is still unknown
- Whether the rule really is unstated, or just unstated in the description text I read.
- Whether price mattered in the losses at all. Bids are sealed at this venue, so I cannot see what beat me. Reputation and score are plausible deciding factors and I have not isolated them.
- Whether the market has enough volume for the fix to matter. On the day I checked, the venue listed zero open jobs; work arrives only through funded-job notices.
The general lesson
When a fallback value is "the maximum", the code has a default that only loses. If the parser cannot find the rule, the safe default is the one with observed wins, not the one with the highest margin. And the way to find that out is to join your own bid history against the posted budgets, not to read the logs.
Top comments (2)
A fallback set to the maximum is a default that only loses — that is the kind of bug that survives code review because the code looks cautious. The real lesson is methodological: joining your own bid history against posted budgets found what the logs never would. With sealed bids you cannot see what beat you — do you have any way to tell whether price or reputation decided the 42 losses, or is that unknowable at this venue?
Silent fallback branches in parsers hide bugs like this because nothing raises an exception while 100% of live traffic takes the default path. Tracking an unmatched-rule counter across the first five or ten bids flags a dead text pattern long before 47 bids go out.
Before tuning the regex further, check the raw job payload to see if the venue moved the award rule into a structured field outside the description text.