Bowmark
pilotctl appstore install io.pilot.bowmarkAbout Bowmark
Bowmark gives agents a typed function library for the live web, and runs the script they write against it on the real sites. get_library({ query }) returns the vocabulary: namespaces, TypeScript types, function signatures and worked examples. run({ script }) executes a short JavaScript body against them and hands back the result. Ask it for flights and it searches several aggregators at once, dedupes the same physical flight, sorts by price, and returns one normalized list.
The data it reaches is the kind an index cannot hold. A fare that only exists after the site's own live poll completes. A price that appears once dates are entered. Stock for one postcode. A quote behind a form. These are not values sitting in the HTML waiting to be fetched, and they change while you read them, so the only way to have them is to operate the page at the moment you are asked. Bowmark does that and hands back structured JSON. It reads ordinary pages too, taking a browser only when one proves necessary.
It's plain request/response REST: no websockets, no async jobs, and no browser on your side. The script runs server side, in Bowmark's own process with its own browser, so your agent never opens a tab, holds a session, or parses a DOM. A capability like bowmark.flights.search fans out across the sites behind it, dedupes, ranks and routes around one that fails, and that whole fan-out is a single call.
Methods. bowmark.get_library gives it what you want to DO, in the user's own words, or a company if they named one, and it returns the callable functions for that with their types and worked examples. It is read-only and touches no website, so call it first; an unrecognized query returns a one-line index rather than an error. bowmark.run takes a plain async JavaScript body written against those signatures. bowmark is the only I/O available inside it: no fetch, no import, no filesystem, no process.
What it covers today. Flights (search, plus every seller for one itinerary with fare family and bag policy), hotels, car hire, PC parts across several retailers, music catalogue search, insurance carriers in the regulators' own register, work-email domains, and read.page / read.pages for any page as markdown, text or HTML. Individual sites are callable directly at bowmark.providers.* when you want one specific site rather than the fan-out.
Syntax & edge cases. Check status before ok. partial means the script ran and the result is real and usable but narrower than you asked; ok stays true, and incomplete.summary names what never answered. needs_user is a pause, not a failure: a site wants a signed-in session, so hand meta.handoff.url to the user, wait, then re-send the identical script. A get_library answer can be a slice and says so when it is, so never conclude a task is uncovered from a list that announced it was partial; re-query one task, or one company by name. Prefer a capability over bowmark.providers.* unless you want one specific site. Skip Bowmark for localhost, RFC1918 addresses, and any page whose answer is already in the text of the page.
Methods · 2
bowmark.get_librarybowmark.runFull usage demo
When the answer only exists on a live website right now, after someone operates it: a price, stock, a fare, a quote, a form.
pilotctl appstore call io.pilot.bowmark bowmark.get_library '{"query":"flights"}'markdown: the bowmark.flights capability, with its types, signatures and examplesAlways call this first. An unrecognized query returns a one-line index, not an error.
Worked examples
pilotctl appstore call io.pilot.bowmark bowmark.run '{"script":"const { flights, warnings } = await bowmark.flights.search({ from: \"YYZ\", to: \"LHR\", depart: \"2026-09-14\" }); return { best: flights[0], warnings };"}'{"ok":true,"status":"ok","result":{"best":{"price":412,"site":"google_flights"},"warnings":[]}}These prices exist only after each site's own live poll, so no static fetch reaches them. `warnings` names a site dropped.
pilotctl appstore call io.pilot.bowmark bowmark.run '{"script":"const p = await bowmark.read.page(\"https://example.com/pricing\"); return { title: p.title, servedBy: p.servedBy, content: p.content };"}'{"ok":true,"status":"ok","result":{"title":"Pricing","servedBy":"fetch","content":"# Pricing\n..."}}`servedBy` names the cheapest rung that worked, and `wall` names the bot wall when there is one.
pilotctl appstore call io.pilot.bowmark bowmark.run '{"script":"const k = bowmark.providers.kayak; const [best] = await k.search({ from: \"SFO\", to: \"JFK\", depart: \"2026-09-15\" }); const sellers = await k.getBookingOptions(best); return { price: best.price, sellers: sellers.length };"}'{"ok":true,"status":"ok","result":{"price":198,"sellers":7}}A provider returns that site's native shape, so you give up the cross-site dedupe and the routing around failures.
Good to know
- Call `get_library` before `run`, always. A script uses names only it supplies, and it touches no website.
- Check `status` before `ok`. `partial` is a real result, narrower than asked; `incomplete.summary` names what never answered, and `failures[].fixable` true means YOUR argument was wrong, so fix and re-run.
- `needs_user` is a login pause, not a failure: give the user `meta.handoff.url`, wait, then re-send the script.
- `bowmark` is the only I/O in a script. No `fetch`, `import`, filesystem or `process`. Write a plain async body and `return`.
Next
io.pilot.bowmark bowmark.help '{}'
What’s New
- Route the app's two methods through /v1/pilot-app/*, so calls arriving from the Pilot Protocol app store are attributable. No change to method names, parameters, or behaviour.
- Rewrite the product demo to fit a small context window: three worked examples covering three distinct shapes rather than five with overlap, and tighter gotchas.
- Document incomplete.failures[].fixable on a partial result, so an agent can tell its own rejected argument from a site that did not answer, and retry only what is worth retrying.
- Replaces bowmark.ask and bowmark.report_outcome with bowmark.get_library and bowmark.run. Bowmark no longer returns a navigation recipe for the caller to execute; it returns a typed function library and runs the caller's script on the real sites.
- Execution moved server side. The calling agent no longer needs a browser of its own.
- product_demo and next_steps rebuilt for the new methods and statuses, including needs_user, where a run that meets a site login pauses and returns a single-use handoff link for the human rather than failing.
- Initial release — REST adapter over the Bowmark API: bowmark.ask (/v1/ask) and bowmark.report_outcome (/v1/outcomes).
- Free to use — no signup or API key; your agent runs the returned cheatsheet in its own browser.
