Q&A mode

Q&A mode is the second flavour of the widget. It mounts an inline component (no floating bubble) with an email gate, then drops the visitor into a streamlined AI conversation. Use it when you want a "Ask anything about our product" widget on a help page, a documentation site, or a landing page.

The component is ChatQAApp in src/chat-qa-app.tsx.

Mount it

Set mode: 'qa' on the React wrapper or init call:

<AppmintChat
  orgId="..."
  configId="..."
  appId="docs"
  mode="qa"
/>

Or with the script tag:

<div id="qa-widget" style="max-width: 640px; margin: 0 auto;"></div>
<script>
  AppmintChat.init({
    containerId: 'qa-widget',
    orgId: 'your-org-id',
    configId: 'your-config-id',
    appId: 'docs',
    mode: 'qa'
  });
</script>

The component renders inside the container instead of fixed-positioning to the viewport. Sizing is up to you — the inner panel is h-[600px] by default, contained inside max-w-2xl mx-auto.

What's different

	Full chat	Q&A mode
Position	Fixed bottom-right (or left)	Inline inside container
Bubble	Yes (floating)	No
Welcome screen	Yes (/)	No — straight to email gate or chat
Agent routing	Yes (queue + assignment)	No — AI assistant only
Broadcast overlay	Yes	No
Engage notice	Yes	No
File uploads	Yes (drag-and-drop)	No
Email gate	Optional (can pre-auth)	Always present (email-only, no name/phone)

The trade-off is simplicity. Q&A mode is a single screen — header, message list, input — with one job: answer the visitor's questions using the AI assistant attached to the chat config.

Email gate

The first time a visitor uses the Q&A widget they see an email-only form. Submitting it calls AppEngine's customer-register endpoint internally (the bundle's REST helper, name varies across builds — search chat-client/src/utils/ for the actual call) with { email, name: <email-prefix>, phone: 'N/A' } to create a guest customer, stores { token, user } in localStorage, and reveals the chat surface.

There's no name or phone field — the email-prefix is used as a placeholder name. If you want a richer registration, switch to full chat mode and use the ChatRegistrationPage form.

AI streaming

Q&A mode routes every message to the chat config's AI assistant. There's no human-agent fallback — if the AI errors or hits a rate limit, the visitor sees the error in the message stream. The aiStreamingMessages slice of the store drives the typing-style "streaming" UX:

• ai-stream-start clears the previous streaming buffer and shows a "thinking..." indicator in the header.
• ai-stream-chunk appends text to the current streaming message and rerenders.
• ai-stream-tool-use / ai-stream-tool-result emit tool-call breadcrumbs (rendered as system messages by default).
• ai-stream-end finalises the message and moves it into messages.
• ai-stream-error flips the streaming state to error and surfaces the message.

The widget renders AI replies through react-markdown with remark-gfm so tables, fenced code, and task lists work out of the box.

Configuration

Q&A mode reads the same chat-config record as full chat. The relevant fields:

If you don't have an AI assistant configured on the org, Q&A mode renders the email gate but messages won't get a reply. Configure an assistant in the admin UI or via POST /repository/create with datatype: 'assistant' first.

Mixing modes

You can mount both — a floating chat bubble for support and a Q&A widget on the docs page — as long as they use distinct configIds. The chat store is a singleton, so behaviour is undefined if both mount on the same page with overlapping configs. Pick one mode per page.

When to choose Q&A mode

• A documentation site where every page should expose "ask the docs".
• A pricing page where you want a "got questions?" inline assistant.
• A help centre where the visitor is already in a help context (no need for a floating bubble).
• You don't need human handoff and don't want the friction of a multi-field registration form.

Otherwise, prefer full chat mode.