Web grounding

Reviewed: 29 October 2026, against the production configuration.

Web grounding lets a feature search the public web while it works, so an answer can cite current pages. Two kinds exist, and a feature may use either or both:

• Model-side search. The model's own provider runs the search inside the model call: the model decides whether a search would help, writes the query, runs it and cites the results. Which provider's search runs follows from which model is making the call.
• Kumkuat-side search. Kumkuat sends a query it built to a search provider, fetches the pages that come back, and hands their text to the model as evidence. The model never talks to the search provider.
• Kumkuat-run search for a model endpoint. A model endpoint the workspace added itself has no search of its own. When an admin turns on Web search for your own model endpoints, the endpoint's model may ask Kumkuat to search: the model writes the query and decides whether to search, and Kumkuat runs the search and hands the results back to the model. Off by default.

Which search runs

Model-side, by the model's provider

Model provider	Search tool	Governed by
Google Gemini	Grounding with Google Search, inside the Gemini API call	Gemini API Additional Terms, Grounding with Google Search section
Anthropic Claude	Anthropic's web search tool	Anthropic's API terms
OpenAI GPT	OpenAI's web search tool	OpenAI's API terms
A model endpoint the workspace added itself	None by default: Kumkuat sends no search tool to an endpoint. With Web search for your own model endpoints on, Kumkuat offers the endpoint a search tool and runs each search the model asks for as a separate Google Gemini call with Grounding with Google Search, on Kumkuat's Gemini account, or on the workspace's own Gemini key when it has added one; that call receives the query and nothing else	As for Google Gemini above

Which of these run for a workspace follows from the models its features call; the Sub-processors page names the search providers that receive queries today. Kumkuat uses the Gemini API on the paid tier, where Google does not use prompts or responses to improve its products. No provider's search is covered by the Google Cloud agreement that governs Kumkuat's hosting.

Kumkuat-side

Kumkuat sends the query to one of the web and news search providers listed on the Sub-processors page, and tries the next only when the first returns nothing. Each receives a search query and nothing else.

Two boundaries that hold everywhere

• What leaves is a search query, never a workspace document. The sections below say what each query is made from.
• The switch in the table turns searching off, not the choice of model. Naming an OpenAI or Anthropic model under Workspace settings → Models does not stop a feature from searching; a workspace that wants no searches uses the switches below. When a selector names a model endpoint the workspace added itself, its features skip model-side search: audience chat and the scorecard note answer without searching, and persona-context refresh declines questions marked Web search (audience reactions selector); document auto-tags, newsroom discovery and saved search sources skip it (signals selector); narrative research skips it (narrative analysis selector). The Kumkuat-side searches in discovery, saved search sources and narrative research still run. If an admin turns on Web search for your own model endpoints, audience chat, the scorecard note, persona-context questions marked Web search and auto-tags with web search enabled search again on the endpoint, through Kumkuat (see Your own model endpoints); discovery, saved search sources and narrative research do not change. An API request to audience chat that names a model with no search tool, such as GPT-4, runs without search.

Where it is used

Feature	Default	Search	What the query is made from	Who starts it	Switch
Audience chat	On	Model-side	The user's question, as rewritten by the model	A user, each chat turn	Workspace settings → Policy → Web search in audience chat
Persona-context refresh	On for questions marked Web search	Model-side	The grounding question	A refresh, scheduled or started by an admin	The same policy switch
Scorecard note	On when a user asks for it	Model-side	The persona and the document's topic, as the model writes it	A user clicking Why this matters to them on a scorecard, or every reaction if the workspace turns that on	The same policy switch; Kumkuat can also turn the note off for a workspace
Source discovery	On for lookups a person starts	Model-side; saved search sources add Kumkuat-side	The company name or topic, or a saved search query	A user, or onboarding	Workspace settings → Policy → Newsroom pages found by discovery stops background lookups
Narrative research	Off	Model-side and Kumkuat-side	The evidence gaps in the narrative under test, with the company name	A narrative test, when research is enabled	Per workspace or per run, on request
Document auto-tags	Off per tag	Model-side	What the model needs to resolve while extracting the tag	Tagging, when a tag has web search enabled	The tag's Enable web search checkbox
Your own model endpoints	Off	Kumkuat-run, for the endpoint's model	A query the endpoint's model writes from the chat turn, the grounding question or the document being tagged	The endpoint's model, during audience chat, a persona-context refresh, or tagging with a tag that has web search enabled	Workspace settings → Policy → Web search for your own model endpoints, effective only while Web search in audience chat is allowed
Social-profile lookup	Runs only when clicked	X: model-side. LinkedIn: Kumkuat-side	The person's name and outlet	A user clicking Find social profiles	Not switchable; nothing runs unless a user starts it

