Why research agents drift, and the design that keeps them honest

Most research agents demo well and then disappoint in daily use. The first answers read fluently and the citations look plausible. The trouble only shows when someone checks a claim against its source: the quote is not on the page, the question quietly turned into a different one, or the agent ran out of ideas and filled the rest with confident prose. This guide is for developers building research agents, including assistants that search the open web. It names the three failures behind most of the damage and the design choices that prevent each one.

Three failures behind most bad research

When a research run goes wrong, the cause usually falls into one of three groups. They are worth separating because each has a different fix.

1. The question was never answerable. “Tell me about the European battery market” has no end state. The agent cannot know when it is done, so it stops when the context fills or the tool budget runs out, and you receive a survey of whatever it happened to find first.
2. Claims outrun their sources. The agent reads three pages and writes ten sentences. Some are supported. Some blend several sources into a statement none of them makes. Some come from the model's general knowledge with a citation attached afterwards. A footnote on a sentence does not mean the sentence is in the source.
3. The scope grows without anyone deciding it should. A question about one supplier becomes a review of its whole sector because a search result looked interesting. Each step seems reasonable; the sum is a report about something nobody asked for, paid for with time and tool calls nobody approved.

A fourth pattern sits underneath all three: an agent that can only stop by producing an answer. If “I could not find this” is not an allowed outcome, the agent will eventually invent one.

Make the question answerable before the agent starts

The cheapest fix happens before any tool call. Turn the request into a short specification that says which decision the research feeds, what is in and out of scope, and what the finished output looks like:

question     Which of our three shortlisted payment processors support
             payouts in Turkish lira to local bank accounts?
decision     pick a processor for the marketplace launch
in scope     the three named processors, their own documentation
             and published terms
out of scope reviews, forums, resellers, other processors
output       one row per processor: yes / no / unclear, the quoted
             passage, the page it came from, when it was read
done when    every processor has a row; unclear rows say what was
             searched and why it was not conclusive

The “done when” line is the one teams skip and the one that matters most. It gives the agent a stopping rule and gives the reviewer a way to check the result without redoing the work. Writing acceptance criteria first covers the habit in more depth.

Plan first, then let the plan constrain the run

Agents that search, read and decide in one undifferentiated loop are hard to steer. Splitting the run into a planning phase and an execution phase gives you a natural checkpoint. The plan is short: the question, numbered steps and the sources each step may use. A person reviews it before anything runs; for low-stakes work an automated check can stand in.

The plan then acts as a contract for execution. If the agent discovers mid-run that the question should change, the right move is to stop and propose a revised plan, not to widen the search on its own initiative. That single rule removes most silent scope growth. It also makes cost predictable, because the steps and the sources they touch are known before the first call. A changed question needs a new plan explains why revision beats expansion.

Two implementation details help. Keep the source list explicit, and treat an empty list as “nothing allowed” rather than “anything goes”. And give each step its own budget for tool calls and wall time, so one stubborn step cannot consume the whole run.

When the assistant searches the open web

Adding web search changes the risk profile more than most teams expect. The agent now reads text written by strangers: some of it out of date, some written to rank rather than to inform, and occasionally some written to manipulate an agent. A few practices keep a web-searching assistant trustworthy.

• Choose the search layer deliberately. A search API returns ranked links and snippets; your agent still has to fetch and read the pages. Other tools return extracted page content or run multi-step research for you. Choosing a search tool for agents covers the differences. Whatever you pick, try it on your own questions.
• Read the page, not the snippet. Snippets are written to signal relevance, not to be quoted. Fetch the page and take the supporting passage from the fetched text.
• Record provenance at fetch time. Store the URL, the retrieval time and the exact passage used. Pages change, and a citation without a retrieval time cannot be rechecked later.
• Treat page content as data, never as instructions. A page that says “ignore previous instructions” contains a string to report, not a command to follow. Keep fetched text out of the system instructions and never let it trigger tool calls by itself.
• Respect access boundaries. A login or paywall is a boundary, not a puzzle. If material behind it is needed, obtain it through an authorized route and record where it came from.
• Prefer primary sources. When a fact has an owner, such as a company's terms or a regulator's notice, the owner's page should outrank a blog that paraphrases it. Write that preference into the plan instead of leaving it to the agent's judgment.

Whether to build all of this yourself is a separate decision; build a research agent or buy deep research walks through the trade-off.

Every claim carries a quote, and gaps stay visible

The most effective single change is to alter the unit of output. Instead of a report with footnotes, have the agent produce findings: a claim, the exact passage that supports it, and the source. Prose can be written from findings afterwards; the reverse rarely works.

That structure makes verification mechanical. After the run, check that every quoted passage actually appears in the fetched text of its source. Plain string matching with some tolerance for whitespace catches many fabricated or blended quotes before a person ever reads them. The reviewer can then spend attention on what software cannot judge: whether the passage really supports the claim, and whether it bears on the question.

Just as important, a question with no supporting source is a finding in its own right. Record it as open, together with what was searched, and keep it apart from supported findings. Reviewers act very differently on “this processor does not support lira payouts” and “we found nothing either way”, so the output must never blur the two. Citations that hold up goes further into what makes a citation checkable.

How GoCux structures a research run

GoCux is a company workspace rather than a search engine or a crawler, and its research flow is organized around the controls above. A research plan holds the question, the ordered steps and an allowlist of sources. A new plan is saved as a draft and runs only after someone on the team approves it; once running, it cannot reach past what was approved. An allowlist with nothing on it means no source may be consulted, and a changed question calls for a revised plan.

Findings backed by a quotation are kept apart from questions where no source turned up, and both stay on the record. GoCux does not read the open web by itself. Web material comes in through an authorized browsing or export step and carries the address of the original page and the moment it was retrieved, so a reviewer can trace it. The whole run sits on a work order whose steps, sources and decisions build up on a single record; the Task page shows what that looks like.

Measure it on questions you can grade

Generic leaderboards say little about how your agent handles your questions. Build a small evaluation set instead: a couple of dozen questions from real work, each with a known answer and the source that supports it, plus a handful where the honest answer is “not findable”. Run the agent and grade each output on three points: is the answer right, is every claim supported by its quoted passage, and did it say “not found” where it should have.

Track unsupported claims separately from wrong answers. An agent that is usually right but cites passages that do not say what it claims is more dangerous than one that is sometimes wrong and always traceable, because the first one teaches reviewers to stop checking.

Pre-release checklist

• Every run starts from a question with a decision, a scope and a “done when” line.
• A plan with steps and an explicit source list is reviewed before execution.
• A mid-run change of question produces a revised plan, not a wider search.
• Each step has its own tool-call and time budget, and the run has a spend limit.
• Web content is quoted from the fetched page, with URL and retrieval time stored.
• Fetched text is never treated as instructions.
• Quoted passages are checked against source text automatically.
• “No source found” is a first-class output, reported separately.
• Stop reasons (done, stuck, limit reached, decision needed) are visible in the trail.