How AI Research APIs Plan, Search & Synthesize (Under the Hood)

A grounded LLM answers API returns an answer that was checked against retrieved sources, with a citation behind each claim, instead of one the model produced from memory. The label alone does not tell you how much checking happened. This post walks through the five stages of a thorough pipeline, where real products diverge, and how NeuralVerge's research (REST) and its Search, extraction and source tools (MCP) fit in.

The short version

• —The claim. "Grounded" only means something if the pipeline plans, searches, cross-checks and cites per claim. Retrieval before generation is close to universal now; cross-checking and per-claim citation are where products differ.
• —Who it is for. Anyone choosing or building a grounded-answer service for compound questions about companies and people, where a confident wrong answer is expensive.
• —The fast test. Run one compound question you know has two sub-parts, and read the citation trail, not just the answer. The checks are in the last section.
• —What it costs here. AI research is priced by depth tier, from 20 points for Lite to 400 for Ultima. Search and AI extraction are 5 points per call. Plans start at $50 a month for 50,000 points.
• —How you reach it. Research runs over REST. Search, AI extraction and every data source are also MCP tools. For one traced example, see the deep research walkthrough.

What a grounded LLM answers API fixes

The failure it is built for

An ungrounded model answers from what it remembers, fluently, with no reliable signal about whether that memory is current, correct or simply invented. Ask it who owns a company or whether a registration is still active and it will often answer anyway.

Why retrieval alone is not enough

Handing the model something it just looked up fixes part of the problem. It does not fix a single search result that is wrong, stale, or contradicted by a second source the search never surfaced. The fuller architecture closes that gap: not only "did the model look something up" but "was what it found checked before being stated as fact."

The five stages of a grounded answer

What changes between products is how many of these stages are real steps and how many are assumed.

1. Planning: decompose before searching

A compound question such as "summarize this company's ownership and recent funding" is two sub-questions in one sentence, drawing on different kinds of sources. Planning makes that split explicit before any search runs, instead of leaving a single search-and-summarize pass to handle both halves at once and unevenly. A planned question can route each part to the source it needs. A question treated as one blob searches everything and nothing precisely.

Planning only earns its place if the plan changes what happens next. A pipeline that splits a question and then runs the same generic query for every part has the shape of the architecture without the substance.

2. Search: match each sub-question to a source

Each sub-question needs a source category suited to it: a registry for a legal-structure question, a funding database for a financing question, the open web for anything a structured source does not cover. This is also where a thorough pipeline allows a second attempt. If the first search comes back thin, it can issue a follow-up with a refined query instead of treating one attempt as final.

3. Extraction: turn pages into comparable facts

Whatever search returns, whether a page, a document or a database record, is mostly structure and noise relative to the one fact a sub-question needs. Extraction pulls out that fact in a consistent shape, so that two sources' versions of "founded in 2019" and "established 2019" can be compared in the next stage. Without this normalization, cross-checking has nothing comparable to check.

4. Cross-checking: the stage most shortcuts skip

When more than one source touches the same fact, cross-checking compares them. Do they agree? If not, which is more current or more authoritative, or should the disagreement itself be surfaced instead of silently resolved? Most single-pass designs skip it by construction, so a confident wrong answer and a confident right one look identical from outside.

There are two ways to get this stage wrong, and they cause different problems:

• —Under-checking. Treating any retrieved fact as settled brings back the failure grounding was meant to remove, now with a citation attached.
• —Over-checking. Flagging disagreement on details that do not matter, or presenting false balance between an obviously stale source and an obviously current one, produces answers that hedge instead of answering.

A well-tuned stage resolves what can reasonably be resolved and flags only genuine, material disagreement. That is a harder design problem than either extreme, which is why this is the stage where implementations vary most even among products that attempt it.

5. Citation: attach the source to the claim

The last stage is what makes the earlier ones checkable after the fact. A "sources" list under the answer tells you it is backed by something, somewhere. A citation per claim tells you which source backs which sentence, which is the difference between "trust this because it says it is sourced" and "here is exactly what to check if you doubt this part." Citation granularity is a direct signal of how much of the preceding architecture was built and not only described.

A worked example: where the difference shows

