Webhound - A research engine for your agent
by•
Research has no natural finish line. An agent can spend ten minutes or ten hours on the same question, and both answers can look finished. Webhound lets you choose how much work the question deserves. Give it a question and a dollar budget. It follows leads and checks weak claims until the budget is consumed, then returns a cited report or sourced dataset with the sources and working documents behind it. Run Webhound yourself or call it from your agent through MCP or the API.
Replies
Budget as the stopping rule makes sense, especially when another agent is waiting on the answer. The trust layer I’d want is a short handoff note: what was checked, what was intentionally skipped, and which unresolved claims could change the decision if someone spends another hour.
Webhound
@krekeltronics Totally agree! Both the MCP handoff and the web app include the output, working documents, claims, sources, limitations, and structured completion recommendations with suggested follow-up budgets. The end user can see what remains thin and decide whether more work is worth the cost.
MockRabit
Webhound
@ishwarjha I kept trying to use coding agents to run research, and it felt like I had to manually force them to keep digging deeper and deeper, and even then they rarely ever got past a shallow pass of what's out there. We built Webhound so that I could decide how much work the research needed at the start, then let it cook. It's built on top of our harness which is specifically made for research, so it goes way deeper than anything else out there.
I'd love to see how Webhound handles edge cases, like sources with paywalls or outdated information. How do the research agents adapt to these challenges?
Webhound
@aymnart Webhound does not cite a page it could not inspect. When it hits a paywall, it looks for an accessible primary source or open version; if none exists, it flags the gap. You can also give it an API key if you're already paying for the source, and it can access it programatically. For stale information, it checks publication dates and current primary records while preserving conflicts it finds.
Congratulations
Webhound
@madalina_barbu Thank you, Madalina! Appreciate the support.
This looks useful, I lose hours copying company details off websites into a spreadsheet by hand. Having the choice between a clean dataset and a fully cited report covers pretty much every research job that lands on my desk. If I ran the same query again next month, would it give me a fresh dataset I could diff against the old one to see what changed?
Webhound
@doganakbulut Yes. A rerun creates a fresh sourced dataset using current information. We don't have a native one-click diff view today, but you can export both runs or have your agent compare them through MCP or the API. Each cell keeps its source and extraction time, so you can audit why a value changed.
Depth over speed is a refreshing pitch when everything else is racing to answer in two seconds. Exposing budget as the control on research quality is smarter than hiding it behind a vague quality slider. When it builds a dataset rather than a report, how does it handle two sources that contradict each other, does the row keep both values or does the agent pick one?
Webhound
@adamkamaneh by default the agent will pick one, but the cell level sourcing will tell you that there were contradicting sources. However, if you specify in your prompt, contradictions can be handled however you want (include all answers with confidence scores for example).
Budget as the stopping primitive answers how much, and there's a second question sitting under it: how much does the same $5 vary? Two runs on one question at one budget follow different leads, and an agent that follows leads is path-dependent by construction — whichever source it happens to open early reshapes everything after it. The report is a function of the budget and of which door it went through first.
That lands hardest exactly where Clemente was pointing, on the MCP path. A human feels a thin answer and re-runs it. An agent takes the first report as ground truth. I do eval work on my own app's generated output, and the number that changed how I ship wasn't the average score — it was the spread across identical inputs. The mean looked healthy for weeks while the bottom of the distribution was quietly unusable.
Have you measured that spread on a fixed question and budget? And does the per-claim confidence score reflect run-to-run stability, or only the evidence inside the single run that produced it?
Webhound
@narek_keshishyan This is a very salient point and yes, there definitely is a large path dependent variance with seemingly silent failure modes. One interesting thing is that it tends to decrease as budget increases. I haven't done enough measurement of the stability of confidence scores, but from the few tests I have run in the space they seem pretty stable in spite of not explicitly pulling anything on the run-to-run scale.
@theo_schmidt That variance shrinks as budget goes up makes sense, and it does put the noise where it hurts most: the cheap runs are the default, and the MCP path is almost all cheap runs by definition.
The confidence stability is the part I'd poke at. Stable confidence is good news if the underlying runs agree, and bad news if they don't, because then the score is tracking something other than the evidence it found. The check I'd run is pairwise: same question, same budget, two runs, and measure how much the claim sets overlap rather than how much the confidence numbers move. If overlap is 60% and confidence is flat across both, the number is calibrated to fluency somewhere. If both hold steady, you have something genuinely rare and worth saying out loud in the docs.
The dollar budget is a clever constraint, but the stronger idea might be making research depth explicit. Most tools hide the stopping decision behind a confident-looking paragraph. Here, at least, I can decide whether a question deserves five dollars or five minutes. I like that “not enough evidence” can be a valid output.
Webhound
@ra5tadark Thanks Rasulz! Completely agree, “not enough evidence” should be a valid result. Webhound keeps its sources, limitations, and unresolved claims visible, so you can still see what the budget established when the research results are uncertain.
Moe — the disagreement-surfacing answer to Gal is solid. My research problem's different though: federal contract award data and past-performance records aren't scattered across the open web, they're stuck behind a clunky government portal with no public API or real search. Does Webhound handle sources like that, or is it built for open-web research?
Webhound
@medal411 Right now, Webhound works best with open-web sources and services reachable through an API. You can save credentials for APIs you have access to. A government portal with no usable API or indexable pages is a limitation today, and support depends on the portal.
Which systems are you using, and which records do you need from them? Federal procurement data is something we’d look at building direct support for.
The budget-based depth control is an interesting way to make research effort explicit. How does Webhound decide when a claim needs further verification, and can users inspect why the agent stopped researching a particular lead?