How to Check a Browser Agent’s Research Citations

Ask your browser agent for a table with one claim per row, the original page, the exact place it read, and a verdict. A list of links tells you where to start. A source table tells you why a sentence belongs in the report. In a public example we checked in Tabbit, two authoritative pages used very different labels for HTTP 418. Their dates and roles explained the difference.

Start with a question you can verify

Our question was narrow: how is HTTP 418 listed in the current public registry, and where did the teapot wording come from? We checked the registry and two RFCs on November 6, 2026. This was a guided browser check, with the verdicts reviewed by the author. For an autonomous run, give the agent the same bounds and ask it to return unresolved rows before drafting.

Write the scope in the first line of the assignment. Name the relevant date and what counts as a primary source. “Find the current registry label and the historical wording” is easier to check than “explain what HTTP 418 means.” For a larger study, start with a few primary pages and read more only when a claim needs it. Use the deep research use cases guide to choose what belongs in the research plan, then use the first-task checklist to set the pages and actions in scope.

Follow the claim to the original passage

The sample CSV keeps the URLs and verification details for all four rows, including the deliberately invalid candidate. IANA’s table and RFC 9110 refer to the same authority chain, so count them as linked evidence. RFC 2324 answers a different question. A server that returns 418 would be a separate observation and would need a source about that implementation.

For every consequential sentence, click through the citation, check the final URL after redirects, and find the named section. Copy a short passage or write a paraphrase that preserves the conditions. If the source only says “some implementations,” the report cannot say “all.” If a single sentence asserts both current status and historical origin, split it. A browser CLI workflow can capture exact page text, while the MCP versus CLI comparison covers how those observations reach an agent.

Keep the rows that need a decision

Use separate verdicts for supported, contradicted, partial, and unverified. A 404 answers a question about the request, and you still need evidence for the original claim. For a login wall, save the visible title, mark the body unread, and leave the claim out of the final summary unless another suitable source supports it. Review what the browser permission guide says about the active session before handling gated pages.

If two sources disagree, record both and check whether they cover the same date, definition and scope. In our example, the apparent conflict disappears once we distinguish registry status from historical wording. In other cases, keep both values and tell the reader what would settle it. Add a column for the date checked when results could change, and refresh claims from a primary source before reusing the report.

Give the agent a deliverable it can check: “Return the source table first. For each claim, record the URL, heading or row, the specific passage, the check date and a verdict. Keep failed requests in the table. Draft the conclusion only from supported rows and label any inference.” Review a few successful rows plus every unresolved row. The browser automation overview explains the browser side of the task, while the research workflow guide covers collecting materials. You can repeat the public example in Tabbit using the original sources below.

Sources: IANA HTTP Status Code Registry, RFC 9110 §15.5.19, RFC 2324 §2.3.2.

Secholar.L

Growth & Content at Tabbit

Secholar.L writes hands-on guides about AI browsers and agent workflows, comparing tools with real research and citing verifiable sources.