Claude Opus 5.5 could turn a single AI agent into an entire research machine.
It can search hundreds of sources, verify claims, track evidence, spot contradictions and deliver detailed, source-grounded reports.
In this article, I show you how. https://x.com/i/article/2112149016255324160
Research Engineering: Build an AI Research Machine
Practical system for turning questions into fast, source-grounded answers that show their work
You ask an AI a question about a model, a company, a market, or a new paper.
It comes back in seconds.
The answer is clean. The links look credible. The conclusion sounds certain.
Then you open the sources.
One link is a search result, not the original page. Another source never says what the answer claims. A third is six months old. The model has stitched them together and filled the gaps with a sentence that sounds like research.
That is not a research machine.
It is a fluent answer with a browser attached.
The difference is the system around the search: what the agent is asked to prove, how it divides the work, what counts as evidence, how it checks contradictions, and when it is allowed to stop.
That is what I mean by research engineering in this article. It is a practical name for engineering an AI research workflow, not a claim about the formal job title "research engineer".
The goal is not to make an AI read more pages.
The goal is to make it return fewer unsupported claims.
The new research loop is already visible
In September 2026, Anthropic described a biology workflow where Claude agents screened more than 200,000 reverse transcriptases, surfaced 3,500 candidate systems, and narrowed those to 20 reports for review.
The work took about 21 hours across roughly 950 agent sessions. Anthropic says its scientists then tested a candidate in the lab, and that the function of the system remains unknown.
This is an early, company-reported result, not an independent benchmark.
Anthropic's account and independent coverage both make the important distinction: finding a promising lead is not the same as proving what it does.
That distinction is the whole article in miniature.
The machine can search at scale, sort candidates, compare patterns, and prepare a readable report. But the report still needs evidence. The hypotheses still need a test. And the system must show where the answer is solid, where it is contested, and where it has no answer yet.
This is useful well beyond biology. A personal research agent can help you compare models, trace a product claim, prepare for a meeting, map a technical topic, or check what changed since last week.
But only if it is built to keep track of how it knows what it says.
Research machine has six jobs
The architecture is model-agnostic. It can sit around Claude, GPT, Grok, another model, or a mix of them.
Minimal flow diagram of the six stages above.
Each stage has a different job.
Copyable table 01 - Six research stages
If the system jumps from step 3 straight to step 6, it has no reliable way to tell the difference between evidence and a plausible summary.
Give it a research contract, not "look into this"
"Research the best AI model" is not a bounded task.
Best for what? As of when? Compared with which alternatives? Does "best" mean quality, speed, reliability, price, or something else?
Before the first query, turn the request into a small contract. It does not need to be a form the user sees. It can be a compact object inside the workflow.
The contract makes hidden assumptions visible. It also gives the search planner a target. Without it, the agent may search broadly, discover a lot, and still answer a different question.
If a missing choice would change the result, ask the user one focused question. If not, state the assumption and proceed. The system should not turn every small ambiguity into a blocking interview.
One important field is "as of". A question about current pricing, model availability, leadership, or product features has a half-life. Record when it was checked. A timeless explanation does not need the same freshness policy as a live product comparison.
Split the question before you split the agents
The planner turns the contract into a few distinct subquestions.
For the model comparison above, those might be:
- What do the providers currently claim and charge?
- What do independent tests say about the relevant coding tasks?
- Where do the tests disagree, and what could explain the difference?
- Which result matters for this team's actual workflow?
These become separate search lanes. The lanes should be different in purpose, not just copies of the same prompt sent to four agents.
Parallelism is valuable when the work can be separated cleanly. One lane can find primary sources, another can look for independent evaluation, and a third can search for caveats or contrary evidence. The lead agent should merge their evidence, not blindly concatenate their conclusions.
Three agents that read the same five search results are not three independent sources.
Neither is asking three models to agree with each other.
If every worker begins with the same popular summary, the system can produce consensus without adding a single new fact. Give each lane a different question, an explicit source target, and the same evidence-return format.
This keeps the synthesis agent from having to trust a worker's polished summary without being able to inspect its basis.
Search broadly, fetch selectively
Research workflow usually needs more than one source surface.
- The open web for docs, papers, announcements, and reporting.
- X for first-hand posts, announcements, and what a specific person said.
- Private library for PDFs, notes, repositories, and internal documents.
- Database or API when the question needs structured facts rather than prose.
Search results are a discovery mechanism. They are not evidence by themselves. Open the original page, locate the passage that supports the claim, and keep the URL and date with it. If a result points to a quote about a quote, follow it back until you can identify who actually made the claim.
Provider-hosted search tools can reduce setup, but the tool interface is not the research architecture.
OpenAI's web search guide, Anthropic's web search tool, and xAI's X Search tool describe different ways to search and return sources.
Your system still needs a consistent record of what it fetched and what those sources actually support.
Use X carefully. A post can establish that someone said something. It does not automatically establish that the thing they said is true.
Source quality depends on the question. A provider's docs are primary evidence for its documented API behavior. They are not neutral evidence that the product outperforms competitors. A benchmark author is primary for what their test measured, not necessarily for the broad claim that one model is "the best".
Build an evidence ledger before a polished answer
The ledger is the center of the system. It is a structured list of claims and the exact evidence attached to each one.
Store sources once, then refer to them by ID. Keep the original page or file separate from the model's summary. A summary can help retrieval, but it is not a substitute for the passage it summarizes.
The example uses a placeholder URL and passage. In a real run, validate the URL, preserve the fetched page or a durable snapshot where permitted, and do not let a generated citation point to a page the system never opened.
Use explicit statuses. A useful starting set is:
Copyable table 02 - Evidence statuses
Do not force uncertainty into a confidence number that looks more scientific than it is. A short reason is often better: "provider docs confirm the feature exists; no independent test found for reliability".
The ledger also makes the final report cheaper to update. If a price changes, you can find which claims depended on that source instead of rerunning every part of the research.
Verify the claim, not the source's reputation
Before synthesis, ask of every important claim:
- Does the linked passage say this directly?
- Is the source speaking from evidence, reporting someone else's claim, or repeating a summary?
- Is the publication date relevant to the question?
- Is the second source actually independent, or do both trace back to the same announcement?
- Is there a credible source that disagrees or narrows the claim?
- What evidence would change the answer?
The phrase "two sources confirm it" is weak if both articles copied the same press release.
For every central conclusion, verify the path back to the original source. For high-impact or fast-changing facts, check a current primary source and at least one genuinely independent source when one exists. For an announcement, the primary source may be all that exists. Say so instead of implying broader confirmation.
Keep the claim small enough to test. "Model X is better" is not a research claim you can verify. "In benchmark Y, under configuration Z, model X scored higher on task class A" is. The narrower claim can then be put beside the right caveats.
When sources disagree, do not silently average them. Record the disagreement, inspect their dates and methods, and explain which one answers the user's question. Sometimes the correct result is not a winner. It is "the published evidence does not settle this".
Automatic depth selection can make a product feel effortless. It does not guarantee that the right sources were found or that every sentence is supported. In a research machine, the depth decision is visible: here is what the task required, here is what was searched, and here is why the run stopped.
Make the search loop explicit
The orchestration should be boring enough to inspect.
This is reference pseudocode, not a copy-paste implementation. The search, fetch, ledger, and verification functions are adapters you connect to your chosen provider or search stack.
The crucial property is that the next search round is targeted. If one claim lacks a current source, search for that claim. If two sources conflict, fetch the original documents and compare their methods. Do not restart the whole search because the first draft "feels incomplete".
Also treat retrieved pages as untrusted data. A page can contain instructions aimed at the model. Those instructions are content to analyze, not permission to change the system prompt, call unrelated tools, or send data somewhere. Research tools should normally be read-only. Keep consequential actions behind a separate, explicit approval step.
Make it faster by removing wasted work
More agents do not automatically mean faster research. They can repeat searches, fetch the same pages, and produce five summaries that all cite one source.
The high-leverage speed improvements are less glamorous.
- Run independent search lanes concurrently.
- Put a small planner in front of expensive research runs.
- Search broadly, then fetch only the sources likely to answer a claim.
- Deduplicate by canonical URL and content hash before summarizing.
- Cache stable sources, give volatile claims a short freshness window.
- Limit each lane to a clear question and a small evidence return.
- Spend the expensive verification pass on claims that change the conclusion.
- Stop when the evidence is sufficient, not when the answer sounds elegant.
That is the persistent side of the system. Keep raw sources immutable. Let the AI maintain summaries, topic pages, and links as derived files, but make every derived claim point back to its source and date. Otherwise your research memory can become an attractive archive of stale model paraphrases.
For a first deployment, start with three service levels. These are starting defaults to measure against your own tasks, not universal limits.
In quick mode, fewer sources can be enough for a low-risk factual lookup. In deep mode, do not just add more searches. Add a different kind of check: original documents, another method, another date range, or a credible attempt to disprove the working answer.
Give it a memory that can be corrected
A chat transcript is a bad long-term database. It mixes questions, speculation, incomplete drafts, and facts that expire.
Keep research memory in three layers:
Copyable table 03 - Research memory
Do not update a derived wiki by overwriting the old conclusion with a newer-sounding sentence. Add the new source, identify the affected claims, and mark whether the evidence supersedes, contradicts, or merely supplements the old record.
This is especially important for product research. A model name, price, API parameter, or benchmark result can change without the old note looking obviously wrong. A freshness date turns silent drift into a visible maintenance task.
Test the machine on questions that can catch it lying
Do not evaluate the system only on questions where you already know the flattering answer.
Build a small set of real research tasks with known evidence and deliberate traps:
- Stable question with one clear primary source.
- Fact that changed recently, with an old page still ranking highly.
- Two sources that disagree.
- Claim repeated widely but traceable to one weak original.
- Question where the honest answer is "not enough evidence".
- Prompt containing a misleading X post or an instruction inside a fetched page.
- Multi-part question where one subquestion is easy to miss.
Score the final result on separate dimensions:
Copyable table 04 - Evaluation framework
For your own research machine, treat that as a target to test, not a result to assume. The support, coverage, freshness, and contradiction checks above are how you turn the promise into something measurable.
Track errors by type. "Bad research" is too broad to fix. "Two claims cited a press release without opening the underlying paper" points to a concrete improvement in fetching or verification.
Start with a small fixed evaluation set, save every run's queries, source IDs, and final claims, and rerun it after changing the prompt, search tool, model, or retrieval rules. Otherwise a faster version can quietly become less accurate and you will not know when it happened.
The prompt to install first
This can be used as project instructions in a chat product or adapted as the system prompt for an API workflow.
The prompt cannot give an app a browser it does not expose. For current web research, enable a search or browsing tool. For private-library research, give it access to the documents or retrieval system.
Without a source tool, the model can only work from what you provide and what it already knows.
But the prompt is not the machine.
The machine is the prompt plus search tools, a fetch layer, a ledger, checks, budgets, memory, and a test set. Without those, the model can promise to follow the process and still have no way to prove it did.
What I would actually build
For a personal setup, start with one capable model, web search, and a folder that separates raw sources from compiled notes. Use the brief template, ask for exact passages, and manually check the sources behind your important claims.
For an API setup, make the flow explicit:
1. Store the brief and a task ID.
1. Build a query plan with a fixed budget.
1. Run only the independent lanes in parallel.
1. Normalize search results into source records.
1. Fetch and deduplicate the original pages.
1. Write claim records with supporting passages.
1. Run targeted contradiction and freshness checks.
1. Generate the report from supported claims only.
1. Save the trace and score it against the eval set.
The first version does not need a vector database, a swarm of twenty agents, or a custom research dashboard. It needs good source capture and an honest check between "I found a link" and "this link proves the sentence".
Add infrastructure only when your evaluation set reveals a real bottleneck. If retrieval misses relevant passages, improve search and fetch. If it cites the wrong text, improve claim-level verification. If it forgets old findings, improve the evidence store. If it takes too long, profile where the time goes before adding more agents.
The real shift
Search is cheap.
Trust is expensive.
The useful research agent is not the one that opens the most tabs or writes the smoothest report. It is the one that can tell you what it found, what those sources prove, what they fail to prove, and what remains unsettled.
That is how you make an AI research faster without asking it to guess faster.
That is research engineering.
If u read this far
Who is stronger for the work you actually do, Grok, Claude, or GPT? What task changed your mind? I want the specific failure or win, not just a team jersey.
→ Bookmark and retweet this article.
→ Subscribe to my Substack.
→ Follow me on X.
Documentation & Further Reading
- Claude discovers a novel enzyme system - Anthropic
- Introducing Prism - OpenAI
- Web Search - OpenAI API
- Web Search Tool - Anthropic
- X Search - xAI
- Working with Evals - OpenAI API
- LLM Knowledge Bases - Andrej Karpathy (archived copy)
The central principle behind all of these resources is simple: search finds information, but a reliable research system must still verify what that information proves.