Agentic Apps – Ask Oracle Advisors

How the framework turns a user’s question into a routed, context-aware, multi-modal response — and how to build the agents that answer it well.

Introduction

Learn how Ask Oracle dispatches queries via the Query message hint. Why a dedicated Query agent is different from your panel agents. The five-step request flow. Exactly what to pass into your Query LLM node. Why $chatHistory makes or breaks follow-ups. How agent descriptions drive routing in multi-agent apps. Response composition — text plus supporting displays. Section-focus scoping. Builder UI configuration. Tone and summary behavior. Common pitfalls.

1. Ask Oracle: who answers the user’s question?

Every agentic app surfaces a single, persistent input field at the top of the page — the Ask Oracle bar. The user can type any question into it, at any time. The interesting design decision is what happens next: which agent actually answers.

Neither option is more correct than the other — they suit different apps. A dedicated Query agent gives you tight, predictable control over voice and behaviour, which is ideal when you want every answer to feel consistent or when one agent (or team) genuinely owns the whole domain. Letting the orchestrator dispatch is the natural fit when you have several specialised panel agents and you want the user’s question to reach whichever specialist is best suited — like having a 24/7 expert panel where the right expert steps forward.

This blog walks through both paths: the request lifecycle they share, the variables you must pass into the Query LLM node, how the orchestrator decides which agent to pick, the configuration steps in the Builder UI, and the production-grade patterns that make the Ask Oracle experience reliable either way.

---

2. Ask Oracle and Summary: the two special agent slots

Every agentic app has two app-level agent slots that sit outside the regular panel agents:

Ask Oracle — the Query agent

A specific agent team you assign to handle every conversational query the user types into the Ask Oracle bar. It responds with answers and can also produce supporting information displays. Why a dedicated agent? Because you control the routing, the prompt, and the response style — rather than letting the orchestrator pick. The Query agent is bound to the app via the queryAgent property in the application configuration.

Summary — the rolled-up snapshot

A specific agent (or team) that generates the main summary at the top of the app. This replaces the default behavior where the agentic app orchestrator aggregates insights from every agent on the page. Why a dedicated Summary agent? When you have many agents, you want a single voice and a focused summary — not a generic roll-up of every panel.

---

3. The Ask Oracle Query flow — from keystroke to response

Where each Ask Oracle response actually lands. By default a new Ask Oracle response appears as a new section at the top of the page. The most recently displayed Ask Oracle section is highlighted in the chat. If the user has pinned a previous section, the new response appears on top without overwriting it; if they have not, the new response replaces the prior one. This is intentional — it keeps the workspace from sprawling while letting users keep responses they want to act on.

$OraMessageHint == “Query”: the routing pivot

Inside your agent team’s workflow, the very first thing the entry node does is inspect $context.$app.$OraMessageHint. That single string tells your agent which lifecycle event has just fired and, by extension, which branch of your workflow should run.

Two things are worth emphasizing here. First, the Query branch is the only one that is fed by a free-form user input — it cannot be precomputed at app initialization the way Summary or InitDisplay can. Second, the Query branch is the only branch that is expected to use chat history to maintain conversation continuity.

Query is post-initialization. Summary, InitSubtitle, InitDisplay, InitActions, and InitCommunications all fire during the app’s initialization phase — before the user has done anything. Query, InvokeAction, FillParameters, and SendCommunication only fire later, in response to user interaction. Your routing logic should treat the two phases differently.

What you must pass into the Query LLM node

The single most reliable way to predict whether an Ask Oracle agent will perform well is to look at exactly which context variables are wired into the Query LLM node. This is also where the majority of production bugs originate: builders assume the framework auto-passes context, and it doesn’t.

Variable		Required?	Why it matters
$context.$system.$inputMessage		Required	The user’s actual question. Nothing answers without it. Pass it verbatim to the prompt.
$context.$system.$chatHistory		Required	The prior turns of the Ask Oracle conversation. Without it, the agent has no memory and follow-ups like “and the next quarter?” break completely.
$context.$app.$OraUserContext		Optional	Logged-in user identity: fullName, userId, userName, guid. Pass it when answers should be personalized or scoped to who is asking.
$context.$app.$OraAppContext		Optional	Context passed via URL parameters at app initialization — typically the entity the app is scoped to (a candidate, a deal, a requisition). Pass it when the answer must respect that scope.
$context.$app.$OraAttachments		Optional	Files the user attached to the chat. Pass it when your agent is set up to reason over uploaded documents.
$context.$app.$OraAgentList		Optional	The list of agents available in the app. Useful for dedicated query agents handling Ask Oracle queries when they need to know what other panel agents exist.

$chatHistory — the make-or-break variable

If we had to point to a single variable that separates a competent Ask Oracle experience from a frustrating one, it would be $chatHistory. The Query LLM node is invoked once per user question — the model itself has no memory between invocations. Every turn of conversation is a brand-new call. Without $chatHistory wired into the prompt, the agent has amnesia.

