Search in the Cloud UI

The Search page is a chat-style interface for querying your knowledge graphs. When a conversation is empty, the page greets you with What are you looking for today?

​

Sending a query

1. Type a natural language query in the search bar (placeholder Ask a question about your data… under Text, Search a function, class or file name… under Code) and press Enter to send; use Shift+Enter for a newline.
2. The answer streams into the conversation area token by token. While it is pending, the answer bubble names its stage — Searching your data… during retrieval, then Writing… while the answer is generated. If the workspace retries the model call, the partial text clears and restarts rather than stacking two attempts.

The streamed tokens are a preview; the resolved answer that replaces them is authoritative and identical to what a non-streaming API call would return. A workspace that answers with plain JSON instead of a stream is still accepted — the answer simply appears at once. Suggestion chips are shown when a conversation is empty, and they follow the search type. Under Text:

• “What are the main entities?”
• “Summarize the uploaded documents”
• “What relationships exist in the data?”

Under Code:

• “Show the architecture”
• “List the API routes”
• “List the modules”

Click any chip to send it immediately. Past searches are loaded from the backend and shown in the history sidebar. History persists across sessions and is fetched via the GET /api/v1/search endpoint. Queries sent from this page are recall calls, and recall records the questions it answers, so your own UI searches appear in that history alongside searches made through the API — see Recall and search history.

​

Search type

Two pills sit beside the dataset selector, above the search bar, and decide how the next question is answered: Text is the default. Pick Code to reach a repository connected through the GitHub data source: a repository is ingested into the code graph and is not embedded, so nothing the hybrid retriever searches contains it and a question asked under Text comes back empty. When the workspace has a repository dataset, a note beside the pills says so — For GitHub repositories, use Code — it looks up functions, classes and files by name. A Code question is read as a structural lookup rather than a sentence: asking for the architecture draws the overview, naming a kind lists it (List the API routes), naming a file answers with what that file defines in source order, and anything else is resolved as a symbol name. Nothing matching is said plainly — No symbol, file or module name contains retry. The type belongs to the conversation, not the page. Your last choice is remembered per workspace and applies to a new conversation; reopening an existing one shows and uses the type it was asked under, and switching type while a conversation is open starts a new conversation rather than mixing the two. Because Code turns are not recorded as pod sessions, a Code conversation lives only in the open tab: it is listed in the sidebar while you are there, but nothing is stored on the backend, so it is gone after a reload.

​

Dataset

The active dataset is chosen with the dataset selector in the input area, at the right just above the search bar — not from the top bar, which carries only the workspace switcher and the page name. A query is always scoped to exactly one dataset: there is no All datasets option here, and if you have not picked one, the first dataset in the list is used. See Dataset selector. Every query searches the knowledge graph built from the documents you uploaded into that dataset. There is no memory scope to choose either: the former Company Brain / Agent Memory pills were removed, and the page no longer searches agent sessions. To look through what your connected agents stored, open Sessions instead.

​

Conversation history

The sidebar on the left lists past conversations grouped by age — Today, Yesterday, This week, This month, Older. Click any conversation to reopen it, use + (tooltip New conversation) to start a new one, or use the sidebar toggle to collapse and expand the history panel. + does not add a placeholder row — it returns you to the empty new-chat state, and the session is created by the first question you send. The open conversation survives navigation: leaving Search and coming back reopens the same conversation, and a follow-up continues the same backend session. An answer still being generated keeps arriving while you are on another page, and the page picks the stream up mid-answer when you return. Which conversation is open is also remembered per browser tab, so a full reload restores it — closing the tab does not. Past searches are loaded from the backend via GET /api/v1/search. New conversations created during the current page session appear alongside that history, deduped by id, so a restored conversation you have continued is listed once. The sidebar shows a skeleton while history loads, rather than asserting there are no conversations before it knows. Each conversation is titled with the workspace’s own title for the session, which is computed from the full transcript — the detail endpoint returns only the last 20 turns, so on a long conversation the first visible question is not necessarily the one that was asked first. A conversation whose visible tail is blank still keeps its place in the list, and a single malformed row costs that one row rather than the whole page.

​

Retention

A conversation is kept for one year of inactivity — the clock restarts on every write, so a conversation you keep using never expires. Before mid-September 2026 the window was seven days, after which an idle conversation kept its label in the sidebar but silently lost its turns and the model’s conversation history. The same retention applies to agent sessions on the Sessions page.

​

How search works

A Text search calls the POST /api/v1/recall endpoint with graph scope — a standard graph retrieval over the active dataset — opting into streaming (stream: true, or an Accept header ranking text/event-stream above JSON) so the answer arrives as server-sent events. See Streaming for the API contract, and Search Basics for the available search types and parameters. A Code search takes a different route: POST /api/v1/search with a structured code query, which returns the operation’s own payload — facts, nodes, edges, and stats — and reports its own errors rather than answering with nothing. It does not stream, and it is not recorded as a session turn.