When should you use search, agentic search, a Research API, or build the loop yourself?

Use a search API when your application needs sources. Use agentic search when your model needs to choose what to investigate next. Use a Research API when your application needs a finished answer with citations. Build the loop yourself when control over source selection, evidence handling, or synthesis is part of your product.

The decision starts with the job. If a coding assistant needs a parameter definition from a known documentation page, fetch that page. If it needs to compare current capabilities across several projects, someone must find the sources, read them, check coverage, and reconcile the evidence before writing the answer.

Choose where that work belongs and which parts your team needs to control.

First, define what your application must receive

“Add web access” leaves the output undefined. Write the result your application actually needs:

These jobs can exist inside the same application. A pasted link does not need source discovery. A request to find current deployment guidance might. Reading a pricing page and comparing several vendors’ pricing are different workflows even when both begin with a URL.

The search-versus-research guide explains the work between finding sources and producing a cited answer. This guide helps you decide who should perform it.

What each approach gives you

A search API returns candidates for your application to use

A search API fits a source picker, a documentation finder, or a system that already knows how to build an answer from retrieved material.

For example, Ollama’s Web Search API returns results with title, url, and a relevant content snippet. Its Web Fetch API returns a page’s main content and links. The two responses support different next steps: a snippet helps identify a source; fetched content gives your application material to inspect.

If your feature displays links, search can finish the job. If it displays a cited explanation, your application still owns source selection, reading, answer construction, and the connection between claims and sources. That can be a small, bounded implementation when one authoritative page contains the answer.

Choose search when finding sources is the required output, or your existing downstream system already meets the answer requirements.

Agentic search lets the model decide what to do next

In model-operated agentic search, the application gives the model search and fetch tools. The model chooses a query, reads the results, and decides whether to open a page, search again, or answer. The application executes those tool calls and enforces their limits.

Ollama’s search-agent example demonstrates this pattern. It adds tool results to the conversation and continues until the model stops requesting tools.

This approach fits a task whose next step depends on what the agent learns. A coding assistant can inspect a local dependency version, retrieve the corresponding documentation, and use it while proposing a change. The application decides which local context the model can use and which information it can send in a public-web query.

You still maintain tool definitions, context handling, loop limits, source mappings, and failure behavior. Treat web content as untrusted input; it must not grant the agent new permissions or override the application’s instructions.

Choose agentic search when the model’s adaptive investigation belongs inside the larger task.

A Research API returns the answer before your model continues

A managed Research API takes a question and performs the answer-building work inside the service. Your application receives the researched output instead of executing each search and fetch decision itself.

Tabstack Research plans queries, discovers and reads sources, checks gaps, follows up when needed, and synthesizes a Markdown report with citation metadata. It returns the report on the stream’s terminal complete event. Your application can give that result to your own model as an input to its next step.

That boundary suits a briefing feature or assistant that needs a current public-web answer but does not need to control every intermediate retrieval decision.

Your application still owns acceptance. Check whether the answer covers the question and whether its decision-driving claims have support. Handle task-level error events, and treat a stream that ends without a terminal event as incomplete. Research always streams; receiving progress is not the same as receiving the finished report.

Choose a Research API when you need the answer as an input and the service’s exposed controls satisfy the job.

A DIY loop gives your team control over the implementation

A custom loop lets you choose the retrieval components, source-selection rules, context limits, reconciliation method, synthesis prompts, and citation construction. You can combine deterministic steps with model decisions.

Build when those choices create product value or satisfy a requirement a managed service cannot meet. Examples include a prescribed source hierarchy, retrieval across private and public systems, or a requirement to preserve selected evidence passages in your own format.

Ownership includes maintenance. Your team handles changed pages, failed fetches, provider limits, model changes, incomplete evidence, and malformed output. It also maintains the evaluation that determines whether the loop still works.

Choose DIY when you can name the intermediate decisions you must control and assign the engineering capacity to operate them.

Agentic search and DIY overlap. “Agentic” describes how the system chooses its next action; “DIY” describes what your team builds and owns. A managed Research service can also run an agentic loop internally. Inspect the response contract and control boundary rather than choosing from the label alone.

