Now Assist in Virtual Agent doesn't fire topics. It runs plans.

Claire_Conant · 57m ago

Now Assist in Virtual Agent works differently from what classic Virtual Agent trained you to expect. It runs on an agentic model. Instead of matching one message to one topic the way classic Virtual Agent did, it reads your whole request, plans across multiple resources, and sequences tasks to complete them. When that shift catches you off guard, it can look like a misconfiguration. Understanding the model is the faster path to knowing what to check, and this article sets that up before you go looking for a specific fix. It's not unpredictable. It's just a different kind of predictable.

How does Now Assist actually process a request?

The classic Virtual Agent model is clean and predictable: one message, one topic, one path. If the user asks two things at once, the older behavior picks one match, or lists what matched and leaves the user to choose. This is how Virtual Agent worked for years, and it made troubleshooting straightforward: if the wrong topic fired, you looked at intent matching. Carrying that model forward isn't a mistake. It's just no longer the whole picture.

What's really happening

Now Assist in Virtual Agent uses agentic AI as the primary orchestration, and that changes the runtime model underneath your assistant. When a question comes in, the assistant understands the query and can reason, plan, and act across a much wider set of resources than a single topic: AI agents, Virtual Agent topics, conversational actions and subflows, catalogs, knowledge base articles, custom skills, and any supported Now Assist skill. The piece doing all that coordination is called the Orchestrator. It builds a plan based on what your request actually needs, and then routes each part to the right resource:

If a specific AI agent is available for the task or subtask, the Orchestrator uses that agent.
If no specific agent fits, the assistant uses the Search Agent to find an answer or an appropriate skill within the sources assigned to it.
If a skill needs to run to complete the request, the assistant runs that skill.

Across all of this, the Orchestrator can plan and sequence multiple agents, skills, and knowledge answers together to complete a complex request.

Here's an example:

Ask the classic model "What's the maximum contribution for ESPP? Send the details to Robert." It answers the first part but then stops because nothing matches the second part on its own.

In contrast, the agentic model recognizes two separate intents, answers the knowledge question, and then uses that answer as the input to send the email. It separates the request into individual tasks, works out which one depends on another, and handles them in order, passing the result of one step into the next.

Where does Now Assist get its answers?

When Now Assist answers a knowledge question rather than running a skill, it isn't drawing on the model's general training. It's retrieving from sources you control: the search sources you assign (internal content, catalog items, and external sources such as SharePoint), any Knowledge Graph schemas you've added (the Knowledge Graph is a structured map of your data that the assistant can draw on), and your knowledge base articles. The Search Agent retrieves relevant content from those sources and the response is generated from what it finds.

The structure of your knowledge articles now matters more than it used to. Now Assist parses them as HTML and text, not as a rendered visual layout, and it chunks them by their headings. Clear, semantic headings act as anchors that improve retrieval accuracy and reduce the chance of a vague or wrong answer. An article written as one long unstructured block is harder for retrieval to use well, even when the answer is technically in there.

It helps to think in terms of retrieval and routing rather than the assistant "knowing" things. It doesn't know your ESPP policy; it retrieves the article that contains it and routes the request to an agent or skill when action is required. So, when a response is wrong, the useful question is "what did it retrieve, or where did it route?" That points you straight at the configuration in play.

Why it works this way

The design goal is to handle real requests the way a person would. People bundle intent: they ask a question and request an action in the same breath, or string together several tasks that depend on each other. A model that can only fire one matched topic either drops the extra intent or hands it back to the user to re-ask.

Agentic orchestration closes that gap by separating the request into its individual tasks, working out which ones depend on others, and completing the whole thing using the resources available to the assistant. The trade-off is that behavior is now shaped at runtime rather than fully scripted, which is exactly why it helps to understand how it works before you troubleshoot. You're no longer debugging a single decision point. You're reasoning about a plan.

What this means for you

Once you see Now Assist in Virtual Agent this way, several configuration realities follow:

Agents have to be enabled to be discoverable. Only the AI agents enabled and mapped to the current assistant are available to the Orchestrator for planning. If an agent you expected never gets used, check that first, before you question how the user phrased the request.
You choose how the assistant operates. An assistant can run with agentic support turned on or in a standard question-and-answer mode. This is a setting you select, and it shapes whether the assistant plans across multiple tasks or answers one question at a time.
Your knowledge base is part of the response quality. Because answers are retrieved and grounded in your articles, their structure and clarity directly affect response quality. Well-structured, single-intent articles tend to retrieve and summarize better than long multi-topic ones.
Your search sources and Knowledge Graph scope define what's reachable. The assistant can only retrieve from the sources assigned to it. If answers are missing or thin, check those assignments before assuming the model is at fault.
The dead-end behavior is yours to configure. When the assistant can't find an answer or a step can't complete, it offers the fallback options you've set up, such as requesting a live agent, creating a support request, or viewing office hours. Users can also stop an agentic conversation mid-query and start over.
Watch the patch trajectory. Agentic behavior evolved across Zurich patch releases, and some controls changed. For example, the sn_aia.use_agents_in_planner
property arrived in Patch 2 and was removed in Patch 4. Before you rely on a specific toggle, confirm it still exists on your patch level.

The behavior that looked unpredictable usually isn't. It's the visible result of a plan built from the agents, sources, and modes you've configured. Once you can read it that way, troubleshooting Now Assist in Virtual Agent stops being guesswork and becomes a question of which input to check.

Where to go from here

If you're moving from understanding the model to diagnosing a specific symptom, such as the icon not appearing, responses stalling, or the assistant not responding at all, the companion Issue Navigator routes you to the right resource by symptom. For deeper configuration, the product documentation covers the setup steps that follow naturally once the model makes sense. And if you're refining your own setup, the Community forum is a good place to compare notes with other admins working through the same shift.