Tool Recommendations via Grounded Search: How LucidFlow Avoids the LLM Hallucination Trap

Ask a generic LLM which tool to use for a specific business process and you get confident recommendations with a predictable failure pattern: the model recommends tools that were best-in-class two or three years ago (the vintage of its training data), quotes pricing that is out of date or fabricated, and cites product URLs that either redirect, 404, or point to a completely different product. Even frontier models do this, because the recommendation task itself is inherently temporal: the right answer changes every quarter as new tools ship, incumbents raise prices, and categories consolidate. No amount of scale fixes a training-data vintage problem.

The concrete failure mode we audited in the LucidFlow Knowledge Base before shipping the grounded-search layer: models would recommend RPA platforms from 2022 for tasks where a 2025-vintage AI-native competitor has explicitly taken the category, quote yearly pricing based on 2023 public pricing pages that have since moved behind enterprise-sales walls, and confidently cite URLs that were the vendor's product page three years ago but are now a redirect to a generic homepage. The recommendations read as authoritative because the model is good at writing authoritative prose. They fail as actual product-selection guidance.

The LucidFlow tool-recommendation layer uses Gemini 3.1 Pro with Google Search grounding as its primary provider. The model is invoked with `tools: [{ googleSearch: {} }]` in the generation config, which enables Gemini to run real-time web searches during the response and ground its output in the pages it retrieves. The prompt explicitly instructs the model to SEARCH pricing pages before recommending rather than rely on memory, and to set the maturity field to 'new' for tools launched within the last 18 months rather than anchoring on the pre-training-cutoff incumbents.

The grounding metadata returned from each call is logged: the web search queries the model executed and the retrieved URLs (grounding sources) that informed the answer. This is what makes the recommendation auditable. A reviewer can inspect the logs and see that for a given recommendation, the model searched the literal string 'best automation tools for accounts payable enterprise 2025 2026', retrieved three specific product pages plus a G2 review, and produced its recommendation from that evidence. The reviewer can then verify the sources before signing off. A recommendation that would have been untrustworthy from a generic LLM becomes auditable through the grounding layer.

Technical parameters: the grounded-search call uses the Gemini 3.1 Pro preview model with a 60-second timeout (longer than the standard Gemini timeout because grounded search inherently needs more time) and a low generation temperature of 0.2. The 0.2 temperature is deliberate: high enough to surface non-obvious tools the model might otherwise overlook, low enough to keep the output factual and reproducible across calls. The response is validated against a Zod schema that requires a monthly pricing range with explicit min/max, a pricing model string, a maturity enum ('new' | 'established'), and an alternatives array with two to three alternatives each carrying their own price range and reasoning.

Grounded search is the primary provider, but it cannot be the only one. Real-time web search can fail for mundane reasons: API rate limits, transient network errors, timeouts on unusually broad queries, and the recommendation layer needs to remain useful even when the primary fails. The tool-recommendation layer implements an explicit three-tier fallback chain, with each tier chosen to preserve as much recommendation quality as possible while degrading transparently when the higher tier is unavailable.

1. Primary: Gemini 3.1 Pro + Google Search grounding. Real-time web data, auditable via grounding metadata. This is the default path and handles the vast majority of production calls.
2. Fallback: Grok. Uses training data rather than real-time search, so it may have some incumbency bias, but it is still a capable recommender and its training data is relatively recent. Activated when the Gemini primary call fails with a retryable error. A Grok availability check gates this: if Grok is also unavailable, the chain skips to the last-resort tier.
3. Last resort: graceful degradation. Returns an empty tool list with an explicit 'tools unavailable' flag rather than fabricating recommendations. The UI then surfaces this state explicitly, showing the rest of the transformation analysis (maturity levels, savings, ROI) without tool suggestions. This is the right behaviour because a missing recommendation is more honest than a hallucinated one.

A subtle architectural choice in the tool-recommendation layer: it makes ONE LLM call per process, not one call per task. The system prompt explicitly frames the model's job as thinking holistically: 'These tasks form a given workflow. Can ONE platform handle multiple tasks?' The prompt actively pushes the model toward consolidated platforms: 'A consolidated platform that is good enough at each task beats 4 best-in-class tools that require complex integration.' This is the enterprise best practice, and it falls out of the design rather than being applied after the fact.

The practical consequence: a process with ten automatable tasks usually comes back with two or three tool recommendations rather than ten, each recommendation mapping to multiple tasks. A modern AI-native accounts-payable platform might cover five tasks with one subscription; a document-understanding API plus a workflow engine might cover the rest. This is closer to how a real transformation actually gets implemented: teams buy platforms, not point tools, and it surfaces the integration cost trade-off explicitly rather than hiding it behind a long list of individual-tool recommendations.

First-principles thinking baked into the prompt

One more underrated detail: the prompt instructs the model to consider the entire process holistically, including tasks marked not_automatable. A task might be 'not_automatable' in the static pattern-matcher's view but eliminatable by a modern platform: an automated-approval system removes the need for manual review entirely, for example. The prompt allows the model to include 'not_automatable' tasks in a recommendation and explain in the reasoning why the tool can eliminate the task. This catches the case that task-level recommendation would always miss: sometimes the right answer is not automating the task but removing it.

Every recommendation returned by the grounded-search path conforms to the same Zod-validated schema. The shape is worth reading once because it shows what the platform actually commits to surfacing for each recommendation, not claims in prose, but structured fields.

const toolRecommendationSchema = z.object({
  recommendations: z.array(
    z.object({
      taskIds: z.array(z.string()),
      toolName: z.string(),
      description: z.string(),
      reasoning: z.string(),
      monthlyPrice: z.object({ min: z.number(), max: z.number() }),
      pricingModel: z.string(), // "per seat" | "flat rate" | "usage-based" | ...
      url: httpsUrlSchema, // HTTPS only; non-HTTPS falls back to empty string
      maturity: z.enum(['new', 'established']),
      alternatives: z.array(
        z.object({
          name: z.string(),
          url: httpsUrlSchema,
          monthlyPrice: z.object({ min: z.number(), max: z.number() }),
          reasoning: z.string(),
        })
      ),
    })
  ),
});

Three properties worth highlighting in that schema. First, the URL field uses HTTPS URL validation: a transform that returns an empty string for non-HTTPS URLs rather than propagating insecure links into the product. Second, the pricing model is a free-text string rather than an enum because pricing models vary in ways an enum cannot capture (per-seat-with-volume-discounts, per-execution-with-monthly-cap, usage-based-with-minimum, etc.). Third, the alternatives array is required and non-empty by convention: the prompt instructs the model to include one to two alternatives with their own price ranges and reasoning, because a recommendation without alternatives is a sales pitch rather than an analysis. The schema does not force non-empty alternatives, but the prompt design ensures they arrive.