The decision matrix

The architecture does not establish which implementation answers better, runs faster, or costs less. Compare the complete configurations on your questions. Include failed attempts and incomplete outputs rather than pricing only the successful demo.

Where does the work run?

Use this process model before selecting a provider:

flowchart TD
  A[Required output] --> B[Sources to inspect]
  B --> SA[Search API]
  A --> C[Content or fields from a known URL]
  C --> FE[Fetch or Extract]
  A --> D[A cited answer]
  D --> E[Model must choose web steps within its larger task]
  E --> AG[Agentic search]
  D --> F[Service controls meet the job]
  F --> RA[Research API]
  D --> G[Required controls or data boundaries need custom work]
  G --> DIY[DIY loop]
  AG --> H[Application acceptance checks]
  RA --> H
  DIY --> H
  H --> I[Use, reject, or escalate]

If a required processing boundary rules out a provider, eliminate it before testing answer quality. A good report cannot make an incompatible data path acceptable.

Apply the guide to a concrete job

Suppose a developer assistant receives this question:

What does Ollama’s Web Search API return, how does that differ from Web Fetch, and can I display the search response as a cited answer?

Before running anything, define the required answer elements:

1. Name the documented fields in each response.
2. Distinguish a relevant snippet from fetched page content.
3. Explain the application work required to turn those responses into an answer.
4. Cite the documentation for the API facts.

Here is a complete, documentation-derived answer example, not output from a new API run:

Ollama’s Web Search API returns a results array whose entries contain title, url, and a relevant content snippet. Web Fetch returns title, the page’s main content, and links. Neither response defines a finished cited-answer format. Your application can display search results directly, but it must construct the explanation and attach supporting sources if the feature promises a cited answer. See the Web Search and Web Fetch documentation.

For this job, start by reading the known documentation page. It contains the response definitions. If your application can write the explanation and preserve its source, it does not need an open-ended research loop.

Change the job and the choice can change:

• Find official web-search documentation. Use search when you do not already know the destination.
• Inspect this repository’s dependency version and work out the relevant integration steps. Use an agentic path when the model needs to move between local inspection and public documentation. Keep private context out of public queries unless your policy explicitly permits it.
• Compare current retrieval approaches for a developer assistant using evidence across several projects. Evaluate a Research API if your application needs the comparison report before its model continues. Freeze the comparison criteria first.
• Use only approved sources and preserve the exact passages selected at every stage. Build or select a loop that exposes those controls. Do not infer that a report and citation list satisfy an evidence-archive requirement.

The question determines the workflow. A product does not need one architecture for every web request.

When Tabstack is not the answer

We built Tabstack to return finished web output to applications. These requirements point elsewhere:

A known URL is a separate case: it can fit Tabstack, but usually through Extract, not Research. Ask for Markdown when the next step needs page content, or matching JSON when it needs fields. Validate the values as well as the shape.

Pilo provides a self-hosted automation path. It is not a self-hosted deployment of Tabstack Research.

Check the processing boundary

Running your own model does not make external web services local. Search queries and research requests follow the data paths of the providers your application calls.

Tabstack Research runs on hosted infrastructure. Contracted model providers process the query and web content to produce the answer. Our Data Handling documentation describes that path, and the Privacy Notice is the canonical policy. Confirm workload-specific retention and provider requirements before sending sensitive inputs. Do not interpret “never trained on” as a promise that no hosted processing or storage occurs.

Choose a path for one real job

Write down the output your feature promises, the intermediate decisions you must control, and the data it can send outside your environment. Then test the smallest approach that satisfies those requirements.

Use the citation review method to check claim support and answer coverage. The traced Python example shows how to preserve the report, cited pages, and request timeline. For a comparison between complete systems, use the search + fetch + model evaluation plan.

If your job needs a finished answer from public sources, bring that question to the Research playground, which requires sign-in. Write its required answer elements first, then check the returned report against them. If search or a known-page fetch already meets the job, use it.