Giving Agentforce the open web: the Search the Web action, and the questions it should never answer from memory

Here’s the failure mode that shows up two weeks after go-live, not in the demo. A customer asks your service agent something reasonable (“is the port in Long Beach still backed up?”, “what’s the new EU rule on this?”, “did your competitor really get acquired?”) and the agent, grounded flawlessly on your own knowledge base, says some version of I don’t have that information. It’s not wrong to say so. But it’s a bad look, and it’s the exact moment a human would have Googled it in three seconds.

Agentforce’s answer is the Search the Web action: a standard, out-of-the-box action that lets an agent run a live web query and use the results as grounding for its reply. It’s the piece that turns “I can only answer from what you loaded into me” into “I can answer from what you loaded into me and what’s true on the internet right now.” That’s a genuine capability jump. It’s also, if you’re honest about it, the least governed sentence your agent will ever produce, because for the first time the grounding is coming from a source you don’t own, didn’t curate, and can’t fully predict.

This post is the practitioner’s read on the Search the Web action: what it does, how it routes through the Einstein Trust Layer, the two configuration levers that decide whether it’s safe, what it costs per invocation, and the design rule that keeps it from becoming a hallucination amplifier.

What the action is

Most Agentforce grounding is internal. The Data Library indexes your PDFs and knowledge, retrievers fetch the right chunks, Intelligent Context reads your documents, all of it pointed at data you put there on purpose. Search the Web is the first grounding source that points outward, at the live public internet.

Mechanically, it’s a standard action you add to a topic in Agent Builder, backed internally by a streaming web-search capability (the platform names the underlying action webSearchStream). When the Atlas reasoning engine decides the user’s question can’t be answered from the agent’s existing knowledge, it can invoke the action, which issues a query to a search provider, pulls back results, and, this is the important part, hands those results to the model as grounding context rather than pasting raw links into the chat. The model reads the retrieved snippets and composes an answer from them, the same way it would from a retrieved knowledge chunk. Done well, it can even cite what it used; Salesforce’s developer team published a full walkthrough of a cited web-search agent that returns source links alongside the answer.

The feature matured on a beta track, the OpenAI-backed web results went through beta around the start of 2026 and hardened through the Summer ‘26 release, so if you’re reading this on an older org, check the release readiness of your instance before you promise it to a stakeholder.

The mental model that keeps you out of trouble: Search the Web is not “let the agent browse.” It’s “let the reasoning engine retrieve from the open web the same way it retrieves from your knowledge base, then answer from what it retrieved.” Everything good and everything dangerous about the feature follows from that one sentence.

How it routes: the Trust Layer is doing real work here

The instinct with any “agent calls the internet” feature is to worry about two things: what leaves your walls, and what comes back. The Search the Web action addresses the first directly by routing through the Einstein Trust Layer. The query the agent sends to the provider passes through Salesforce’s secure AI gateway, and the provider (OpenAI, in the default configuration) operates under Salesforce’s terms, meaning your search text is not retained by the provider or used to train its models. That is not a small detail. A naïve DIY web-search integration would ship your customers’ phrasing straight to a third party under that provider’s consumer terms; the Trust Layer is the difference between “governed retrieval” and “data exfiltration with extra steps.”

What the Trust Layer does not do is vouch for the content that comes back. Toxicity and PII masking apply on the pathways the platform controls, but the open web is still the open web. A result can be outdated, wrong, or adversarial, and once it’s in the grounding context the model will treat it as evidence. This is the asymmetry to internalize: the Trust Layer secures the transport, you are still responsible for the trust.

The two levers that decide whether it’s safe

The standard action exposes a small number of inputs, and two of them are the whole ballgame.

searchProvider selects which engine runs the query. OpenAI is the provider most teams start with because it’s the default and it’s the one wired through the Trust Layer path described above. Treat the provider choice as a governance decision, not a performance one. You’re choosing whose index and whose safety posture your agent inherits.

siteFilter is the lever almost nobody uses on day one and almost everybody wishes they had by week three. It restricts the search to a list of domains, up to ten, comma-separated. Set it, and “search the web” becomes “search these sites,” which is a completely different risk profile. A conceptual view of the action’s configuration:

Action: Search the Web
  searchProvider: openai
  siteFilter: "faa.gov, iata.org, yourbrand.com, status.yourbrand.com"
  query: <the user's question, passed by the reasoning engine>

The difference between those two configurations is the difference between a demo and a production deployment:

• No siteFilter, the whole open web. Fine for an internal research assistant where a knowledgeable employee is reading critically. Reckless for a customer-facing agent that speaks with your brand’s authority.
• siteFilter set to a curated allowlist, the agent can only ground on sources you trust. This is how you get the freshness of the web without inheriting its garbage. Your own status page, the relevant regulator, the standards body, a trade publication you’d cite in a memo.

If you take one configuration decision away from this post: a customer-facing Search the Web action without a siteFilter is a liability, not a feature. Scope it to an allowlist of domains you would be comfortable quoting in writing, because that is exactly what the agent is about to do.

The design rule: knowledge first, web as fallback

The most common, and most correct, pattern is to make web search the fallback, not the default. Your own knowledge base is curated, current for the things you control, and free of the open web’s failure modes. So the topic design you want is: answer from knowledge when knowledge has the answer, and only reach for the web when it doesn’t.

You express this in the topic’s instructions, which is where a lot of teams under-invest. Instructions are how you tell the reasoning engine when a tool is appropriate, a point we’ve made before about why agents pick the wrong topic. A workable instruction for a topic that carries both a knowledge action and the web action looks like this:

You answer product and policy questions.

- First try to answer from the company knowledge base.
- Only if the knowledge base has no relevant answer, and the question is
  about a current external event, regulation, or third-party fact, use
  Search the Web.
- When you answer from the web, state that the information came from an
  external source and cite the site you used.
- Never use Search the Web to answer a question about the customer's own
  account, orders, or entitlements, those come from system-of-record
  actions only.

That last line matters more than it looks. The web action should never be the thing that answers “where is my order”. That’s a governed record-grounded action hitting your system of record. Web search is for facts about the world, never facts about the customer. Keeping those two lanes separate in the instructions is how you stop the agent from doing something creative under pressure.

When to reach past the standard action

The standard action is deliberately narrow, and for most service and employee use cases that’s exactly right. But there are cases it doesn’t cover. You want a provider it doesn’t offer, you need to post-process results against a proprietary ranking, or you want to blend web results with a live internal API in one step. That’s when you drop to a custom Apex action, the same escape hatch we’ve written about for Apex-backed agent actions and the broader MCP tool pattern.

The skeleton of an invocable action that fronts an external search API (and returns structured, citable results the agent can ground on) is ordinary Apex:

public with sharing class WebSearchAction {
    public class Request {
        @InvocableVariable(required=true)
        public String query;
        @InvocableVariable
        public String allowedDomains; // comma-separated allowlist
    }

    public class Result {
        @InvocableVariable public String answerContext;
        @InvocableVariable public String citations;
    }

    @InvocableMethod(label='Search Curated Web' description='Grounded external search over an allowlist')
    public static List<Result> search(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request req : requests) {
            HttpRequest httpReq = new HttpRequest();
            httpReq.setEndpoint('callout:Search_Provider/search');
            httpReq.setMethod('POST');
            httpReq.setHeader('Content-Type', 'application/json');
            httpReq.setBody(JSON.serialize(new Map<String, Object>{
                'q' => req.query,
                'sites' => req.allowedDomains
            }));
            HttpResponse res = new Http().send(httpReq);

            Result r = new Result();
            if (res.getStatusCode() == 200) {
                // Shape the provider payload into grounding text + citations.
                r.answerContext = res.getBody();
                r.citations = 'see Named Credential response';
            } else {
                r.answerContext = 'No external results available.';
            }
            results.add(r);
        }
        return results;
    }
}

Two things make this the exception, not the rule. First, you’re now outside the Trust Layer’s managed web path, so you own the data-handling terms with whatever provider sits behind that Named Credential, read them. Second, the description on that @InvocableMethod is the text the reasoning engine reads to decide when to call your action; as with any custom action, the description is the code that matters most. A vague description gets your expensive custom search invoked at the wrong moments.

What it costs, and why that shapes the design

Search the Web is metered like any other agent action. On the Flex Credit model, a standard action consumes 20 Flex Credits. $0.10 at list price, given a 100,000-credit pack lists at $500. That sounds trivial until you remember the reasoning engine can chain actions: a single “what’s the latest on X, and does it affect my order” turn might fire a web search, a knowledge lookup, and a record retrieval, and you’re paying for each. We laid out the full arithmetic in the Flex Credits pricing breakdown, and the takeaway applies squarely here: an action you invoke by default on every turn is a very different line item than one you invoke only as a fallback.

That’s another reason the knowledge-first design isn’t just about answer quality. It’s about cost. An agent that reaches for the web only when its own knowledge comes up empty invokes the paid action a fraction as often as one that searches the web on every question. Good governance and a defensible invoice turn out to be the same design decision.

The honest limitations

A few things to set expectations on before you promise this to a stakeholder:

• Freshness is the provider’s freshness, not real-time. A search index has crawl latency. For “what’s the absolute latest” questions on fast-moving events, the agent is only as current as its provider’s last crawl, which is usually good enough, occasionally not, and never a substitute for a live status API you own.
• siteFilter caps at ten domains. If your trusted-source list is longer than ten, you’re either prioritizing or building the custom path. Ten is generous for most curated allowlists and a real constraint for a few.
• It grounds; it doesn’t verify. The model composes a fluent answer from retrieved snippets. If two sources on your allowlist disagree, or one is stale, the agent won’t necessarily flag the conflict. Web search reduces “I don’t know” hallucinations; it does not eliminate “confidently wrong from a bad source.”
• Customer-facing use raises the prompt-injection surface. A page in the retrieved results can contain adversarial instructions. The Trust Layer and Atlas mitigate a lot, but an allowlist of sources you control is still your best defense, one more reason siteFilter isn’t optional in production.

The takeaway

Search the Web fixes a real, visible gap: the grounded agent that goes quiet the moment a question touches the world outside your org. Turned on thoughtfully, it’s the difference between an assistant and a form with a personality.

Turned on carelessly, it’s the fastest way to have your brand confidently repeat something wrong from a random web page. The whole distinction lives in three decisions: set a siteFilter to an allowlist you’d quote in writing, make the web a fallback behind your own knowledge in the topic instructions, and never let it answer questions about the customer’s own account. Get those three right and you’ve added the open web to your agent without handing it the open web’s problems.

If you’re weighing where web grounding fits against your existing knowledge and retriever setup, the Data Library and retrievers posts cover the internal side of the same grounding decision, and our Agentforce ROI calculator can help you sanity-check whether the deflection you’d gain justifies the per-action cost.