What ‘it can browse the web’ actually means

The loop underneath the feature list

When a product says the assistant can search the web, run code, read your files or send an email, one mechanism is doing all of it. The product describes a set of tools to the model: name, purpose, what arguments each takes. The model, instead of answering, can emit a request to call one. The product runs it, puts the result back into the conversation, and asks the model to continue. Round and round until the model produces a final answer.

Three things follow, and they explain nearly every disappointment people have with these features.

The model decides whether to call the tool. It is not a rule; it is a judgement made from the tool description. This is why a model sometimes answers a current-events question from memory when search was available, and gets it wrong. It did not fail to search. It decided not to.

Whatever the tool returns goes straight into the context as text. If the search returns three pages of search-engine slop, the model is now reasoning over three pages of slop. Garbage in the tool result is garbage in the answer, and the model has no independent way to know it.

Each round trip costs tokens and time. A five-step tool sequence is five model calls with a growing conversation each time. This is why agent-ish features feel slow and why they cost more than they look.

The four tools you will actually meet

Web search. The product runs a query on a search engine, pulls the top few results, and feeds in extracts. Quality is bounded by the search engine, not the model. Ask about something where the top results are marketing pages and you will get marketing.

Code execution. A sandbox (usually Python) where the model writes and runs code and reads the output. Excellent for arithmetic, data files, charts and format conversion, because the answer is computed rather than recalled. Two limits catch people: the sandbox usually has no internet access, so it cannot install a library or fetch a URL, and it is wiped between sessions, sometimes between messages.

File retrieval. Your uploaded documents are chunked, indexed and searched for each question. This is the mechanism behind the long-document behaviour from two lessons ago.

Connectors. Access to your mail, calendar, drive, repository, ticket system. This is where tool use stops being convenient and becomes a decision about permissions, because a connector granted read access to your whole drive has read access to your whole drive.

Checking what actually happened

Good products show their working. Before you trust an answer that involved a tool, look for:

• A list of tool calls you can expand. If you can see the query it searched and the pages it opened, you can judge the sources yourself.
• Citations that link to real pages. Click one. Models can produce a citation that looks right and points nowhere, and a product that formats citations without verifying them will pass that straight through.
• The code, not just the chart. If it computed something, read the four lines. This is where wrong column names and silently dropped rows show up.

If a product gives you none of these, you are being asked to trust the tool layer on faith, and the tool layer is the part most likely to have failed.

Free paths

You do not need a paid tier to have tool use. Open front-ends like Open WebUI and LibreChat support web search and code execution against whatever model you point them at, including a local one. Jupyter with a free API key gives you the code-execution pattern with far better visibility, because you can see and edit every line. For search specifically, SearxNG is a free, self-hostable search backend that several of these front-ends accept.

The judgement to make

Tool access changes what a tool is for more than model quality does. A middling model that can read your actual files and run actual code is more useful for real work than an excellent model answering from memory, because most work questions are about your material rather than about the world.

But every tool you switch on is a new way to be wrong, and each one fails quietly. Search returns a wrong page and the answer is fluent. Code drops a row and the chart is beautiful. The connector reads a stale copy and the summary is confident. When an answer that used tools is wrong, check the tool output first and the model second. That order is right far more often than it feels.