Skip to content

SYSTEM Cited by 2 sources

Yelp Assistant

Definition

Yelp Assistant is Yelp's AI-powered chatbot brand, originally shipped in 2024 (iOS, SwiftUI) to help consumers diagnose service needs and connect with service pros — the canonical flow: a user opens the Assistant, writes "I have a leaky faucet", the Assistant asks clarifying questions until it has what a pro would need, then submits a Request-a-Quote project to multiple businesses. It was "the first large-scale consumer-facing use of large language models at Yelp" (Source: sources/2026-09-29-yelp-the-making-of-the-yelp-assistant-ui).

It has since expanded to answer questions about a business, create reservations, book appointments, and order food. In 2026-03 Yelp extended the Assistant to business pages as Biz Ask Anything (BAA).

"We first introduced Yelp Assistant, our AI-powered chatbot, in 2024 to help consumers diagnose service needs and easily connect with service pros." (Source: sources/2026-03-27-yelp-building-biz-ask-anything-from-prototype-to-product)

UI architecture: a hybrid native + server-driven chat app

The 2026-09-29 post documents the UI architecture of the original consumer/services variant. The defining constraint was decision reversibility under uncertainty — the team was simultaneously learning to use LLMs as a product and racing an evolving technology, so they wanted UI decisions that were cheap to make and cheap to reverse: "how can we mitigate the cost of making and changing decisions?"

Why server-driven, then why hybrid

Mobile's app-store latency (days to reach users; some never update) pushed the team toward server-driven UI (SDUI) via Yelp's CHAOS framework — "update the backend and all clients receive the latest configuration within minutes." But early CHAOS lacked network-request affordances and text input, and building those "required more time than we wanted to invest." So they chose a hybrid (hybrid-native-sdui):

  • Top bar (close button) — native
  • Chat content (the messages) — server-driven (CHAOS)
  • Input bar (where the user types) — native

"Our goal was to build something, ship, and start learning." Making the two halves cooperate requires blurring the boundary: sending a message interacts with the native UI, displaying it requires the CHAOS context.

View / data separation

The client fetches the CHAOS view configuration once at launch (the blueprint + the actions that fire on events + operations required for correct functioning), then uses it as a template that data hydrates turn-by-turn — separation of concerns between the view (fetched once) and the data (streamed per turn). Client state lives in CHAOS datasets; "each entry in the dataset represents a MessageEvent," and CHAOS observes the datasets to keep the UI current. This is what lets new content (even new message types) be appended incrementally without re-fetching the view.

The chat loop (turn-based, reactive, optimistic)

Yelp Assistant "is reactive and turn-based" — it only responds to a message, never proactively pushes, and the user must wait for a reply or failure before sending again. On Send:

  1. disable the input box
  2. clear quick replies
  3. send the message to the backend
  4. optimistically insert the user message + a typing indicator into the dataset

On reply (happy path): remove the typing indicator, insert the response, add quick replies if present, re-enable the input box. The user message insert is an optimistic update ("to show it instantly"); "the client is fully responsible for inserting and removing the typing indicator at the right time."

MessageEvent vocabulary

Each message is a MessageEvent — opaque to the chat app, rendered by CHAOS component templates. data class MessageEvent(id, type, text?, url?). Types disclosed:

Type Ephemeral/Persistent Interactive Notes
user_message Persistent No User's text
typing_indicator Ephemeral No Send → response
bot_message Persistent No Bot's reply
link_message Persistent Yes Navigate elsewhere; usually ends the chat (e.g. "See your matches" → yelp:///project/...)
quick_replies Ephemeral Yes Tappable suggested replies (separate dataset, same principle)

Only quick_replies and typing_indicator are ever removed.

Actions: user-triggered vs backend-triggered

  • CHAOS actions (user-triggered, via onView/onClick): quick_reply (Yelp-Assistant-specific; routes a tapped bubble back through the message-sending logic) and open_url (built into CHAOS; navigates to a link_message's destination).
  • Client actions (backend-triggered): "a client action is executed by the client on the backend's instruction." The first is DisableChat, included in the bot's final response to remove the input bar and end the session — most commonly because the project was submitted, but also on rate limits or errors. "The mechanism is flexible to support new actions as we require them." This backend-driven-client-action seam lets the server steer a native-owned surface (the input bar) it doesn't render.

Failure handling

Two tiers of graceful degradation; both first remove the typing indicator and insert an error message. Recoverable → retry a bounded number of times, then ask the user to resend. Non-recoverable → ask to try again later and disable the chat, ending the session.

Consequences

  • Composability — "add new functionality such as image recognition or support for logged-out users as each part of the entire system is independent of the others."
  • A reusable foundation — a team "cloned and repurposed Android's Yelp Assistant to bootstrap the pilot for Biz Ask Anything"; the hybrid UI "laid the groundwork for what would become the next generation of Yelp Assistant."
  • Costs — onboarding time (learn Yelp Assistant + CHAOS before contributing) and cross-platform rendering inconsistencies ("what works well in one platform is buggy in another").

Seen in

Last updated · 766 distilled / 2,225 read