Take an illustrative question about the fictional Acme Oy (Finland): "Summarize the ownership and recent funding of Acme Oy, and flag anything inconsistent across sources."

A single-pass design searches once, hands the results to a model and cites whatever came back. If two sources state different funding figures, nothing in the process is built to notice. The answer reflects whichever figure the model weighted more, and the reader gets no sign a disagreement existed.

A five-stage design plans the question into ownership and funding, routes each to the source category likely to answer it, extracts the specific facts, compares the funding figures across sources, and then does one of three things: resolves the disagreement with a stated reason, prefers the more authoritative source, or states the disagreement in the answer. Each sentence is tied to the source it came from.

Both produce an answer with citations. Only one checked whether they agreed with each other.

Where implementations diverge

Every product marketed as a grounded LLM answers API runs some retrieval before generation. The real differences are below.

Single-pass or multi-step

Some products run one search, hand the results to a model and generate one answer. That is fast and entirely reasonable for a single well-defined fact. Others plan, search iteratively and generate only after cross-checking. Both are legitimate; they suit different shapes of question.

Cross-checking as a stage or as a hope

Telling a model to "check your sources" inside one generation pass is not the same as a dedicated stage that compares facts from independent sources before an answer is written. The first relies on the model noticing a disagreement; the second makes noticing it a step's job.

Citation granularity

Per-response source lists and per-claim citations both count as "citations" but carry very different checkability. Look at whether the trail says which source backs which sentence.

Configurable depth or one fixed process

A system with one fixed depth over-processes simple questions or under-serves compound ones. A system built with depth as a dial can route a single well-defined fact close to directly from search to citation, and run the full sequence for a question that really decomposes.

How NeuralVerge implements it

NeuralVerge's AI research runs the five stages as separate steps rather than folding them into one generation pass. A question is planned into sub-questions. Each is routed first to structured sources in the source catalog (corporate registries, company intelligence, contact enrichment, professional profiles) with the open web as fallback. Facts are extracted and normalized, cross-checking compares facts from independent sources before anything is finalized, and the answer cites each claim to the source it was checked against. Depth is a per-request setting with five tiers, and the model that writes the final answer is a separate per-request choice, finalizer_model; check docs.neuralverge.ai for the current values.

REST and MCP

The research pipeline, the five stages run end to end, is called over REST. It is not an MCP tool: a research run is asynchronous, you start it, get a session_id back and poll for the result, while an MCP tool has to return inside the call. Here is the real request for the Acme Oy ownership question at the Core tier, followed by the poll.

# Start the research run, which returns a session_id immediately
curl https://api.neuralverge.ai/functions/v1/run-research \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "instructions": "Summarize the corporate structure and ownership of Acme Oy (Finland)",
    "settings": { "country_code": "fi", "search_enabled": true, "deepsearch_model": "core" }
  }'

# Poll for the result
curl "https://api.neuralverge.ai/functions/v1/get-session-status?session_id=<SESSION_ID>" \
  -H "Authorization: Bearer <API_KEY>"

This is the example response from the AI research product page, shortened, with a placeholder session id:

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "status": "complete",
  "results": {
    "kind": "deepsearch",
    "human": "# Acme Oy\n\nAcme Oy is a private limited company registered with YTJ...",
    "machine": { "summary": "Acme Oy is a private limited company registered with YTJ..." }
  }
}

results.human is the readable answer and results.machine is a structured version for code. Poll until status is complete.

What an agent can reach over MCP are the building blocks around that call. Search (run_search), AI extraction (run_extract) and every data source in the catalog are tools on the hosted server at https://mcp.neuralverge.ai/mcp. An agent that does its own planning can use run_search for retrieval, run_extract to turn a page into structured facts and a registry or company tool for a structured source, then do its own cross-checking and cite what it retrieved. Tool names use underscores where REST paths use hyphens, so run_search over MCP is run-search over REST.

Connecting works the same in any MCP client, including Claude, ChatGPT, Cursor, VS Code and Gemini CLI: add the URL, sign in through the browser and click Allow. Setup guides are at https://docs.neuralverge.ai/connect-a-client, and the MCP server for Claude walkthrough shows the Claude case.

Every tool returns the same response shape as its REST endpoint at the same price, so the choice is about who decides when a call happens:

• —REST fits a pipeline that already knows what to ask and when: a scheduled job, a back-office workflow, anything that runs a research task and waits for the cited result.
• —MCP fits an agent choosing tools mid-task: looking something up, extracting a figure or fetching a record because the conversation just called for it.

The two combine: an agent can answer simple questions from MCP tools and hand a compound one to research over REST. MCP tools alone do not give you the cross-checking stage; the agent has to implement it, or call research.

Cost and limits

AI research is priced by depth tier. Figures are from the pricing page at the time of writing.

Search and AI extraction are 5 points per call. Points come from a monthly plan; the pricing page lists the plans, from $50 a month for 50,000 points, and the cost of each action.

A few limits are worth stating plainly:

• —Cross-checking is not verification. It catches disagreement between sources; it does not prove a source is right.
• —Freshness follows the sources. Retrieval is live, but a registry record is only as fresh as the registry's own last update, and the open-web fallback reflects what is publicly indexed at query time.
• —Depth is a trade. A lighter tier runs fewer cross-checks: fine for a narrow question, worse for a broad one.
• —Runs take time. Turnaround runs from 30 to 90 seconds at Lite to 5 to 12 minutes at Ultima, so research suits background jobs, not a synchronous page load.

How to decide

Run a compound question you already know the answer to through a candidate and inspect the trail. "Grounded", "cited" and "multi-step" are used loosely enough that only a real call settles it.

• —Does the question decompose? If it is a single well-defined fact, a single-pass design is fine and the full pipeline is wasted work. Use the fuller pipeline when the question has more than one sub-part.
• —Does each part get its own citation, tied to the sentence it supports? Or does the answer blend the parts under one source list?
• —What happens when two sources disagree? Feed in a case where you know they would. Does the answer surface the disagreement, prefer one with a stated reason, or silently pick a side?
• —Can you set depth per request? If the same fixed process runs for every question, you either wait on work simple lookups do not need or the light path is quietly worse at everything.
• —Does it admit what it could not find? A pipeline that always sounds confident and complete deserves more skepticism than one that reports an inconclusive sub-question.
• —Do you need the whole pipeline or the pieces? If your agent already plans and checks its own work, the Search, extraction and source tools over MCP may be all it needs. If it should hand off a compound question and get a cited answer back, call research over REST.

Frequently asked questions

Is every "AI research" product built this way?

No. Some products run a single search-and-summarize pass rather than the full plan-search-cross-check-cite sequence described here, which is a reasonable architecture for fast, single-fact questions. The fuller pipeline is worth the extra time specifically on compound questions that benefit from decomposition and cross-checking.

Does more architecture automatically mean a better answer?

No — a narrow, well-defined question doesn't need multi-step planning to answer correctly, and running the full pipeline on it is unnecessary work, not extra correctness. The architecture earns its keep on questions that genuinely decompose into more than one sub-question.

What's the single biggest failure mode this architecture is built to prevent?

A confident, ungrounded answer that sounds complete but was never checked against a real source — the failure mode where a model states something fluently from training data with no signal that it might be wrong or outdated.

Can cross-checking eliminate hallucination entirely?

No — it reduces a specific failure mode (invented, unsourced claims) but can't guarantee every retrieved source is itself correct. Cross-checking catches disagreement between sources; it doesn't independently verify that a source is right.

Why does citation granularity matter this much?

Because a citation attached to an answer as a whole tells you the answer is backed by something, somewhere — while a citation attached to each specific claim tells you exactly which source backs which sentence, which is what actually lets someone check the work rather than trust it on faith.

Can a cross-checking stage over-correct and hedge too much?

Yes — flagging disagreement on details that don't actually matter, or presenting a false balance between an obviously stale source and an obviously current one, is a real failure mode in the opposite direction from under-checking. A well-tuned stage resolves what can reasonably be resolved and flags only genuine, material disagreement.

Can I use a grounded LLM answers API over MCP, or only through REST?

AI research is called over the REST API and is not an MCP tool. Search, AI extraction and every data source are MCP tools on the hosted server at https://mcp.neuralverge.ai/mcp, so an agent can use them for retrieval and extraction around a research call. Responses have the same shape and the same price as over REST.