Audience chat

Talking to a persona is the one place grounding is on by default. The web app asks for it on every turn; a REST or MCP caller chooses per request, and it is off unless the request asks for it; Slack conversations do not ask for it. The model receives the persona profile, the excerpts Kumkuat retrieved from the workspace and the user's question, and may run a search it writes from that question through its provider's search tool. On a model endpoint the workspace added itself, chat searches only through Kumkuat, and only when an admin has turned that on (Your own model endpoints).

A workspace admin or owner turns it off under Workspace settings → Policy.

Workspace settings → Policy → Web search in audience chat. The note says what the switch does not cover.

The switch is enforced on the server at a single decision point, so it overrides the request whether it came from the web app, the REST API or MCP, and whichever provider's model the call runs on. It reaches every Kumkuat server within about a minute, and a conversation already in progress follows it from its next turn. With it off, a persona answers only from its profile, its grounded context and the workspace's stored documents.

The panel summary after the switch is set to Off and saved.

The full list of policy switches is on Workspace policy.

Persona-context refresh

Grounding questions give a persona standing context ("What has this person said about our sector this quarter?"). A question marked Web search is answered with model-side search when it is refreshed; a question without the mark is answered from the persona's linked sources only. The query is the question itself.

The audience-chat policy switch covers these refreshes too: with it off, every grounding question is refreshed without web search.

When the audience reactions selector names a model endpoint the workspace added itself, a question marked Web search is declined rather than answered from the endpoint's memory, unless an admin has turned on Web search for your own model endpoints. With it on, the endpoint may search through Kumkuat, and an answer the endpoint wrote without running a search is still declined, so nothing unsearched is stored as web-grounded context.

Workspace settings → Grounded context. The panel says which questions search the web and points to the Policy switch that turns it off.

Scorecard note: why this matters to them

A persona reaction scorecard can close with a note, Why this matters to them, on why the document's topic matters to that audience. It is written with a model-side search: the model receives the persona's name and description and the document's title, type, executive and an excerpt, writes its own queries about the topic, and cites what it finds. The query is never the document itself.

The note is generated when a user asks for it on the scorecard. A workspace can also have it generated with every reaction; that is off by default. It runs on the model the Audiences selector names, and on a model endpoint the workspace added itself it runs without search unless Web search for your own model endpoints is on. It passes through the same decision point as audience chat, so Web search in audience chat: Off stops its searches too, and Kumkuat can turn the note off for a workspace altogether.

Source discovery

When a user looks for a company's newsroom page, during onboarding or from Comms Sources → Discover newsrooms, the lookup runs a model-side search with the company name or topic. The results are candidate pages; nothing from the workspace is sent.

A knowledge base search source a user creates runs its saved query on a schedule, as model-side and Kumkuat-side searches.

Onboarding can also attach the best newsroom it finds without a person choosing it. Workspace settings → Policy → Newsroom pages found by discovery set to A person chooses stops those background lookups; a lookup a person starts still searches.

Narrative research

A narrative test can supplement the workspace's own evidence with recent public announcements. This is off by default: a test stays on workspace evidence unless research is enabled for the workspace, or for a single run through the API. When it is on, the queries are written from the evidence gaps the test found, together with the company name, and run as model-side and Kumkuat-side searches. The candidate articles are shown as evidence in the report.

