AI search in a SaaS product: should search and the AI assistant be one input?

Decide by what the user is trying to do, not by the technology behind the box. One input works when finding and asking start from the same moment in the user's head, the product keeps ordinary search as the default, and it always shows which mode is active and which source answered. Keep two inputs when the jobs differ in consequence: finding a known record is not the same act as asking for a generated answer or an action, and a person should never get the second when they asked for the first.

The rest of this page gives the rule in a form a product lead can apply, the jobs a SaaS search box is asked to do, how widely used products split or merge the two, what a single input has to get right, and how each choice fails.

The decision rule

Ask three questions about your own product, in this order.

1. Do the two jobs start from the same place? If people arrive at the box with the same kind of words and cannot know in advance whether a record or an answer will help, one input spares them a guess. If one job is "open invoice 4471" and the other is "draft a renewal email for this account", they do not start from the same place.
2. Does a wrong response cost the same? A wrong search result is visible and cheap: the person sees the list and looks again. A wrong generated answer reads as fluent and complete, and a wrong action changes something. Where the assistant's output will be relied on, sent or run, the move into it must be a deliberate act by the person, never an automatic switch.
3. Can the product show mode and source at a glance? If the field cannot make clear whether it is searching or asking, and the result cannot make clear whether it was retrieved or generated, keep the two apart until it can.

These are design judgements drawn from the evidence below, not measured results. Test them against your own users' queries before you commit.

The jobs a SaaS search box does

Andrei Broder's taxonomy of web search (SIGIR Forum, 2002) separated navigational, informational and transactional queries: reaching a known place, learning about a topic, and getting something done. Inside a SaaS product the same split appears in five jobs, and they are the unit to design for.

The first three are retrieval. The last two are where an AI assistant adds something search cannot. The decision about one input or two is really a decision about whether these jobs can share a front door without the person losing track of which one they are in.

How shipped products draw the line

Product documentation shows the range. These describe how each feature is designed, not how well it performs.

The direction of travel matters too. Microsoft's release notes record Copilot Chat made available in a side pane while people use Copilot Search (25 August 2026), then, on 6 October 2026, chat embedded directly within search results, with the results as the foundation for follow-up questions. A vendor that built two surfaces is joining them at the results, not at an empty box.

Google applies a similar gate on the open web: its guidance for site owners says AI Overviews are only shown when its systems determine that it is additive to classic Search. The generated answer is the exception the query has to earn, not the default.

What one input has to get right

Merging the two jobs moves work from the person to the interface. Five things have to be visible or they become the person's problem.

The current mode. The field should say whether it is searching or asking before the person presses Enter: a label in the field, a different placeholder, a visible mode chip. A key press that changes behaviour silently leaves people unsure which engine will answer.

Which source answered. A retrieved record and a generated answer need to look different, and the answer needs its sources at the claim. Evidence on the open web shows why the boundary matters. In a Pew Research Center analysis of 900 US adults' browsing in March 2025, people clicked a traditional result in 8% of visits to Google results pages with an AI summary and 15% of visits without one, and clicked a link inside the summary in 1%. That is web search, not a SaaS product, and Pew measured an association, not its cause; still, it is a pattern to design for: when an answer sits above the results, people open the results less. And in two online experiments by Spatharioti, Rothschild, Goldstein and Hofman at Microsoft Research (CHI 2025), people using LLM-based search finished decision tasks faster and were as accurate as with traditional search while the model was right, but over-relied on its answer when it was wrong; colour-coded highlighting that flagged potentially incorrect content helped them catch the errors. The experiments, first reported in 2023, used product-comparison tasks and the models of that time, so the size of the effects will not transfer. The lesson does: if a generated answer can be wrong, the interface must show what it rests on.

The zero-results state. A search that finds nothing is the most natural moment to offer the assistant, and the most dangerous moment to switch to it without saying so. Say that search found nothing, then show that the query has gone to the assistant. Check first for the near miss: a typo, a synonym or an ID with a missing digit should still find the record, because an assistant that answers when an exact match existed is worse than an empty list.

Keyboard behaviour. Raycast uses Tab to switch into the assistant, and Chrome uses Tab or Space after a typed keyword. In a web application Tab already has a job: the WAI-ARIA combobox pattern states that "the combobox is in the page Tab sequence", so Tab is how keyboard users leave the field. If you borrow it, switch only when the field holds text, keep Shift+Tab and Escape working, offer a visible control that does the same thing, and announce the mode change to screen readers as a status message. WCAG's No Keyboard Trap criterion requires that focus can always be moved away with the keyboard, and that people are told how if it takes more than the standard keys.

