AI and business
iKB Rebuilds Its Deep Research Mode to Work More Like a Researcher
iKB’s team rebuilt Deep Research after finding the first version produced summaries, not research. The redesigned AI deep research agent plans sub-questions, reads full sources, checks every quote and reports its own gaps.
iKB has rebuilt its Deep Research mode so that users can run topical research on the public web straight from iKB. According to the team’s design notes, the new mode plans a question, reads full sources, checks every claim against a verified quote and reports what it could not cover. The aim is research that works the way a careful researcher would, rather than a digest of search results.
The notes also record what the team learnt while building a deep research agent that holds up in practice, including where evaluation exposed weak spots.
Why Deep Research was rebuilt
The original Deep option was the Focused mode with a wider first search. It wrote up to six queries, read only titles and snippets, and ran a single synthesis call. In real runs it drew on one to three web sources and about 10k tokens. The team’s own verdict was that this produced a summary, not research.
The everyday default stays the same. The Focused brief remains standard, and Deep runs only when a user selects it. An admin must also allow Deep for each topic, using a switch that is off by default. Organisations therefore decide where the heavier mode is available.
How the research loop works
The rebuilt mode follows a set sequence: plan, search, select, read, extract claims, reflect (up to three rounds), verify, write and check.
- The planner turns the question into three to six sub-questions, each naming the kind of evidence that would answer it.
- The agent reads full pages, including PDFs, not snippets.
- Claims go into a ledger, and the report is written from that ledger rather than from raw pages.
- A run stops when every sub-question is answered, a budget runs out, or repeated queries stop adding anything.
Picture a hypothetical policy analyst in a government department who needs a briefing on a public regulation. In a topic where the admin has enabled Deep, the analyst selects it instead of the Focused brief. Real server-side progress appears, such as “Reading 7 of 18 sources”, instead of a timer. The analyst moves on to other work, and a desktop notification arrives when the report is ready. Had the question needed narrowing midway, cancelling would have kept the sources already found.
How the report earns trust
Every extracted claim carries a verbatim quote, and the design notes say the quote is checked against the fetched page. If it is not there, the claim is dropped.
A claim counts as corroborated only when two independent publishers support it. Syndicated copies, identical page bodies and quotes found inside another source’s text are merged before counting, and unknown provenance never counts as independence. Each claim is labelled supported, single-source, disputed or unresolved, and nothing is upgraded without evidence. Uncited factual sentences are flagged or removed.
For the analyst, those labels show at a glance which points to check before circulating the briefing. Staff still review the findings and make the decisions.
The team is open about the limits. Relevance remains a model judgment, and quote checking proves a quote exists on the page, not that the claim is correct.
The same openness applies when a run falls short:
- If a budget runs out, the agent writes the best report it can from the ledger and states what was not covered.
- An empty ledger produces a “no relevant sources found” report instead of a fluent guess.
- A writing timeout produces a limited report.
A hypothetical compliance lead whose broad legal question hits the budget would receive a usable report with its uncovered areas listed, ready to hand to staff for follow-up.
Safety design
Page fetching is limited to the public web. Every redirect hop is checked, and fetching is capped on redirects, page size and time, with only HTML, text and PDF accepted.
Fetched text is treated as data, not instructions. The model has no tools, so page content cannot change the research plan or the budgets.
Private-document text never enters search-query generation. A conservative filter drops queries containing private terms, accepting the loss of some useful queries. Strict-PII topics receive the same output redaction and instruction as normal chat.
Cost and limits
| Setting | Design default |
|---|---|
| Time | 10 minutes |
| Tokens | 300k |
| Pages | 30 |
| Searches | 24 |
| Reflect rounds | 3 |
A fixed slice of tokens and time is reserved for writing the report. The team expects a run to use roughly 100k to 300k tokens over three to eight minutes, against about 10k before. Runs are rate-limited per user, and admins can tune those limits, with changes audit-logged.
What evaluation taught the team
- Evals can burn a shared quota. A test harness ran about 15 research runs back to back, and the free search engines began rate-limiting the host. Both instances quietly fell back to documents-only.
- A result count is not a health check. A scraped search fallback returned full result sets that were largely junk, such as job listings and US Constitution pages for legal queries. Focused mode’s vetter dropped them, but Deep had none and wrote a contradictory report. The team added vetting and reverted the fallback.
- Wrong sources slip through. A legal question surfaced constitutional sources, which led to vetting for each sub-question.
- Provenance merging is hard. It took three audit rounds, and a second agent audited every stage and caught real bugs.
For anyone building a deep research agent, the practical lessons are to protect shared quotas, judge results by quality rather than volume, vet sources at each step and have every stage reviewed independently.
