Get early access
How it works

Three choices, and together they are the whole thing

A chatbot sends your question to one very large model in a data centre, which searches through a paid service and hands the finished paragraph back to you. You cannot point at a sentence in it and ask where that came from, because the paragraph carries no record of which page produced which clause. Three decisions take that apart.

Research Workbench Agents
  1. Discovery
  2. Orchestr.
  3. Task Giver
  4. Query Help
  5. Task Doer
  6. Evaluator
Six stages run in order. The three choices below are what makes that order possible.
Choice one

Your browser fetches the pages, so sites see a person

An extension you install does the fetching. Every page request leaves your own machine, on your own connection, so a publisher sees the same request it would see if you opened the page yourself. Pages that turn away a data centre open normally for a person, so LoQuery reads sources a crawler cannot reach at all.

No crawler of ours visits the pages you read. No site has an address of ours to recognise. Your account and your run records do sit on our servers. The privacy page lists what is stored.

Research Workbench Sources

Sources Discovered 24 sources 8 domains

Most-used sources

  • en.wikipedia.org × 3
  • aviation-safety.net × 2
  • recherche-research.bac-lac.gc.ca × 2
  • www.canada.ca × 1
  • archives.gov × 1
  • nsarchive.gwu.edu × 1
  • www.baaa-acro.com × 1
  • ufocasebook.com × 1
The source dossier from one run over aviation records. Every page in it arrived through the browser of the person who started the run, and none of them was requested from an address of ours.

Cell values, sources and caveats here are real and open to checking. The scores, attempt counts and source totals show the shape of a run and get replaced once a captured session record lands.

Choice two

Extraction and judgment are separate calls, so nothing grades itself

LoQuery splits research into narrow jobs: one writes the searches, one pulls a single fact off a fetched page, one decides whether that page supports it. Every answer comes back in a fixed shape, checked by plain code, so you can tell which step produced a value and which step to check.

Every question put to the model is about a page that search already fetched, so the work is judgment over supplied evidence rather than recall from training. No value in the table comes from what the model remembers. Small open models are enough for that. A model grading its own work defends the answer it already committed to, which is why the judging step never sees how the extraction reasoned.

  1. 01

    Extract Task Doer

    Reads a fetched page and pulls out the specific value for one field, with the URL it came from. It does not score anything and it is not asked whether it did well.

  2. 02

    Gate Deterministic

    Plain code, no model. Six checks run over the extracted values. Dates in the future, dates outside the window you asked for, too many fields marked not-applicable, entities pulled off an aggregator page. Arithmetic, so it always fires the same way.

  3. 03

    Judge Evaluator

    A separate call with its own context. Is this actually the entity that was asked about? Is this source authoritative for this kind of claim? Does the date make sense for this event? It never sees how the extraction reasoned, which is the point.

  4. 04

    Verdict confirmed · with caveats · uncertain · mismatch

    A score, one of four verdicts, and typed caveats, each with a code and a severity rather than a sentence the model improvised. And verdict_source: evaluator.

  5. 05

    Override You, if you disagree

    Set the verdict yourself, or keep it and rewrite the reasoning. verdict_source becomes user or collaborative, and it stays that way downstream. The machine's original call is not overwritten, it is recorded as having been overruled.

Choice three

LoQuery writes its own instructions for every question

The code knows nothing about securities enforcement or aviation history. Before a search runs, LoQuery decides what it is looking for, which sources count as authoritative in that subject, and what each column has to contain. Nobody added a subject, a source list or a field rule.

Plans Task Plan

Aviation history · Task Plan 6 sections

  1. 1 · Research intent unspecified · event · aviation history
  2. 2 · Output fields date, official explanation, primary source, status, summary
  3. 3 · Research strategy DAG · 1 level
  4. 4 · Field limitations (none)
  5. 5 · Authoritative sources aviation-safety.net, gov, canada.ca, archives.gov, nasa.gov, mil
  6. 6 · Dynamic config summary domain: aviation history · denied_sources: 0