Document auto-tags

An auto tag extracts a value from each document. A tag can have web search enabled so the model may look up what the document does not say, such as a company's headquarters. The option is off for every new tag and applies only to that tag. The search runs only when the tag runs on a Google Gemini model, the default for tagging; a tag set to another provider's model runs without search. On a model endpoint the workspace added itself, the tag runs without search unless an admin has turned on Web search for your own model endpoints; then the endpoint's model may search through Kumkuat.

Library → Auto tags → tag editor. Off unless an admin ticks it for that tag.

Your own model endpoints

A workspace that adds its own model endpoint under Workspace settings → Models & provider keys usually does so to keep its content on its own infrastructure, and an endpoint has no web search of its own. So by default Kumkuat sends no search tool to an endpoint, and the features that run there answer from what the model already knows.

An admin or owner can turn on Workspace settings → Policy → Web search for your own model endpoints. It takes effect only while Web search in audience chat is allowed; turning that switch off stops these searches too. With both on:

• In audience chat, the scorecard note, a persona-context refresh of a question marked Web search, and tagging with a tag that has web search enabled, the endpoint is offered one search tool. Your endpoint must accept tool calls in the OpenAI format; one that does not answers without searching, as if the setting were off.
• The endpoint's model decides whether to search and writes the query. Kumkuat runs at most three searches per reply, within the time the feature already allows, and returns the results to the model, which writes the answer. Kumkuat searches only when the model asks; it adds no searches of its own.
• Each search is a separate model-side search on a Google Gemini model (the Google Gemini row in the table above), on Kumkuat's Gemini account, or on the workspace's own Gemini key when it has added one under Models & provider keys. That call receives the query the endpoint's model wrote and nothing else: not the conversation, the persona, the document or the excerpts Kumkuat retrieved. Turning this on therefore means the Google Gemini model provider receives search queries even when every feature runs on your endpoint.

Workspace settings → Policy → Web search for your own model endpoints. Off unless an admin turns it on.

Social-profile lookup

On a persona, Find social profiles looks for the person's public profiles by searching with their name and outlet: a model-side search for X and a Kumkuat-side search for LinkedIn. Nothing runs until a user clicks it, and what it finds is a suggestion the user confirms or discards.

A persona's Suggested links. The lookup runs only on the click, and applies nothing until confirmed.

A workspace that sends nothing to a search provider

Four settings, all available today:

1. Workspace settings → Policy → Web search in audience chat: Off. Covers chat from the web app, the REST API and MCP, the persona-context refresh and the scorecard note.
2. Workspace settings → Policy → Newsroom pages found by discovery: A person chooses. No background lookups.
3. Leave narrative research off (its default).
4. Create no auto tag with web search enabled (the default for every tag).

Web search for your own model endpoints stays off by default, and with step 1 it has no effect.

After that, a search happens only when one of your own users starts a newsroom lookup, creates a saved search source, or clicks Find social profiles. Kumkuat can apply these at workspace creation and show you the Policy panel summary.

Evidence

• The Policy panel for your workspace, which summarises the current settings at the top.
• A record per model call. Every audience-chat call is recorded with the grounding decision, true or false, alongside the workspace, user, feature, provider and model; persona-context refreshes and discovery lookups likewise; the scorecard note is not in that record today. Kumkuat can produce a per-workspace count of grounded and ungrounded calls for any period, by provider, the same audit described on Model provider controls.
• For a model endpoint that searched through Kumkuat, the call's record also says that Kumkuat ran the search, whether the answer was grounded and how many searches ran, and each search is recorded as its own call, with the length of the query but not its text.
• A log line whenever a model provider or a model endpoint refuses the search and the reply goes out without it.

Related pages

• Workspace policy, the switch and what it covers, and Web search for your own model endpoints
• Audience chat
• Model provider controls, including turning a provider off
• Data flow, what each search receives
• Sub-processors, the model-side and Kumkuat-side search providers
• API reference: interact with a persona, the per-request grounding field and the policy that can override it