# Cloudflare web search and bounded fetch for SaaS agent research workflows

> Add web research to a SaaS agent with selected sources, bounded fetches, clear provenance, and safe request limits.
> By Dave · 2026-10-14
> Source: https://otf-kit.dev/blog/cloudflare-agent-search-fetch-flow

An assistant that can search the web is useful only if it can bring back the right evidence. Give it unrestricted page fetching, though, and a simple research question can turn into a large, noisy prompt—or a request to a host your app never meant to contact.

Cloudflare’s Agents SDK now documents a paired `web_search` and `web_fetch` workflow. Search can return a short numbered set of titles, URLs, and descriptions; fetch can read selected pages and return bounded text with response details. The implementation decision is how your application chooses results, limits each request, and presents source provenance to the user. The wrappers help with that work, but they do not guarantee that retrieved content is safe or true.

For a SaaS assistant, the useful pattern is narrow: ask a focused question, search for a small number of relevant pages, select only the results worth reading, fetch them under application-defined limits, and show the resulting source URLs and statuses. Keep the fetched material separate from trusted system instructions. That gives the user a reviewable research trail instead of an opaque answer backed by a large context dump.

## Turn search results into a deliberate reading list

Start with the user’s actual decision. “What changed in the latest release?” needs a different query from “Which option supports our deployment constraint?” A vague query usually returns a list that is harder to assess and easier for an agent to over-trust. Ask the model to state the question it is trying to answer, then issue a search with a modest result limit appropriate to that task.

The search tool returns structured result descriptions, not proof that every result is relevant or authoritative. Before fetching, have the application or agent inspect the title, host, and snippet. Prefer the vendor’s documentation for product behavior, a primary announcement for release details, and a first-party policy page for rules. A search result can point to commentary, an obsolete page, or a copy that omits important conditions. Treat it as a candidate source.

Selection is a useful place to make the workflow visible. Show the chosen URLs, and let the user remove a result when the assistant’s interpretation of the question is off. For automated flows, record why each result was selected and preserve the original URL. If the source redirects, keep the final URL returned by the fetch step as well; that is the address whose content the model actually received.

This creates a small evidence set. The goal is not to fetch the maximum number of pages. It is to answer the buyer’s question from enough trustworthy material that a person can check the key claims. If the initial results are weak, revise the query or say that the evidence is thin rather than broadening access without a reason.

## Bound the fetch operation in application code

Cloudflare’s `web_fetch` tool can convert HTML, PDF, and supported Office documents into readable text, request Markdown from sites that support it, and format JSON. Long pages are returned in windows that can be continued with an offset. Results include details such as final URL, HTTP status, content type, and character counts. Those fields let your application report what it read and whether the source response was successful.

Set the request policy when you create the tool. Cloudflare documents controls for allowed hosts, blocked hosts, response bytes, timeouts, redirects, and the number of characters returned in one window. Use the narrowest policy that fits the product. A research assistant that should read your own documentation and a few approved vendor domains does not need permission to fetch every public host on the internet.

Allowlisting is a policy boundary, not a substitute for validating the task. Check redirect destinations as part of the effective policy, and keep private or local hosts unavailable unless your product has a specific, reviewed reason to reach them. Enforce byte and timeout limits so a slow or unusually large response cannot consume unbounded resources. If users can request arbitrary domains, decide explicitly how that access is mediated and logged rather than inheriting a permissive default by accident.

The response window also matters. A long page may contain one section that answers the question and many that do not. Use the returned offset to request another portion only when the first window shows that more text is needed. Keep each continuation tied to the same source and task, and stop when you have enough evidence. This helps keep context manageable and makes it easier to explain which portion informed the answer.

