Chat & search experience

In one line. The two ways an end-user asks questions over their documents — conversational Chat (with cited answers) and query-driven Search (ranked results) — and how a builder turns them on. You’ll be able to. Walk a user through asking a grounded, cited question; read every control on the Chat and Search surfaces; and know which builder switch enables each. Where this lives. Consumer app: the Chat tab (App ▸ Chat) and the Search tab (App ▸ Search). Builder config is in Studio — see Shaping the experience.

Why it matters

The document pages (Document workspace, Document detail) were about processing documents — extracting fields, moving them through review. This is the other half of the platform: letting people ask questions of a body of documents and get answers back. That is what a Knowledge collection exists for. There are exactly two surfaces for it, and they answer different needs:

	Chat	Search
Shape	A conversation — you ask, it answers, you follow up	A query box — you ask once, you get a ranked list
Answer	A written answer, grounded with citations back to source documents	A list of matching documents/passages, with the best answer highlighted
Best for	“Explain it to me”, “compare these two policies”, multi-step reasoning	“Find me the document that says X”, scanning many hits
Memory	Multi-turn — it remembers the conversation	Stateless per query (but keeps a search history)

Same underlying retrieval; different end-user experience. Teach a user Chat when they want an answer in words, Search when they want to find and open the right document.

Status — coming soon / by design. Knowledge collections — and the auto-vectorise-on-ingest that makes a document answerable the moment it lands — are partly forward-looking in the current build (see the callout in What is Botminds). The Chat and Search surfaces below are shipped and live; what is still rolling out is the automatic “every doc auto-becomes knowledge” wiring. Until then a builder may need to attach knowledge and run vectorisation deliberately (Collections & schema).

Chat

One engine, four places. The platform has one chat engine that surfaces in several containers: the full-page Chat tab, a Project Co-pilot modal launched from the nav, an embedded doc-chat pane on a single document, and a floating agent widget. They share the same controls — learn it once here and you know all four. (The retired global “Piper” assistant is dormant; the newer Global Co-pilot dock is its replacement.)

Layout

CHAT  (App > Chat)
+---------------+----------------------------------------------------------+
| CONVERSATION  |  +- You ---------------------------------------------+   |
| RAIL          |  | Which of our policies cover remote work?          |   |
|  + New chat   |  +---------------------------------------------------+   |
|  Search chats |  +- Assistant ---------------------------------------+   |
|  -----------  |  | Three policies address remote work ... [1][2]     |   |
|  Today        |  |  References:  [1] Remote-Work.pdf p.3             |   |
|   . Remote... |  |               [2] Travel-Policy.pdf p.1           |   |
|   . Leave...  |  |  up / down    copy    speak                       |   |
|  Yesterday    |  +---------------------------------------------------+   |
|   . Expenses  |   Follow-ups:  [ Does it cover contractors? ]            |
|  -----------  |   thinking... 62%  (Agent Build Log >)                   |
|  profile      |  +---------------------------------------------------+   |
|               |  | Ask a question...                          [Send] |   |
+---------------+--+---------------------------------------------------+---+

Conversation rail (left) — + New chat, Search chats, and the history of past conversations grouped by day. A user profile link sits at the foot.
Message thread (centre) — alternating you bubbles and assistant bubbles.
Composer (bottom) — the question box, with Send. On an empty chat it shows suggested/default questions to get the user started.

What every control does

