ASKSINGAPORE.AI
How it works

The concierge that refuses to invent

Building a travel chatbot that answers questions is easy. Building one that admits when it doesn’t know is the entire job. Here is what runs behind the chat window on this domain, and the decisions that shaped it.

Open asksingapore.ai and type a question. Within a second or so, words begin appearing — a real answer, streaming in as the model produces it. There is no app to install, no account to create, no cookie wall. You ask; it answers; you leave.

That surface simplicity hides the only interesting problem in this category. A language model asked “where should I eat tonight near Marina Bay?” will always produce a confident, fluent, beautifully specific answer. The question is whether the restaurant it names exists.

What actually runs here

The architecture is deliberately small. The page itself is a single HTML file — no framework, no build step, no dependencies. The chat posts to one serverless endpoint on this same domain, which forwards the conversation to Agnes AI and streams the reply straight back to the browser, token by token.

Everything else is local. The Singapore clock in the corner is computed in the browser from your device time, not fetched. The page makes exactly two outbound calls in total: the chat itself, and a weather reading for Singapore. That is the whole system.

What the visitor gets from it:

  • Answers in their own language. The model is instructed to reply in whatever language the visitor writes in — no language picker, no setting to find.
  • Streaming, not spinning. Words appear as they are generated, at a steady reading cadence, rather than after a long blank pause.
  • Nothing to sign up for. No account, no app, no stored profile.
  • Short answers. Replies are held to roughly 150 words unless you ask for more. A concierge is not a brochure.

The failure we caught in testing

Early in owner QA, the concierge was asked for hawker food recommendations. It answered warmly and specifically: a stall name, the centre it sits in, the dish to order, the queue to expect.

The stall did not exist.

This is the characteristic failure of fast, small language models on local knowledge, and it is genuinely dangerous in a travel product. A hallucinated restaurant is not an abstract accuracy metric — it is a visitor standing in the wrong place at 8pm in an unfamiliar city, having trusted you. Worse, the invented answer is more appealing than the honest one. It is specific, it sounds like insider knowledge, and it reads exactly like the answer a great concierge would give.

The uncomfortable part: the better the model is at sounding local, the more convincing its inventions become. Fluency and reliability are separate axes, and optimising for the first does nothing for the second.

The fix: a short leash, on purpose

The response was not a better prompt asking the model to “be accurate.” Models comply with that instruction by sounding more confident, not by knowing more. Instead, the concierge operates under explicit venue rules and a curated list of verified places, written and checked by hand.

In practice, it may name a place only if that place is on the verified list or is a genuinely world-famous Singapore landmark. Otherwise it does not name one. Asked for the best chicken rice, it will point you to a specific hawker centre — Maxwell, Tiong Bahru Market, Chinatown Complex — and tell you to follow the queues or check current stalls on Google Maps. It will not invent a stall to fill the gap.

Three further rules follow from the same principle:

  • No street addresses or unit numbers. These are precisely the details a model fabricates most convincingly, and the ones a visitor is most likely to act on without checking.
  • No exact prices. Broad ranges at most, always flagged as variable.
  • No guessing at live facts. Opening hours, availability, schedules — if the model isn’t certain, it is instructed to say so rather than produce a plausible number.

When a new category of invention shows up, the fix is to extend the verified list in that category — never to relax the rules. The leash stays short; the list gets longer.

What it deliberately cannot do

The concierge cannot make a booking, a reservation or a purchase. Asked to, it explains how you can book yourself. This is stated plainly rather than hidden, because a fake booking flow is the fastest way to destroy trust in a product like this — and because a demo that pretends to transact is lying about what it is.

It also cannot browse the live web, check real-time availability, or give turn-by-turn navigation. It answers from what the model knows plus a hand-checked local brief. For a buyer, those are exactly the seams where live integrations would slot in — booking APIs, inventory feeds, a maps provider. The point of shipping without them is that nothing on the page currently claims a capability that isn’t there.

When it breaks, it says so

The endpoint has real limits: rate limits per visitor, a global cap, upstream timeouts. When any of those trip, the chat shows an honest line — the concierge is busy, or something went wrong, please try again.

The tempting alternative is a canned fallback answer: a generic paragraph about Singapore, served silently when the live model fails, so the demo never appears broken. We don’t do that. A canned answer posing as a live one is a small lie told at the exact moment the visitor is deciding whether to trust the product.

What we log, and what we don’t

Completed exchanges — the question and the answer — are appended anonymously to a spreadsheet so we can see where the concierge is weak and extend the verified list. No IP addresses, no identifiers, no accounts, no profiles. This is disclosed on the page itself, under the category chips, rather than buried in a policy nobody opens. Turning the logging off is a matter of removing one environment variable.


None of this makes the concierge smarter. It makes it narrower, and narrow is the correct trade for a product whose only real asset is being believed. A visitor who follows a recommendation and finds the place open is a visitor who comes back. A visitor who follows one into an empty street is gone, and so is every answer you gave them before it.

That is the version running on this domain today: a working concierge with the guardrails visible, built so that what it says can be trusted — and honest about the parts it leaves for whoever takes it further.

Acquisition

This domain is available

asksingapore.ai is for sale, along with the working concierge you can try on the front page. We haven’t set a public price — tell us what it’s worth to you.

Make an offer · [email protected]

Don’t buy a domain. Own the verb.

More notes