![Luna, Byte, Dex, and Nova inspect approved source cards passing a physical host gate; a long page is shown through successive narrow reading windows, with an outside source held back.](https://cdn.otf-kit.dev/blog/cloudflare-agent-search-fetch-flow/inbody1-20261014a.webp)

*Use a host allowlist and cap each read; continue to another bounded page window only when needed.*

If a fetch fails, preserve the structured failure details for the application and show a clear status to the user. A timeout, unsupported file, blocked host, or ordinary HTTP error should not silently become an empty “source.” The agent can retry a correctable input or use another selected source, but the UI should distinguish a failed read from a successful page with little relevant content.

## Treat page text as untrusted input

Retrieved pages can contain instructions aimed at the model. A web-fetch wrapper can label the returned page as untrusted content, but Cloudflare explicitly does not describe that wrapper as a prompt-injection guarantee. Your application still has to preserve the distinction between trusted instructions and text gathered from the public web.

Keep fetched text inside a clearly marked data field in the model’s request. Tell the assistant to use it as evidence to summarize, not to obey commands found in it. Do not let a page change tool permissions, redefine the user’s request, or authorize unrelated actions. For consequential operations, require a separate confirmation path that is independent of whatever a page says.

The assistant should cite claims to the final source URL and make uncertainty visible. A source can be reachable and still be outdated, incomplete, or irrelevant. Keep the fetched status and content type alongside the citation, and avoid turning an HTTP 200 into an assertion that the source is authoritative. If two pages disagree, surface the disagreement and its sources instead of hiding it in a single confident summary.

![Dex, Luna, Byte, and Nova review source pages kept in an amber evidence tray, physically separated from a blue trusted-instructions notebook; the source trail remains visible as they inspect the material.](https://cdn.otf-kit.dev/blog/cloudflare-agent-search-fetch-flow/inbody2-20261014a.webp)

*Treat retrieved page text as untrusted evidence, not instructions; check sources and keep provenance separate from trusted instructions.*

For a broader example of separating durable application state from a live browser session, see our guide to [recovering browser tasks across agent turns](/blog/cloudflare-agents-browser-session-recovery). The same design habit applies here: retain the evidence your app needs to explain a result, while treating remote content as something to inspect rather than trust by default.

## Make the workflow reviewable in a SaaS product

Before launch, test the path with ordinary pages, a long document that needs a second window, an unsupported content type, a redirect, a slow response, and a host outside the allowlist. Verify that every case produces a meaningful status and that the assistant can continue from an alternate selected source when appropriate. Use synthetic or public material for tests; do not place customer secrets in URLs or fetched prompts.

Log the query, selected source URLs, final URLs, response status, content type, and whether the fetch completed or continued. Apply your privacy and retention policy to query text and page content. If a user asks for a report later, these records let you answer which sources were used without storing a full copy of every page indefinitely.

Give users a compact evidence panel with the question, selected sources, read status, and citations. They should be able to open a source directly and see when the assistant could not read it. For teams, an owner can review the host policy, byte limit, timeout, and redirect rules in one place. That turns a capability demo into an operational feature that can be supported and audited.

The [SaaS Dashboard kit](/templates/saas-dashboard) can serve as an optional editable UI and account shell for a research workspace. It does not include Cloudflare’s Agents SDK, web search, web fetch, source allowlisting, or this integration. Teams still need to implement the model tools and request policy themselves.

## A practical rollout checklist

1. Define the buyer task and the source domains the feature is intended to read.
2. Search for a small set of candidate pages and inspect their hosts before fetching.
3. Configure host restrictions, redirect checks, byte limits, timeouts, and a bounded text window in the application.
4. Fetch only the selected sources; continue through offsets only when the answer needs more of a page.
5. Preserve final URLs and response details, and show users which sources succeeded or failed.
6. Keep web text in an untrusted-data boundary and require separate authorization for consequential actions.
7. Test redirect, timeout, content-type, and pagination cases before enabling the feature for customers.

This flow makes web research more controlled, but it does not make the model’s conclusions automatically correct. The application decides where the agent may read, how much content enters context, and what evidence the user can inspect. Keep those choices explicit, test the failure paths, and give the assistant permission to say when the available sources do not answer the question.

## Sources

- [Cloudflare Agents SDK: Web fetch](https://developers.cloudflare.com/agents/tools/web-fetch/) — Cloudflare documentation, last updated October 12, 2026; checked October 14, 2026.