RoomScout

While building Jumper, I kept coming back to the step before booking: finding a room in the first place. Listings are scattered across classifieds, forums and individual studio websites. I wanted a band to explain what it needs once, then have someone do the searching and chasing. RoomScout is my attempt at that.

What the Scout does

You tell the Scout your budget, preferred days, band size and equipment needs. It works through listings, asks providers about the missing details and follows up. You can review its messages before they go out or allow it to handle inquiries on autopilot. Bookings, payments and contractual commitments still need a person.

I initially put an approval step in front of almost everything. In my own trials, I kept approving the messages, and checking the agent was becoming another task. That led me to make autopilot more prominent. Those trials helped with the product decision; they were not enough to establish how reliably the agent would behave.

How it works

Firecrawl brings public listings into Convex, where I keep their sources and remove duplicates. Each band gets an AgentMail inbox for the conversation with providers. Contact details are available to the Scout but kept out of the public directory. It remembers the band's requirements separately from things it has learned during the search.

For the browser workflow, I built a separate room-listing portal. The Scout registers through its UI, reads a verification code from its inbox, sends an inquiry and checks for replies. That lets me exercise the full flow without contacting a real landlord. Authorisation is checked again immediately before a message is submitted.

What was hard

Structured Outputs came back as loose JSON no matter which schema I sent. The provider adapter behind the Convex AI Gateway did not advertise a supportsStructuredOutputs flag, so the AI SDK quietly dropped the JSON Schema and downgraded the request to plain JSON mode. A minimal reproduction pinned it to that one missing flag. A small local patch to the adapter restored strict schema parsing, and after I posted the finding in the Convex Discord it was fixed upstream.

The official Firecrawl Convex component could crawl and scrape, but it could not drive a browser. I vendored it as a local fork, kept its API, its tests and its MIT licence intact, and added Interact and Native Monitoring, so browser registration, verification and messaging run through the same component as public-web discovery.

The first browser implementation made a remote call for nearly every small step. I grouped the work into four phases: open, prepare, send and close. Keeping prepare and send separate matters: the permission check still runs immediately before submission, even if permission changed while the browser was filling in the form.

Where it stands

I built the first version in a week at the end of August and kept working on it through September. The app runs on Convex hosting; roomscout.dev is the separate test portal.

After the first week I worked on the part the prototype could not prove: whether the Scout could follow a lead through registration, an authorised inquiry and a reply. The controlled test portal now lets me exercise that flow.

By 21 September the index held 496 rooms with their sources attached, and I submitted the project to the hackathon. The demo uses simulated providers on my test portal. Turnstile blocked automated signup in the browser tests, so I disabled it there; signup on a third-party portal protected by a CAPTCHA is still an open problem.

The permission checks have deterministic tests. Evalite is also in the repository, but I have not yet used it to carry out a systematic evaluation of the Scout. So far, my assessment of its behaviour comes from trying the flows myself.