Prismfy + LangChain: When to Use Web Search Instead of a Retriever

This tutorial focuses on a production-friendly search integration pattern, so developers can add a web search tool, fresh public evidence, and better routing logic without overbuilding retrieval.

Problem framing

LangChain makes it easy to wire a retriever into an agent, but a retriever is only as current as the corpus behind it. That works well for stable documents and internal knowledge. It breaks down when the answer depends on what changed on the public web this week.

Prismfy fits that gap. It gives your LangChain app one synchronous POST /v1/search call for fresh public-web evidence. You keep the retriever for stable text. You add Prismfy when the question depends on public sources that can change without notice.

The practical mistake is to use one retrieval path for every question. If you send everything to the vector store, your agent will answer quickly but may be stale. If you send everything to live search, you will add noise and unnecessary cost. The better design is a router that chooses the source based on the question.

Why this matters now

Search-oriented agent apps are getting more specific, not less. Teams do not just want “answers.” They want answers grounded in a current source of truth. In practice that means:

• product docs that may update after your last index build
• pricing pages that change without versioning
• release notes that make old embeddings misleading
• standards, API docs, and policies that are revised in place

If you rely on a retriever for those cases, you are assuming the corpus is fresh enough. That assumption often fails silently.

Step-by-step solution

The right pattern is to treat LangChain as the orchestration layer and Prismfy as the live evidence layer.

1. Classify the question.
2. Use the retriever for stable, internal, or already-indexed material.
3. Use Prismfy for time-sensitive public evidence.
4. Normalize the results into a small evidence bundle.
5. Let the model synthesize only from that bundle.

That split keeps the system understandable. A retriever answers “what did we already know?” Prismfy answers “what does the public web say now?”

Code example

The code below uses a small LangChain tool that calls Prismfy directly. It returns a compact evidence block rather than the full JSON response.

import os
import requests
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI

PRISMFY_API_KEY = os.environ["PRISMFY_API_KEY"]
PRISMFY_BASE_URL = os.getenv("PRISMFY_BASE_URL", "https://api.prismfy.io")

@tool
def prismfy_search(query: str, domain: str = "", time_range: str = "week") -> str:
    """Search the live web through Prismfy and return compact evidence."""
    payload = {"query": query, "page": 1, "timeRange": time_range}
    if domain:
        payload["domain"] = domain

    response = requests.post(
        f"{PRISMFY_BASE_URL}/v1/search",
        headers={
            "Authorization": f"Bearer {PRISMFY_API_KEY}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    data = response.json()

    lines = [f"cached={data.get('cached', False)}"]
    for item in data.get("results", [])[:4]:
        lines.append(f"- {item['title']} | {item['url']}\n  {item.get('content', '')[:180]}")

    return "\n".join(lines) if len(lines) > 1 else "No live web results returned."

llm = ChatOpenAI(model="gpt-5.4-mini", temperature=0).bind_tools([prismfy_search])

That tool is intentionally small. It accepts a query, optionally narrows the search to one domain, and defaults to a freshness window. In a real LangChain app, the model can decide whether to call the tool, and your app can decide how to merge the result with the retriever output.

If you want a more explicit router, make a simple rule set:

• if the question is about your own stable docs, use the retriever
• if the question is about a public page that may have changed, use Prismfy
• if the question blends both, call both and compare the evidence

That is often enough to avoid overcomplicating the agent graph.

Practical notes and caveats

Prismfy is not a replacement for your retriever. It is a live web search API that complements one. Keep the responsibilities separate or you will end up with a prompt that mixes stale local text and fresh public evidence without any way to tell them apart.

It is also worth keeping the evidence set short. LangChain can handle a lot of tool output, but your model usually answers better when you pass only the top few URLs and snippets. More search results is not the same as better retrieval.

Use domain when a single source owns the truth. Use timeRange when freshness matters more than breadth. If the search results are thin, the right behavior is to ask a narrower question, not to invent certainty.

Why Prismfy fits this workflow

Prismfy fits LangChain because the API boundary is clear. The agent owns reasoning. Prismfy owns public-web retrieval. The search step is synchronous, so the tool call is easy to inspect in logs and easy to replay during debugging.

That is the right shape for a production agent. You do not want hidden search behavior inside the prompt. You want a visible request, visible results, and an explicit decision about whether those results are strong enough to answer from.

FAQ

Why use a web search API instead of only a retriever?

A retriever is useful for indexed material you control. A web search API helps when the question depends on fresh public evidence, new pages, current docs, or time-sensitive changes that may not exist in your retriever yet.

What is the safest way to add LangChain Web Search Tool?

Keep the integration narrow: route only freshness-sensitive questions to Prismfy, pass a compact evidence set back to the framework, and ask the model to answer from sources instead of memory.

Related Prismfy guides

• Prismfy + LlamaIndex: Use Fresh Web Evidence in RAG
• Build an MCP Search Tool with Prismfy
• Add Real-Time Web Search to an OpenAI Agent Workflow with Prismfy

Try Prismfy

Create a Prismfy key, test POST /v1/search, and wire the search step into the workflow you care about first.