What goes wrong without it

Without chat history, Turn 2 is parsed as a standalone question. The agent has no idea what list was just shown, what “the next quarter” refers to, or even that the conversation is about talent retention. It produces a generic, off-target response — or worse, an apologetic refusal. With $chatHistory wired in, the model sees the prior question and answer, infers the topic, and produces the natural continuation the user expected.

How to wire it

Inside the Query LLM node’s prompt, reference the variable directly. A minimal pattern looks like this:

You are the Talent Retention Advisor.   Conversation so far: {{$context.$system.$chatHistory}}   New question from the user: {{$context.$system.$inputMessage}}   Answer concisely using the data in {xxxx}. If the new question is a follow-up, use the conversation context to interpret pronouns, time references, and implicit subjects.

---

4. Why agent descriptions decide who answers

When the user types a question, the agent team’s orchestrator has to choose which specialist answers. It does this by comparing the user’s intent against each agent’s description. Vague descriptions cause the orchestrator to skip your agent — or pick the wrong one entirely.

Diagnose routing problems with one test. Ask the app: “Show me the top talent we are at risk of losing.” If the wrong agent answers, do not rewrite the prompt. Rewrite the description. Then re-run the same query. If the right agent now responds, routing was the problem all along.

---

5. Response composition — text, displays, and dynamic content

An Ask Oracle response is not just a paragraph of text. The Query agent can emit a multi-part response that combines a conversational answer with structured visualizations and follow-up actions.

Whether an Ask Oracle response includes any of these structured outputs is entirely controlled by your Query LLM node’s prompt. If you want the agent to produce a chart alongside its answer, you tell it to in the prompt; you also enable the relevant widget in the Output Tab so the runtime accepts the emission.

Two-step pattern for widgets. For an agent to actually emit a widget, two things must be true. First, on the agent’s LLM node, in the App Experience Tab under “Select Widgets”, the widget type must be enabled. Second, your Query LLM node’s prompt must instruct the agent to use it (“Use a chartWidget when comparing trends; use a messageListWidget for prioritized lists”). Skip either step and the widget never appears.

---

6. Section focus and scoping behavior

From a builder perspective, you do not need to wire section-focus routing yourself — the framework handles the scoping automatically. You just need to make sure each panel’s agent is configured to handle Query hints, the same way the app-level queryAgent is.

---

7. Configuring Ask Oracle in the Builder UI

All Ask Oracle configuration happens in the Builder UI — you never need to hand-edit the appConfig.

---

8. Tone and summary behavior in the Query prompt

The Query LLM node’s prompt is also where you control the personality and shape of every Ask Oracle response. Two dials are worth deliberate attention:

Tone

Tone is set directly in the prompt. “Respond in a concise, analytical voice” produces a different answer than “Respond in a friendly, conversational voice”, which produces a different answer again from “Respond formally; reserve the analytical detail for the supporting display.” Tone is the single fastest way to make an agent’s personality match its domain — the Compliance agent should not sound the same as the Talent agent.

Summary behavior

Each Ask Oracle response can either include a generated summary of the answer up front or skip directly to the direct answer. Both are valid; the choice depends on what makes sense for the agent’s domain and the user’s typical question style. Quick lookups (“who owns Deal X?”) often work better without a summary. Analytical questions (“how has Region 2 performed this quarter?”) usually benefit from a one-line summary above the supporting display.

You toggle this behavior by including or omitting a summary instruction in the Query LLM node prompt.

---

9. Common pitfalls and how to avoid them

Pitfall	What to do instead
Follow-up questions break (“and the next quarter?” gets a generic answer).	Wire $context.$system.$chatHistory into the Query LLM node’s prompt. It is not auto-passed.
The orchestrator routes to the wrong agent.	Rewrite the agent team’s description with specific verbs, nouns, and dimensions. Re-run the same query to confirm.
The agent never appears in the Ask Oracle dropdown in Builder UI.	Open the agent’s Output Tab and turn on Expose to Agentic Apps. Without this toggle the agent is invisible to apps.
The Query agent produces no widgets, only text.	Two-step fix: enable the widget type on the agent’s Output Tab under Select Widgets, and instruct the agent to use it in the Query LLM node prompt.
Responses ignore the user’s identity or the entity in the URL.	Pass $OraUserContext and $OraAppContext into the Query LLM node prompt, and reference them in the instructions.
Two back-to-back questions overwrite each other on the page.	That is the default behaviour — a new response replaces the prior section unless the user pinned it. Tell the user about pinning if they want to keep multiple responses side by side.
Latency feels excessive for a simple question.	Review the Query branch for unnecessary LLM nodes or tool calls. Workflows beat supervisors for predictable latency; aim to stay well under the 60-second response limit.

---

Recap

Ask Oracle is the single most open-ended surface in an agentic app, and the only one driven entirely by an unscripted user prompt. That is what makes it strategically valuable — and what makes it the most demanding feature to configure well.

---