I Rebuilt a Browser Fact-Checker on AWS, and AgentCore Web Search Was the Missing Piece

🎬 Also available as a blog walkthrough video if you’d rather watch than read.

What Got Me Started

I came across an open-source browser extension that fact-checks YouTube videos and live streams in near real time, entirely in the browser [3]. The idea is clean and the pipeline is easy to describe: transcribe what is being said, identify the verifiable claims inside the transcript, verify each claim against the web, and highlight the result inline as the video plays. It leans on Google Gemini’s built-in search grounding for the verification step, and it does the job well for a single user with a personal API key.

What stuck with me was not the extension itself but the shape of the problem. A fact-checker is really one small, reusable thing wrapped in a lot of plumbing. The reusable thing is a function: give it a claim, get back a verdict with evidence. Everything else (capturing audio, splitting text into claims, drawing colored highlights) is a client that feeds that function and renders what comes back. If I could build that function well on AWS, I could put any number of clients in front of it.

So I set out to rebuild the idea as an AWS-native claim-verification service. The interesting question was the verify step, because that is where the original’s design choice lives: it works because it uses a model with native, citeable web-search grounding. On Amazon Bedrock, Claude is an excellent reasoner but does not search the web on its own. Until recently, grounding Claude meant building your own search-and-retrieval tool or standing up a retrieval corpus. That changed.

The Piece That Closed the Gap

Web Search on Amazon Bedrock AgentCore became generally available on 19 June 2026 [1]. It is a fully managed, Model Context Protocol (MCP) compatible web search tool, exposed as a connector you attach to an AgentCore Gateway. An agent discovers it with a standard tools/list call and invokes it like any other MCP tool. There are no search APIs to provision, no outbound keys to manage, and no result parsing to maintain [1].

A few properties make it a good fit for fact-checking specifically:

• It is backed by a web index Amazon operates directly, spanning tens of billions of documents and refreshed within minutes, so a claim about something that happened this morning has a chance of being checked against this morning’s reporting [1].
• It includes a knowledge graph for high-confidence entity and relationship facts, aimed at reducing the drift you get when a model stitches an answer together from snippets alone [1], a design goal I haven’t measured independently.
• Every web result carries a url, a title, a publishedDate, and a semantically extracted text snippet [1] [2]. Publication dates matter a lot for a fact-checker, because “true as of when?” is half the question.
• Queries are not sent to a third-party search API: the Gateway routes the request internally to an AWS-owned connector [1]. That removes one common data-egress review item, the external search processor, while region boundaries, service data handling, logging, retention, and your own policies still get reviewed like any other AWS workload.
• It is model-agnostic through MCP, and the sample agent in the launch post runs Claude Sonnet [1]. So Claude does the reasoning and AgentCore Web Search does the grounded search.

Pricing is 7 USD per 1,000 queries, pay as you go, with no persistent infrastructure [1]. The one constraint to plan around: at general availability it is in US East (N. Virginia) only [1]. For a proof of concept that is fine; for a production EMEA deployment it is a real design input to track.

This is the piece the rebuild was waiting for. AWS even lists fact-checking as a named use case for the tool [2].

The Architecture

The service keeps a single clean seam: claim text in, verdict with evidence out. The backend’s only job is to turn a string into a verdict; everything that produces claims or renders verdicts is a thin client of that contract.

The request path:

1. Login with Amazon Cognito. The client signs in and gets a JWT. No model or search credentials ever sit in the browser.
2. API Gateway (REST) with a Cognito authorizer fronts two endpoints: /extract (text to claims) and /verify (claim to verdict). Each is a Lambda function.
3. Claude on Amazon Bedrock, through the Converse API, does the language work. I use forced tool use so the model returns structured output (clean JSON) instead of prose I have to parse defensively [4]. A cheaper model, Claude Haiku, handles extraction; Claude Sonnet handles the verdict reasoning, where the quality matters most.
4. AgentCore Web Search grounds the verdict. The verify Lambda builds a tight search query from the claim, calls Web Search through the Gateway, and hands the returned snippets and publication dates to Claude with a verdict prompt. The model returns a verdict (TRUE, FALSE, or UNCERTAIN), a confidence score, an explanation, and the sources it relied on, picked from the search results it was handed. In this proof of concept the source attribution is the model’s own; a production build should validate the cited sources against the retrieved results server-side and fill in URLs, titles, and dates from the search response rather than from model output.

One rule I kept from the original because it is a good one: the explanation has to agree with the verdict. If the explanation cites figures that contradict a “TRUE”, the service downgrades it. This label–explanation agreement check, not the sampling-based self-consistency technique from the literature, just a rule that the label and its explanation must not contradict each other, is cheap insurance against a confident model talking itself into the wrong label.

Extract, then verify in parallel

The frontend chunks pasted text, extracts claims from each chunk, and then verifies the claims in a bounded parallel pool rather than one at a time. The original verifies serially by necessity, because a free API tier limits it to a handful of requests per minute. That constraint does not apply here: Bedrock and AgentCore are pay-per-use, and in my runs three parallel claims took about as long as one, the real ceilings are service quotas and Lambda concurrency, not a rate-limited API key. The cap I keep is a cost cap, not a rate-limit workaround. Claims are screened during extraction so I do not spend a web-search query on filler, and the parallel pool has a fixed ceiling so a long paragraph cannot run up a surprising bill.

