research agent.

We kept running into the same problem with AI chatbots: they answer fast and sound confident, even when the information is wrong or outdated. Working around Web3 and AI content, we wanted something we could actually trust to research a topic properly and explain it using sources we could verify ourselves. That gap between "confident" and "correct" is what pushed us to build an agent that researches before it writes, instead of simply pulling an answer from memory.

What it does

You give it a topic. It searches the web, reads multiple sources, compares what it finds for agreements and contradictions, and only then turns the research into a clear, beginner friendly explanation with citations attached. If the available research is weak or the sources disagree, it tells you instead of covering the uncertainty with confident sounding text.

How We built it

We designed the architecture before writing the first line of code. The backend runs on FastAPI with a LangGraph pipeline covering intent classification, query planning, parallel web search, two phase source validation, content extraction, knowledge synthesis, an iterative gap detection loop, and a final writer stage. Instead of creating a flat summary, the knowledge stage builds a structured graph of concepts and claims. Every external service, including the language model, search API, and page extractor, sits behind its own swappable interface, so the pipeline itself doesn't depend on any specific provider.

The frontend is a Next.js app built around a single page state machine, with its own visual identity instead of the usual generic AI chat interface. The product is supposed to feel like a research tool, not another chatbot.

Challenges We ran into

The design phase was straightforward. Implementation was where things got messy. We ran into a long list of practical bugs: files that looked fine but were actually empty on disk, stale Python bytecode hiding real fixes, and a models file that ended up with two conflicting definitions of the same class after a refactor.

The bigger problem was working within free tier AI model limits. We started with one provider, hit a billing wall halfway through the build, and switched to Groq. That brought its own problems: strict tokens per minute limits that truncated responses, a reasoning model that used its entire token budget thinking before producing an answer, and a smaller model that sometimes returned the JSON schema instead of actually filling it in. Each problem needed a different fix: changing token limits, assigning different models to different pipeline stages, throttling concurrency, and rewriting prompts to make the expected output structure explicit.

What we learned

The biggest lesson was that good architecture matters most when things start breaking. Because every node had one clear responsibility and external services were separated behind clean interfaces, we could switch AI providers halfway through the project without rewriting the pipeline itself. We also learned to actually read errors before reacting to them. A rate limit error and a code bug can look similar in a stack trace, but they require completely different fixes. Learning to tell the difference quickly saved a lot of wasted time. Most of all, we learned that building a reliable AI agent isn't really about clever prompts. It's about careful, boring engineering: validation, fallbacks, and handling failure honestly at every step.

Built With

• next.js
• python
• react
• typescript