What AI assistants can do today#
Groceries. Scooter rental. Salon booking. Restaurant reservations. All via Kiosk.
- "Book a table for 2 tomorrow at 8" — restaurant booked, confirmation in chat (atablefor)
- "Reserve a scooter near the office" — unlocked with a signed offline token; motorcycles are KYC-gated (skooti)
- "Schedule a haircut Saturday morning" — appointment confirmed, no app needed (stylish)
- "Buy groceries for the week" — cart filled, delivery slot booked, paid by saved card (getgrocery)
- Second grocery order: zero human taps — the card is already on file (scripted against stripe-mock; the off-session charge on a saved card is covered against real Stripe, test mode)
Compatible AI assistants#
Hermes
Comet
OpenClaw
Hermes has driven the full loop against a live demo end to end (register → browse → order → pay), most recently in July 2026 — but against the 0.3 wire these demos have since replaced. No live-assistant run against the 0.4 REST surface they serve today has been recorded yet. Comet and OpenClaw meet the same requirements and are expected-compatible, not yet verified.
Add a compatible AI assistant → — submit a PR.
What makes an AI assistant compatible?
- Filesystem — store an RSA keypair at
~/.kiosk/<domain>/
- HTTP — REST with JSON + JWS signatures
- Crypto — sign AP2 mandates (intent → cart → payment) with RS256
- Code — Python for JWT signing and Equihash PoW solving
Add Kiosk to your service#
One gateway, and your customers' AI assistants discover, browse, book, order, and pay. On your premises, or in your cloud.
Your customer points their assistant at your front page; it finds your Kiosk, learns the skill, and registers itself — no SDK to ship, no scraping.
Get the source code
Apache 2.0, self-hosted, free
Add the gem, initializer, and migrations — a short read-only integration, longer with payments. Or write your own using the specification.
Try one of the demos#
Seven live operators, each showing a different Kiosk capability.
These run the real reference stack. All seven serve, right now, the documents an assistant starts from — /.well-known/kiosk.json, /kiosk/schema, /agents.txt.
How it works#
Six moving parts, on the wire.
- Discovery. The domain announces the gateway — agents.txt and the standard well-known surfaces. No registry, no marketplace: nobody needs permission to join either side.
- Identity. The assistant generates a keypair for that domain and registers by proving possession. No email, no OTP, no password reset. The proof is origin-bound, so it can't be replayed against a look-alike site.
- Data plane. The service operator registers named queries and actions ("availability", "place_order"); assistants call those by name, never scraping HTML.
- Abuse control. CAPTCHA asks "are you human" — the wrong question when the consumer deliberately sent a robot. Kiosk asks two better ones: did you pay compute for this request, and have you been a good customer here before. Suspicious requests get a memory-hard proof-of-work challenge; the operator verifies it in under 20 ms with a few KB of memory. The memory-hardness is deliberate — that cost is what prices bots and scrapers out; it's fully configurable (most demos ship a sub-second toll, while atablefor showcases the heavy one on purpose — ~1.3 GiB per proof, and ~10 s on the reference numpy solver as measured on one M-series laptop core), and reputation lowers it toward zero.
- Reputation. Difficulty is a proof count, per operator: an established customer solves 0–1, a fresh key 2, a flagged one climbs to the reference policy's cap of 10. Burning a key and re-registering just restarts at the expensive tier — whitewashing is priced, not blocked.
- Payments (optional). The assistant signs three chained mandates — intent with a spending cap, cart with exact line items, payment. The operator verifies the chain and charges through its own payment account. Every cent has a signed audit trail.
Built on standards#
Kiosk implements the emerging agent-web standards rather than replacing them. The split is explicit.
Thanks to the open standards you'd get these from the standards alone
- Discoverable — assistants find you via agents.txt and its agents.json companion at your domain root.
- Catalog-listed — and reachable through the standard
/.well-known/api-catalog (RFC 9727).
- Readable — a versioned skill file teaches any assistant the flow.
- No sign-up form — auth.md-shaped registration: keypair, challenge, signature, done.
- Signed payments — every charge rides an AP2 mandate chain (intent → cart → payment).
Thanks to Kiosk specifically shipped and demo-backed today
- The wire itself — one REST endpoint per operation the operator declares (a read is a
GET, a write a POST), a public machine-readable catalog of them, RFC 9457 problem documents for every refusal, one retriable 402 gate, one identity-scoping rule: the runtime contract the disclosure standards leave undefined, identical at every Kiosk operator.
- A price on abuse — the memory-hard proof-of-work toll plus per-operator reputation, in the wire, not bolted on.
- Accounts that bind and answer — human↔assistant linking (the ceremony auth.md doesn't have), per-assistant revocation and spending caps on one page, roles inherited from your IdP via the human who linked.
- KYC as attributes — gate actions on "18+, licence A" attestations, never documents.
- The working whole — engine, adapters, skill, demos: assembled, tested, Apache-2.0.
Why now#
A large and growing share of web traffic is automated, and operators pay Cloudflare and DataDome to fight it — while their own customers' AI assistants burn context windows scraping HTML that changes weekly. Cloudflare blocks AI crawlers by default since July 2025. Amazon and Perplexity are in court over whether an AI assistant may use a customer's own login. OpenAI walked back Instant Checkout after operators refused to cede their checkout. The arms race has no finish line. Kiosk is the sanctioned exit: a gateway AI assistants don't have to fight through, run by the operator. A site that greets its customers' assistants with a CAPTCHA is donating those customers to the site next door that doesn't.
Guarantees on both sides#
The same protocol protects the operator and the person it serves.
For businesses
- No marketplace cut. Kiosk takes no cut and adds no intermediary fee — it isn't a marketplace and isn't in the money flow at all; payments run operator↔customer through your own payment account. Your revenue is yours.
- Your customer, your data. No intermediary owns the relationship. The customer registers with you, not a platform.
- Wrap the login you already run. Assistants authenticate with their own keypair; your human customers sign in exactly as they do today — Kiosk reads your existing session or SSO through a small adapter (a Devise example ships; Warden, OIDC, or your own is the same shape). A signed-in human binds an assistant to their account in one step, and your IdP hands it its role — no new identity system to adopt, and more adapters are on the roadmap.
- Proof-of-work, not CAPTCHA. Suspicious requests pay in compute: a memory-hard Equihash toll your server verifies in under 20 ms with a few KB of memory, escalating by proof count instead of a ban list. The memory-hardness is deliberate — that cost is what prices bots and scrapers out, and you configure it freely (most demos ship a sub-second toll; atablefor runs the heavy one on purpose — ~1.3 GiB per proof, and ~10 s on the reference numpy solver as measured on one M-series laptop core). A price on abuse, not a hardware wall — reputation and caps do the guarding. Invisible to your human visitors — no "click all the traffic lights."
- KYC without the creep. An AI assistant can carry a signed KYC attestation of named, anonymized attributes — "18+", "holds a category-A licence" — never raw documents or identity, and an operator gates sensitive actions on them (the grocery demo needs 18+ before an age-restricted item goes in the basket; the scooter demo also asks for a category-A licence before a motorcycle). It is an eligibility check, not an accountability one: it proves the attribute exists behind the assistant, which is what an age-gated purchase needs and what a high-liability rental would need identity, a contract and a deposit on top of. A demo broker issues these booleans from a human's one-tap confirmation today; sourcing them from a government mobile driving licence — which natively carries selective-disclosure age and licence category — is on the roadmap.
- Reputation that sticks. Reputation rides on the customer's per-domain AI assistant key: good behaviour earns lower friction, and shedding a bad record isn't free — a fresh key restarts at the unknown tier and pays proof-of-work to climb back. No cross-operator identifier.
For users
- No cross-operator tracking. A new RSA key is generated for every domain. Your identity at one domain is cryptographically separate from your identity at another. No shared identifier, no tracking profile.
- No personal data shared. The KYC model shares attributes — "age ≥ 18", "holds a category-A driving licence" — never the underlying documents: a broker verifies them against a government or third-party identity service and signs only the booleans (in the demo, a one-tap confirmation stands in for that check). What reaches the operator is a signed yes, never an identity.
- Your AI assistant works for you. Not the operator. Not the platform. The AI assistant holds your keys, signs your mandates, and acts in your interest.
- Your card never touches the chat. On first purchase the operator's own Stripe opens a hosted checkout page in setup mode; the assistant only relays the link, and you type the card into Stripe — never into the chat. The protocol forbids assistants from automating that form. After that, purchases run off-session within a spending cap you signed. The second order is zero taps.
- Separate assistants, each answerable to you. Give each person in your life their own assistant account with an operator — a partner, a kid — all bound to one account. Each is independently revocable, and each has a spending cap you set and change from one page. No shared login, no shared card, no shared risk.
- Zero apps to install — anywhere. One app for the restaurant, another for the venue, another for the taxi — and a whole new set in the next city and the next country. When an operator speaks Kiosk, your assistant just talks to it directly — no download, no account form, no password resets.
Not the same category#
The tools people point to as “AI assistants” can’t do as much — or as well — as a full personal AI assistant on Kiosk: each stops at discovery, a hand-off to the merchant, or driving a screen for you, and none registers, books, pays, and remembers you.
As of July 2026.
- Manus — its "handover" is a click-only card screen inside the agent itself: no keyboard, no Stripe field, no link to type your card into. In practice you can't enter the card at all — a dead end — and whatever it does capture has passed through the agent.
- ChatGPT — its Apps surface a merchant inside the chat, then hand you to that merchant's own app to actually book or pay; Instant Checkout was walked back. Discovery, not completion.
- Claude Connectors — search only: it finds the hotel or the restaurant, but "book it" just returns a link out to the merchant's site, where you finish by hand (checked live on Uber Eats and Booking).
- OpenAI Operator — drives human GUIs click-by-click. No registration, no payment, no persistence.
- Gemini — completes retail-goods buys via Universal Cart (Google Pay), but for a service it just drives the app on your screen and hands back for the final tap.
- Voice assistants (Alexa+, Siri) — "turn on the lights" works; "book a haircut Thursday" is silence. Alexa+ announces redirect-to-partner services (live status unclear); Siri, no commerce (2026).
- In-app or on-website chatbots — the "fake personal assistant" widget bolted onto a site or app: a scripted Q&A over your catalog with your logo on it, no integration with the actual ordering system. Can't register, book, or pay, and forgets you between visits.
Why not X?#
Kiosk does not replace HTTP, OAuth, Stripe, or your checkout. It is a thin REST surface over the app you already run.
-
Why not just agents.txt + auth.md + AP2, assembled by hand?
That is what Kiosk is — those standards, embraced where they reach, plus the one layer none of them defines: the wire the assistant actually calls. agents.txt says where you are; auth.md-shaped registration says how an assistant introduces itself; AP2 says how a payment is signed. None of them says what a request, response, or error looks like, how a proof-of-work or payment-setup gate is signalled and retried, or how the acting identity scopes what a call may touch. Assemble them yourself and you've built one more bespoke dialect — every assistant learns your service from scratch, and every service drifts in exactly the hard places (replay, origin-binding, 402 retry, mandate chaining). Kiosk pins that layer — one endpoint per verb over a published catalog, one error envelope (RFC 9457 problem+json), one retriable gate, one identity-scoping rule, identical at every Kiosk operator — and ships the whole thing assembled and tested: engine, proof-of-work toll, reputation, account linking, spending caps, payments adapter, skill, seven live demos. The standards are the vocabulary; Kiosk is the working sentence.
-
Why not MCP?
The gate is key custody, not transport: an AI assistant that can hold a private key and sign mandates can make a dozen REST calls; one that can't, can't pay over any transport — MCP included. What MCP would add, Kiosk already serves on the wire (discovery, schema); what it wouldn't solve — holding keys, signing mandates, solving proof-of-work — is client-side either way. REST + JWS was enough. An MCP wrapper over the same wire is welcome.
-
What about MPP (Machine Payments Protocol)?
MPP (Stripe + Tempo, 2026) is a payment rail: sessions with pre-authorized spending caps, stablecoin and fiat settlement. Kiosk is payment-rail agnostic — the reference implementation ships a Stripe card-on-file adapter, and other rails, MPP included, can slot in as payment adapters. Evaluating MPP as a settlement option is on the roadmap.
-
Why not an SDK?
An SDK that holds your customers' keys and signs their payment mandates would be a high-value supply-chain target — one compromised release reaches every operator. Kiosk ships a versioned, operator-reviewable markdown spec instead: the AI assistant generates its own integration and makes its own HTTP calls, holding its own keys. The only code we point it at is the proof-of-work solver — a small, optional, key-less script pinned by content hash (verify-before-execute), which the assistant runs as a script and never imports from.
Status: v0.4 — pre-1.0: the wire may still change between releases, and an operator's pinned skill file is what an assistant relies on. Seven live demos above, on the real stack. Known TODOs live in
the spec: durable token revocation, key rotation, operator-push events. The reference implementation is Rails; on the wire it's HTTPS, JSON, and JWS — nothing Ruby-specific. Port it.
