Treasure Hunter started with a practical question: could an agent scan local marketplaces, estimate resale value, and leave behind enough evidence for me to judge every result myself?
The last clause became the real project. Finding listings is easy to demonstrate. Producing a trustworthy decision surface is harder. A useful system has to preserve what it saw, distinguish observations from estimates, expose uncertainty, and remain inspectable after an automated run stops.
I built Treasure Hunter as a local, chat-operated proof of concept with a CLI and a live dashboard. It looks for possible Facebook Marketplace and Craigslist resale candidates. It does not message sellers, buy items, prove demand, or guarantee profit. Its job is narrower: collect bounded evidence, attempt a quick valuation for every item, and make the reasoning visible.
The architecture follows the decision
The flow begins in chat or the CLI. A request defines the sources, location, query, and item limit. Marketplace discovery then runs in dedicated browser profiles rather than my personal browser session. Each collected listing enters a quick valuation pass, including items that look unpromising or have incomplete identities.
Those results are stored as immutable appraisal records and job checkpoints in MongoDB. The dashboard projects that history into a ranked view with the asking price, estimated resale range, confidence, evidence, unknowns, appraisal ID, and any access blocker.
The implementation is split along those boundaries. hunt.ts coordinates collection and valuation. runtime.ts runs the model work within an explicit local process. live-results.ts turns persisted records into the dashboard’s rows and ranking explanation.
That separation matters. The dashboard is not a transient narration of what the agent thinks it did. It is a view over durable records.
Evidence has types
A price-shaped number can mean several different things. Treasure Hunter separates asking, sold, inferred, and reference evidence because collapsing them would create false certainty.
An asking price is a seller’s current request, not proof of market value. A confirmed sale is stronger transaction evidence, though its date, geography, condition, and channel can still make it a poor comparison. Reference evidence—such as retail pricing or a related product—can anchor an estimate without establishing local used value. An inferred resale range is the model’s conclusion from those inputs, not an observed sale.
When identity, condition, cost, or comparison quality is missing, the value remains unknown. Uncertainty is not zero. A mixed plant listing, for example, should not acquire a zero-dollar resale value merely because the available description cannot support a defensible estimate.
The same discipline applies to confidence. A low-confidence estimate can still be useful if the interface keeps it visibly separate from observed facts. Refusing to estimate everything would make the system inert; disguising a guess as a comparable would make it misleading. The useful middle is a labelled estimate with its evidence and unknowns attached.
Discount is not ROI
The dashboard also keeps discount distinct from return on investment. Discount answers how far the asking price sits below an estimated resale value: 1 - ask / resale. ROI answers how estimated profit compares with the purchase price after known costs.
Those measures can diverge. A large discount does not account for parts, fees, transport, storage, or labor. Treasure Hunter’s opportunity score uses conservative cash profit, ROI, and estimated sellability, then prints the scoring basis beside the result. If required costs are unknown, the item can remain unrated. The rank is a transparent heuristic, not a trained prediction or a promise that an item will sell.
The failure was optimizing too early
The first serious design failure was straightforward: deep research starved valuation coverage. An early version screened listings and spent expensive research effort on a small subset. The harness could look sophisticated while most collected items never received the basic output the user had requested.
I corrected the default flow to value every item briefly. Automatic hunts no longer promote candidates into deep research. A blocked source records its access problem without suppressing independent work on another source. Partial results are persisted as they arrive.
This changed the product from a selective research demo into a volume-first decision tool. Depth remains available as an explicit later choice, but breadth is now the default contract.
Stop and resume are part of correctness
Agent runs encounter browser logins, rate limits, model failures, and ordinary interruption. Treasure Hunter treats those conditions as state transitions rather than reasons to discard the run.
A stop request is durable. Resume continues from saved listing, screening, and valuation checkpoints instead of inventing a fresh run. Each job is bounded by its recorded configuration, and listings and appraisals keep stable identifiers. This makes state reproducible enough to inspect: I can see what was requested, what completed, what remains pending, and which appraisal revision supports a row.
The immutable record model also prevents enrichment from silently rewriting history. New notes or evidence become a new appraisal revision. The dashboard can select the current revision while the earlier basis remains available.
What the real runs actually proved
The October 18 volume pilot covered exactly six real listings: three from Facebook Marketplace and three from Craigslist. It stored six appraisals, five numeric resale estimates, and 25 evidence entries. One listing stayed unknown because its identity and item-level pricing were insufficient.
That run validated the integration path across both sources and the value-every-item correction. It did not validate throughput, profitability, or demand. It was not a 100-item benchmark, and there were no recorded Treasure Hunter sales in the reviewed dataset. The candidate rankings therefore remain hypotheses to inspect, not outcomes.
A subsequent volume run extended this to 114 distinct listings: 60 Craigslist and 54 Facebook. All 114 had saved appraisals; 113 had numeric resale ranges. I rechecked those persisted results for this article. Facebook remained partial because its radius setting reset to 40 miles, making the final requested filter unverifiable. Stopping was the correct result.
The larger sample exposed the next limitation: evidence quality. It contained 450 evidence entries, not 450 independent comparisons. Confidence was low for 100 appraisals and medium for 14. Review corrected placeholder prices, per-item versus bundle comparisons, and a currency mismatch; some model classifications still warranted further scrutiny. With no recorded sales, the result demonstrates coverage and inspectability rather than validated returns.
Historical records can improve later work without becoming “learning” in the machine-learning sense. Treasure Hunter may reuse a fresh appraisal for the same unchanged listing under a deterministic policy, or supply older records as dated context. That is traceable retrieval with freshness rules—not reinforcement learning, model training, or evidence that the agent gets profitable through experience.
Two ways to inspect it
The hosted demo uses synthetic data so the interface can be explored without marketplace accounts or a local database. A live hunt is deliberately local: it requires Node.js, Chrome, a signed-in Codex subscription, and MongoDB. Authentication checkpoints still require a person; the system does not copy personal cookies or bypass access controls.
That boundary is part of showing the work. The goal is an agent whose collection, estimates, interruptions, and limits remain visible enough for a person to make the next decision.
Explore the source repository, inspect the pilot record, or open the synthetic-data demo.
