Agents for Humans: A $1,500 Lead Meets HTTP 410

A saved September 11, 2026 marketplace capture contains a $1,500 opportunity with zero listed claimers and zero people marked as trying it. Those are attractive discovery signals for an independent developer. They are not enough to justify implementation work.

The canonical verification result in that same record is state: unverifiable, verified: false, reason: GitHub HTTP 410. The important observation is the disagreement between an advertised opportunity and its canonical source. A single dated HTTP response is not proof of fraud, permanent nonpayment, or today's state of the underlying repository.

The repository keeps this record in data/audit-2026-09-11.json rather than retaining only a screenshot of an attractive headline. It records the advertised dollar amount, the canonical URL, the claim counts, and the verification failure. The capture is a historical artifact; rerunning a public API request later can produce a different result.

A source-first workflow should retain at least four independent facts: what the marketplace advertised, which canonical resource it pointed to, when verification happened, and what the canonical request returned. Combining those into an unsupported label such as “guaranteed reward” would destroy the distinction that makes the audit useful.

RewardRadar implements Scout, Verifier, Risk Analyst, and ROI Ranker as a Strands GraphBuilder pipeline. The architecture gives discovery and verification different tool responsibilities. The repository also includes independent standard-library capture scripts for obtaining and preserving live evidence. The historical HTTP 410 observation came from evidence capture; it is not presented as a completed Bedrock reasoning run.

In the intended source-first flow, Scout finds the advertised row. Verifier checks the canonical resource and retains the failure. Risk Analyst explains that source integrity and acceptance cannot be established from the listing alone. ROI Ranker applies policy to that verified state rather than treating the headline as a reason to start coding.

The credential-free demo exercises this actual Strands graph through a deterministic adapter with prescribed fixture tool calls. A hosted model can be injected through the separate runner, but no completed Bedrock invocation or AgentCore deployment is claimed. The public dashboard is a saved evidence replay, not live verification.

The scoring module treats a non-open status as zero payment probability for ordinary finite inputs. That is a conservative action policy: do not recommend spending implementation time on an unverified task. It is not a statistical finding that every unavailable page can never lead to legitimate paid work.

The useful next action is to obtain valid canonical evidence, not to guess the missing issue's requirements or publish a speculative patch for work that cannot be verified. If the source is restored or an organizer supplies a legitimate replacement, the evidence can be refreshed and the decision reconsidered. Old records should remain dated rather than being silently overwritten.

Even a valid open issue answers only one question: whether that canonical item is open at observation time. It does not establish escrow, exclusive assignment, an enforceable acceptance criterion, regional payment compatibility, or a sponsor's willingness to choose this contributor.

RewardRadar therefore represents escrowed, sponsor_verified, acceptance_clear, and payout_rail_ready separately. Missing evidence should not be upgraded to true because the amount is large or because an agent can produce code quickly. The scoring weights remain disclosed heuristics, and expected value remains different from received money.

This case suggests a practical acceptance criterion for future adapters: retain canonical failures and prevent an unverifiable row from being ranked as an actionable opportunity merely because its advertised amount is high. Add fixtures for HTTP failures, malformed URLs, closed items, and restored sources. Check the reason and timestamp as well as the final verdict.

Testing the rejection path is especially useful in an agent system. A fluent explanation is not evidence that a source was checked. Keeping the capture, tool output, policy, and user-facing explanation separate makes failures easier to diagnose and prevents a nice-looking demo from hiding a weak assumption.

To collect a fresh snapshot, follow the repository setup instructions and run python scripts/capture-live-audit.py data/audit-latest.json. This makes real public-network requests and writes a new dated result. It does not reproduce September 11's external state, require a phone call, or establish a payment entitlement.