About the Project Tweet FactChecker is a one-click fact-checking tool for X/Twitter posts. The idea is simple: when a user sees a suspicious tweet, they can click a “Fact Check” button directly inside the browser. The extension sends the tweet to a backend pipeline, where multiple agents extract claims, evaluate evidence, critique the reasoning, and return a concise verdict in an overlay.

Inspiration

Social media moves faster than truth. A misleading post can spread widely before most people have time to verify it. We wanted to build something that fits naturally into the place where misinformation appears: the timeline itself. Instead of asking users to copy a tweet, open another tab, search manually, and compare sources, Tweet FactChecker brings the verification workflow directly into the browser. Our goal was to make fact-checking feel lightweight enough that people would actually use it in the moment. What It Does Tweet FactChecker adds a fact-checking layer to X/Twitter: A browser extension detects tweets and injects a fact-check button. When clicked, the extension sends the tweet text to a FastAPI backend. The backend runs a multi-agent pipeline: ClaimAgent extracts checkable claims from the tweet. EvaluatorAgent searches for supporting or contradicting evidence. CriticAgent reviews the reasoning and catches weak conclusions. ClaimAgent extracts checkable claims from the tweet. EvaluatorAgent searches for supporting or contradicting evidence. CriticAgent reviews the reasoning and catches weak conclusions. The system aggregates the results into a final verdict. The extension displays the conclusion in a clean floating overlay. Conceptually, the pipeline turns a tweet into structured reasoning: tweet \rightarrow claims \rightarrow evidence \rightarrow critique \rightarrow verdict How We Built It The project is split into two main parts: extension/: a TypeScript + Vite + Manifest V3 browser extension backend/: a Python 3.12 FastAPI service The extension handles tweet extraction, UI injection, API calls, and result rendering. The backend owns the fact-checking pipeline, shared contracts, mock responses, real-agent wiring, and integration smoke tests. A key design decision was to keep the data contract frozen between frontend and backend. The Pydantic models in backend/contracts/models.py mirror the TypeScript types in extension/src/types.ts, so both sides agree exactly on the shape of requests and responses. We also built the system so it can run in two modes: Mock mode for local development without API keys Real agent mode using USE_REAL_AGENTS=1 for the full multi-agent pipeline This made it easier to develop the UI and backend independently while still preserving an end-to-end path. Challenges We Faced One of the hardest parts was keeping the frontend and backend synchronized. Since the extension depends on exact response shapes, even a small contract mismatch could break the overlay rendering. Freezing and mirroring the contract helped reduce that risk. Another challenge was designing the agent pipeline so it did more than produce a single rushed answer. We wanted the system to separate claim extraction, evidence evaluation, and critique, because fact-checking requires more than just confidence. It requires structured reasoning. We also had to balance real-world usability with development speed. The browser extension needed to feel immediate, while the backend needed enough structure to support mock testing, real agents, and future expansion. What We Learned We learned that fact-checking is not just a search problem. It is a workflow problem. A useful system needs to identify what is actually being claimed, evaluate evidence carefully, and explain the result in a way users can understand quickly. We also learned the value of strict contracts between frontend and backend. By treating the response schema as a shared source of truth, we made the system easier to test, debug, and extend. Most importantly, we learned that AI agents are most useful when they have clear roles. Splitting the pipeline into claim extraction, evaluation, and critique made the final result more reliable than a single all-purpose step. What's Next Next, we want to improve source citation quality, support multi-claim tweets more deeply, add richer verdict explanations, and make the extension more robust across different X/Twitter layouts. We also want to experiment with confidence scoring and user feedback so the system can better communicate uncertainty instead of pretending every answer is absolute.