Control	What it does	Notes
Ask a question box	Type a question, press Send	On an empty chat, suggested questions (the project’s default questions) appear above/in the box as one-click starters
Assistant answer	A written, streaming answer	Renders rich content: markdown, tables (with CSV export), charts, code blocks
References chips	Numbered citations — `[1] [2] …` — one per source document	Clicking a chip deep-links into the document at the cited page. This is how chat proves its answer.
Thumbs up / down feedback	Rate an answer	Plus copy and speak (read aloud) on each answer. Feedback trains/flags quality.
Follow-up chips	Suggested next questions	One click asks them — this is what makes Chat conversational.
Regenerate	Re-runs the last question	Use when an answer was weak.
thinking… footer	A sticky status while the agent works	Animated dots plus a progress %/heading; an optional Agent Build Log shows the live tool steps the agent is taking.
+ New chat	Starts a fresh conversation	Clears context so a new topic doesn’t inherit the old one.
Search chats	Finds an earlier conversation in the history	History persists per user.
Output / Query toggle	Shows the answer or the underlying query the agent ran	Only when the project enables answer transparency.

Walkthrough — ask a grounded question

Open App ▸ Chat.
The empty chat shows suggested questions. Either click one, or type your own in the Ask a question box — e.g. “Which of our policies cover remote work?” — and press Send.
Watch the thinking… footer: the agent embeds your question, retrieves matching passages, and composes an answer. (Expand the Agent Build Log if you want to see each step.)
Read the streamed answer. Note the [1] [2] markers and the References block beneath it.
Click a reference chip — the source document opens at the exact cited page so you can verify the claim. This round-trip back to the source is the whole point of grounded chat.
Click a follow-up chip (or type your own) to continue the thread — the assistant remembers what you already discussed.
Give the answer a thumbs up or down. That feedback is recorded for the builder to review.

Behaviours to know

Connection / streaming states. Answers stream token-by-token. If the connection drops you’ll see “Reconnecting…” or “Connection lost — Reconnect”; an unanswered question offers “Try again”. None of this loses your conversation.
Human-in-the-loop (HITL). If the agent is configured to pause for a human, chat shows a pending-interrupt card — Approve, Review (with feedback), or Reject, with editable arguments. The conversation resumes once you decide. Present only when the agent’s workflow defines an interrupt; most read-only knowledge agents never show it.
The four containers. The same controls appear in the Co-pilot modal, the per-document doc-chat pane, and the floating agent widget (the only place a user picks which agent to talk to at runtime). If you learned the Chat tab, you’ve learned them all.
It only knows what it was given. A chat agent answers over the Knowledge collections attached on its Knowledge tab — nothing else. No attachment, no answer (see the builder section below).

Search

Layout

Search has two states on the one tab:

Search home — a hero prompt (“Hi there, What Can I Help With?”) with the query box, a Select meta fields picker, a Select a view picker, the Search button, and three prompt-hint cards.
Search results — after you search: the query bar with a Clear control, a “Showing: N of M Results” count, a Search history toggle, the ranked results list (matching passage highlighted, thumbs up/down per result), Refine search, and Load more.

What every control does

Control	What it does	Notes
Search hero	The “Hi there, What Can I Help With?” prompt box	The landing state of the Search tab.
Select meta fields	Choose which extracted fields to search/return	Has Select-All / Unselect-All.
Select a view	Scope the search to a saved View	Reuses the same Views from your document lists (Shaping the experience).
Prompt-hint cards	Three example queries	One click runs them — onboarding for new users.
Search button	Runs the query	Switches the page into the results state.
Results list	Ranked matching documents/passages, with the answer-key passage highlighted	Each result deep-links to its document.
Thumbs up / down per result	Vote a result up or down	Tunes relevance / records feedback.
Load more	Pages in the next batch of results	Counts up toward the total “Showing: N of M Results”.
Refine search	Narrow by annotations, keywords, or labels	Layer constraints without retyping the query.
Search history	Re-open a past search	Toggled from the results header.
Clear	Empties the query	Returns you to the hero.

Walkthrough — find the right document

Open App ▸ Search.
(Optional) narrow the scope: pick a View in Select a view, and/or pick meta fields.
Type a query — e.g. “remote work policy” — and press Search (or click a hint card).
Scan the results list: the matching passage is highlighted in each hit, ranked best-first.
Thumbs-up or down the results to record relevance feedback.
Load more to page further, or Refine search to add a keyword/label constraint.
Click a result to open the source document; reopen earlier queries from Search history.