Enforcement · Task Plan 6 sections

  1. 1 · Research intent unspecified · company · enforcement
  2. 2 · Output fields regulator, penalty, date, filing, summary
  3. 3 · Research strategy DAG · 1 level
  4. 4 · Field limitations penalty: currency required
  5. 5 · Authoritative sources sec.gov, justice.gov, cftc.gov, gov, courtlistener.com
  6. 6 · Dynamic config summary domain: enforcement · denied_sources: 1
Two unrelated runs, one code path. Six slots each, both written before anything was searched, and the enforcement run required a currency on the penalty field where the aviation one had nothing to constrain. The source lists differ, and so do the denied-source counts.

Cell values, sources and caveats here are real and open to checking. The scores, attempt counts and source totals show the shape of a run and get replaced once a captured session record lands.

The subject decides which sources count as authoritative. So LoQuery searches first and reads what came back. When that search turns up trade press and no institutions, the plan leaves the source list empty and flags the subject as uncalibrated. Filling that gap is your job.

Hand LoQuery a category instead of a list and the same machinery works out the population first, collecting candidates in waves before it researches any of them. You approve the list before LoQuery spends anything on it. Approve a discovered list yourself →

Every cell carries its source (not a bibliography at the end)

The source sits on the cell itself, next to a verdict on how well it supports that claim, so you can defend one number without re-reading the run. Any warning LoQuery raises against its own answer sits there too, and when no record resolves for an item the cells stay empty while the row says why. Nothing is filled in with something plausible.

Every item gets up to three attempts. Attempt one runs five queries and accepts nothing under 0.85, attempt two runs ten at 0.80, and attempt three runs twenty or more on best effort. The final row merges the best data any attempt produced. A run that stops early writes the reason into the record by name, so you can tell a fast run from a run that gave up. The full ladder is in Making an open model return Not Found.

Research Workbench Table View
Item name Score Verdict Why Caveats DateOfficial explanationPrimary sourceStill unexplained
Lake Michigan 1994 incident 3 attempts 0.18 mismatch Low score (0.18); zero of 2 evidentiary field(s) filled. The 1994 reports are a cluster of sightings across several towns, so no single incident record resolves. Not Found Not Found Not Found Not Found
This row scored 0.18. Every one of its four fields came back Not Found, because the 1994 reports are a cluster of sightings across several towns with no single incident record. The table says so rather than guessing.

Cell values, sources and caveats here are real and open to checking. The scores, attempt counts and source totals show the shape of a run and get replaced once a captured session record lands.

Five things it refuses to be

In a market this crowded, LoQuery is described better by what it refuses to be than by another round of promises about what it does.

  • Not a chatbot

    There is no conversation with the pipeline. You configure a run, watch it work, steer it while it goes, and get a table. Nothing here is trying to sound like a person.

  • Not a search engine

    It orchestrates search engines, through your browser, using your connection. We do not have an index and we are not trying to build one.

  • Not trained on a private library

    It reads the live open web, per run. Nothing is retrieved from a corpus we curated in advance, so nothing is as stale as the last time we updated it.

  • Not a cache

    Nothing carries over between sessions. Run the same question twice and it is researched twice, because a verdict reused from last month is a verdict nobody checked.

  • Not autonomous

    A run needs your browser attached and expects you in the loop. That is the design, not a limitation we are working around: a tool that finished the thinking while you were away would be the thing we built this to replace.

Where we lose: reasoning, speed, testing

LoQuery loses on open-ended reasoning. A small open model under hard contracts beats a large one on verifiability, and that is the trade LoQuery is built on.

If your question needs a long chain of original thought, this is the wrong tool. We would rather say so here than have you find out on your third run.

The first answer takes longer than a chatbot's, because the searching happens in your browser at the pace a person would browse rather than in a data centre. We check quality by hand today. LoQuery cannot run without a browser attached, so there is no automated end-to-end evaluation for anyone to check.

Get early access