Permissions and sources. Both modes must see the same eligible content for the same person, or search and the assistant will disagree about what exists. Watch for answers that draw on more than the results do: Microsoft notes that Copilot Answers may include references from external sources, including the web, depending on the grounding the organisation has enabled for Copilot Chat, while the search results come from Microsoft 365 and connected sources. If the answer can reach sources the list cannot, label them. The detail of permission-aware answers is covered in our article on AI chatbot UX for B2B products.

How merging fails, and how separating fails

Each choice has its own failure, and it helps to name both before choosing.

Merging fails when:

• the person cannot tell a retrieved result from a generated one, and treats a summary as if it were the record;
• the assistant answers a query that had an exact match, so a known object is replaced by a paraphrase of it;
• the switch into the assistant happens on a rule the person cannot see, so the same words give a list one day and prose the next;
• a draft or action starts from what looked like a search, and the person did not mean to ask for either.

Separating fails when:

• people must guess which box will answer, and the wrong guess costs a second attempt;
• "Ask AI" becomes a worse search: people type keywords into it, get a paragraph back instead of the record, and stop using it;
• the two entry points drift, with different permissions, different sources or different names for the same object;
• nothing carries over, so moving from results to the assistant means typing the question again.

When people try an AI feature once and stop, the cause is worth diagnosing before the interface is rearranged; our article on why users stop using an AI feature after trying it once sets out the tests.

Where recommendations belong

"Suggested for you" is the neighbouring case. A recommendation answers a question the person has not asked yet, so its natural home in a search surface is the empty state: before anything is typed, recent items, likely templates and suggested destinations save a search. Once the person types, the query has stated the job, and suggestions should give way to matches.

Three conditions keep recommendations honest inside a search surface:

• Label them as suggestions, separate from results, so a promoted item is never mistaken for the best match. Promoted items are a shipped feature, not a hypothetical: Microsoft's Copilot Search lets administrators curate answers for acronyms, bookmarks and people that are delivered directly in search results.
• Show the basis in a few words: recent activity, the current project, what the team uses.
• Give a way to dismiss or correct, and make clear whether that changes only this list or future suggestions.

Keep a recommendation out of the search surface when it proposes a consequential action, such as reassigning work or changing a setting. That belongs in the context where the person can see what it affects, with a confirmation step.

One field, two modes: our Eden AI redesign

At Tcules, we redesigned workflow creation for Eden AI, a platform where developers combine AI capabilities into workflows they can test and export as API endpoints. The problem had three entry points (start from a template, ask AI for help, or start from scratch) and separate interfaces for building, testing and configuring. It came up repeatedly in Eden AI's regular user feedback sessions and was verified with analytics and Hotjar recordings. Before the redesign, only 6% of users were able to create workflows.

We replaced the three entry points with one search field that kept every way of starting a workflow:

• standard template search by default;
• a Tab press to switch the field into the AI assistant;
• when a search found no results, the query became an AI prompt, so the person did not have to write it again;
• preview cards and documentation, so a template or AI feature could be inspected before it was added;
• the same component reused inside the builder to find and add AI feature nodes.

The design followed the command-palette pattern, with GitHub Copilot and Raycast as the familiar references. The case reports its impact qualitatively, as a more efficient and approachable tool; it gives no measured figure after the redesign, so we claim none.

By the rule above, one input fitted here. Both jobs started at the same moment, "I want to start a workflow". Search stayed the default, so a person who knew which template they wanted got it. The switch was explicit. And the assistant's output was a workflow the person could test in the builder before putting it into production, so a wrong suggestion could be caught before it did anything. Samy Melaine, Eden AI's founder and CPTO, put the wider principle simply in our conversation with him: "don't do AI for AI sake, but do it for your user sake." For the wider map of where search sits among AI product patterns, see our article on generative AI in SaaS.

Test the choice before you ship

The rule is only as good as your understanding of what people type. Before choosing:

1. Sort a sample of real queries by job. Take recent searches, support questions and assistant prompts and mark each one: known object, navigation, capability, open question or action. The mix tells you whether the jobs share a starting point.
2. Find the near misses. For each known-object query, check whether search found the record. Those that failed are the queries an assistant would be tempted to answer with a paraphrase.
3. Run the zero-results path. Take the queries that found nothing and see what the assistant would say. If it answers confidently from the wrong source, fix retrieval or eligibility before merging anything.
4. Test the switch with keyboard and screen-reader users. Can they tell which mode they are in, and can they leave the field?
5. Decide what the assistant may do from this box. Answering, drafting and acting are three different permissions; grant them one at a time.

At Tcules, we design this decision as part of our AI search and recommendation work: what the person is trying to find, which content they may see, where each answer comes from, and the decision that follows, with search, generated answers and recommendations kept distinguishable even when one interface presents them together. If your product has a search box and an assistant that do not yet know about each other, that is the place to start.