Behaviours to know

Search reuses Views. “Select a view” is the same View object you build for document lists in Shaping the experience — a Search scope is just a saved slice.
It’s feedback-driven. Per-result voting is first-class here; encourage users to thumb results so relevance improves.

Under the hood — how a Knowledge collection answers. When a user asks a question (Chat or Search), the platform embeds the query into a vector, then does a KNN (nearest-neighbour) match against the vector index — but scoped to the attached collection only (filtered by the collection’s id, so a 100-document corpus and a 100,000-document corpus answer just as fast, and unattached corpora can never leak in). The closest passages are handed to the LLM as context, which writes the answer and attaches a citation back to each source passage — that’s where the References chips come from. A structured question (“how many invoices over $10k?”) takes a different path: it runs read-only SQL against the collection’s Knowledge Datasheet instead of vector search. As noted above, the chunk → embed → index step that fills the vector index is the partly forward-looking piece; the retrieval and citation behaviour is live. Skippable, but it explains why citations are trustworthy: the answer is grounded in passages actually retrieved from your documents, not invented.

How a builder turns these on

You don’t write code for any of this — you configure it. The essentials, with their home pages:

To do this…	Go to…	Page
Let an agent answer over a corpus	Attach a Knowledge collection on the agent’s Knowledge tab	Your first agent — required, or it has nothing to read
Build / vectorise the Knowledge collection	Data Model — create the collection, set its category to Knowledge	Collections & schema
Set default / suggested questions, transparency, feedback	Studio ▸ Chat settings	Shaping the experience
Configure Search settings and the Views that scope it	Studio ▸ Search settings / Views	Shaping the experience
Show or hide the Chat / Search tabs entirely	Project flags (`DisableChat`, `DisableSearch`)	Shaping the experience

Watch out. The single most common “why won’t it answer?” mistake: the Knowledge collection was never attached to the agent’s Knowledge tab. No attachment = no retrieval = a vague, source-less answer. Always check the Knowledge tab first (Your first agent).

Try it yourself

Using a project that already has a Knowledge collection attached (the Policy assistant use case builds one end-to-end):

Open App ▸ Chat, click a suggested question, and watch it stream.
Click a References chip — confirm it opens the cited document at the right page.
Ask a follow-up chip, then a fresh question after + New chat — notice the second one has no memory of the first.
Give one answer a thumbs down.
Now open App ▸ Search, run the same question, scope it with Select a view, thumbs-up the best hit, and Load more.
Compare the two experiences: which felt better for “explain it to me”, which for “find the doc”?

Recap

Two surfaces ask questions over documents: Chat (conversational, multi-turn, cited answers) and Search (query → ranked results). Same retrieval, different experience.
Chat gives written answers grounded with citation chips that deep-link back to the source page; it has conversation history, suggested/follow-up questions, thumbs up/down feedback, a thinking footer, streaming/reconnect states, and (if configured) HITL approve/reject cards.
One chat engine surfaces in four containers (Chat tab, Co-pilot, doc-chat, floating widget).
Search offers a hero prompt, View-scoped results, per-result voting, Load more, Refine search, and Search history.
Under the hood: the query is embedded and KNN-matched against the vector index, scoped to the attached Knowledge collection, and grounded with citations; structured questions hit a SQL Datasheet. (Auto-vectorisation is partly forward-looking.)
A builder must attach a Knowledge collection on the agent’s Knowledge tab (Your first agent) and tune Chat/Search settings in Shaping the experience — no code required.

Where to go next

Collections & schema — build the Knowledge collection these surfaces answer over.
Shaping the experience — turn Chat/Search on, set default questions, and define the Views that scope Search.
Your first agent — the Knowledge tab where a corpus gets attached to an agent.
Policy assistant — build chat-over-a-corpus end to end.