The UI shows each claim inline as a highlight in the text (grey while verifying, then green, red, or amber) and as a tile below, with the verdict, the confidence, the explanation, and clickable sources with their publication dates. Click any highlight or tile and a detail overlay opens with the full evidence.

A live mode, too

Pasting text is the simple client. The one that matches the original’s “watch a stream” experience is the live mode: the browser captures microphone audio and streams it to Amazon Transcribe Streaming, authorized with short-lived, narrowly scoped credentials obtained through the Cognito login, or via a signed backend proxy, never a long-lived key in the browser, and the backend runs extraction on a rolling window of stabilized transcript. Each new claim spawns a verification immediately, and verdicts stream back over a WebSocket as they resolve, out of order, keyed by claim id so the UI fills them in where they belong.

That live path is the proof-of-concept version of a design I want to take further. A long-lived streaming session is a poor fit for a request/response Lambda, so the production shape is a long-running consumer on AWS Fargate or an AgentCore Runtime session holding the transcribe stream, the rolling buffer, the seen-claims set, and the parallel verify pool, sized against each service’s session, connection, and execution limits, which is exactly the constraint that decides between the two. The core function does not change. verify(claim) stays exactly as it is. The streaming layer is just a new front that produces claims faster and consumes verdict events. That is the payoff of the claim-to-verdict seam.

Here is the paste-and-check flow end to end:

The code is on GitHub: stechr/schristoph-blog-samples/live-fact-checker-aws. It builds on the AgentCore work I’ve been doing in other posts, including an agent that pays publishers per article at the edge [5].

Where This Could Go

The paste-and-check app and the live mic mode are deliberately small. They exist to prove the seam works. Two directions are worth being concrete about.

A browser plugin that checks whatever you are looking at

The original extension is scoped to YouTube. With Transcribe Streaming on the audio path and the same backend behind it, a plugin could fact-check claims on any page or any video you are watching, surfacing a quiet sidebar of verdicts with sources. The browser becomes one more thin client of the same /verify contract; the interesting work stays server-side where the grounding and the cost controls live.

Real-time checking in video calls, including your own claims

Point the same pipeline at a meeting’s audio and it can flag a shaky figure as it is spoken. The obvious framing is checking what other people say. The more valuable one is catching errors in your own statements before you mislead anyone, a quiet “that number looks off, here is the source” rather than a public correction afterward. It is also the hardest to get right: latency has to stay inside a conversational budget, confidence has to be calibrated so it does not cry wolf, and the whole thing has to be unobtrusive enough that people forget it is there. None of that is solved here. It is a direction, not a feature.

Both of these are honestly still proof-of-concept territory. What changed is that the retrieval half of the research project, fresh, dated, cited web results, is now a managed connector. The verification built on top is still model-generated judgment, only as good as the model’s reading of those sources, which is why the agreement check and the visible citations matter. The remaining work is the client experience, the streaming plumbing, and the judgment calls about confidence and presentation. That is a much better place to be starting from.

If You’re Running This on AWS

The whole service is a small set of managed pieces:

• Amazon Cognito for JWT login, so no model or search credentials live in any client.
• Amazon API Gateway (REST) with a Cognito authorizer in front of two AWS Lambda functions (extract, verify).
• Claude on Amazon Bedrock via the Converse API with forced tool use for structured output [4]. Two-model split: Haiku to extract, Sonnet to reason about the verdict.
• Web Search on Amazon Bedrock AgentCore, attached to an AgentCore Gateway with connectorId: "web-search". Inbound auth to the Gateway is your Cognito JWT; outbound auth to the search backend is the Gateway’s own IAM service role with bedrock-agentcore:InvokeWebSearch, so there are no search keys anywhere [1] [2].
• Amazon Transcribe Streaming for the live audio path, with the long-lived session hosted on Fargate or an AgentCore Runtime for production.

Wiring the search tool onto a Gateway is a single create_gateway_target call with the web-search connector; the Gateway handles schema, endpoint resolution, and service auth for you [1]. Mind the region (us-east-1 at GA) and the 200-character query cap when you turn a claim into a search query [1] [2].

Sources

• [1] Introducing Web Search on Amazon Bedrock AgentCore, AWS Machine Learning Blog, 19 June 2026.
• [2] Web Search Tool, Amazon Bedrock AgentCore Developer Guide.
• [3] alandaitch/live-fact-checker, the open-source browser extension that inspired this rebuild.
• [4] Use a tool to complete a model response, Amazon Bedrock Converse API.
• [5] Getting Paid by Agents: A Managed Paywall at the Edge, my earlier post on Amazon Bedrock AgentCore.

#FactChecking #AmazonBedrock #AgentCore #Claude #GenAI

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• FactChecking
• AmazonBedrock
• AgentCore
• WebSearch
• Claude
• AmazonTranscribe
• GenAI
• Serverless