Webhound builds long-running AI research agents that scale quality with time and budget. Our agents can create either structured datasets or fully cited research reports.
This is the 3rd launch from Webhound. View more
Webhound
Launching today
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.
Free Options
Launch Team / Built With
If a $5 run hits a dead end early, does the user get to adjust the budget mid-stream or is it strictly set at the start?
Webhound
@freya_jensen_d Yes, you can increase the budget while Webhound is researching. You can also stop the run early if you no longer think the question deserves more work.
Having said that, we’ve seen many examples of runs where the fourth or fifth lead got past what first looked like a dead end.
Congrats on the launch! qq When the budget runs out mid-run, does the report tell me what it did not get to?
Webhound
@alieksia Yes. When the budget runs out, Webhound finishes the report with the evidence it gathered and lists the gaps it did not reach or could not resolve.
You can inspect the research plan and working documents to see which branches remain open. Webhound also suggests follow-up questions aimed at filling those gaps. If one matters, you can add more budget and continue the same run.
@mfkhalil Thanks. Over MCP, does the gap list come back as structured data or as prose in the report? Topping up the budget is a decision I would rather make in code than by reading a document.
Webhound
@alieksia The follow-up recommendations come back as structured data through webhound_get_session and webhound_get_evidence_pack. Each recommendation includes a title, description, suggested budget, and the guidance Webhound would use for the next research cycle. Your code can inspect those fields and call webhound_add_budget if the extra work passes your spending rules.
@mfkhalil
Thank you, that is exactly the shape I wanted. Having the suggested budget as a field means the spend decision can sit in code rather than in a prompt.
UnitPay
Does it search only public websites, or can it also work with my own documents and internal knowledge base?
Webhound
@vijay_gorfad2 It can use private documents too. You can attach PDFs, documents, spreadsheets, or text files, and Webhound will use them as source material alongside public web research.
Through MCP, your agent can also pass Webhound material from systems it already has access to. For an internal knowledge base, you can save its API key or token under Secrets. Webhound can then call Notion, a database, or your own internal API during the run and use that information in its research.
How well does it handle complex prompts with multiple research objectives in a single request?
Webhound
@voyager21 Very well! It turns every prompt into a research plan, breaks each objective into it's own task, and gathers evidence for each one.
The main constraint is the budget. A broad prompt with a small budget forces tradeoffs, so Webhound shows which objectives received less coverage and suggests follow-up research for the remaining gaps. You can also tell it which objectives matter most in the prompt.
Webhound
Hi Product Hunt, I'm Theo, the other founder of Webhound.
Since Moe has already covered a bunch about our product I wanted to give some of my (admittedly messy) thoughts on what I've learned from designing this more agent-facing version.
Recently my cofounder and I have been noticing that a lot of our most consistent users are actually agents, and that share is only growing. As our discussions started to trend towards designing for agents, my question started to become: should we be?
I don’t think we should be designing for agents just yet. And this is not (entirely) because of my tendency to favor human centered design, but rather an attribution problem / thesis.
When we talked to the users behind the agents with carte blanche to our product, we kept hearing “I don’t want to have to leave my second brain.” Memory, context, and integrations are creating the same kind of lock-in as social graphs did with social media.
Many founders I talk to are of the belief that this will change, and that we will all be using a bunch of different AI interfaces in the future. My counterpoint to that is to harken back to the myriad of apps I used to have on my iPod touch (in comparison to the 3-4 apps I use today, not even mentioning all of the hardware products that got condensed into the iPhone).
This process of divergence in tools seems to happen every time a new technology explodes, and then we converge back to the single interface model.
If we assume that people are going to be working from a single centralized interface, the model I start to think about is heavily reliant on the control surface, how human intent is injected into it, and what steps exist within that platform / tool that are beyond my view.
When I talk about designing for agents, I am not talking about agents as the end users. As an HCI major I am still thinking about the human as the end user. There are just more layers of abstraction between human will and silicon execution. This is why I think it’s important to factor the control surface into the mental model / think about where human goals / input enter the system.
With that as the precedent, here are some of the more practical things I’ve learned so far.
For open ended tasks, budget can be a better stopping primitive than subjective completion criteria + an LLM as a judge (contractor).
Memory and workspaces / file structure + integrations create lock in. Try to build something that requires users to leave their second brain as infrequently as possible.
Error messages should be verbose and imply fixes. Since a lot of failures and behaviors sit on the user agent side, it can be hard to view these failure modes. Try to capture them with error logging.
Define your rules of engagement / best practices for agents to interact with your tool / when to call.
Don’t block when you don’t need to. Make state and status visible to avoid hangs / blocking the main agent.
Onboarding should be an MCP endpoint and should be done through the user’s agent. When they create a key, give the user a text prompt to copy to set up the MCP with their agent.
In this prompt, ask the agent to state what environment it is in (Claude Code, Codex, etc), use that client’s supported global MCP configuration unless the user wants it to be project level, save the exact server configuration you give it, call the health endpoint so that you don’t have false positives for successful installs, and then call your onboarding endpoint.
We’ve found this works best when the onboarding endpoint returns steps serially and you ask the user’s agent to keep calling “next step” until it returns that there aren’t any remaining.
There is also intent monitoring, where you have tool search and can see what people are asking their agent for your tool to do. We decided against doing this because it felt too sketchy, but it is something we thought about.
These are the learnings from a couple week deep dive and I hope they are useful to some of you, though I expect them to be relatively fleeting as the interface evolves.
Webhound
@theo_schmidt Hey Theo!
Swytchcode
Supercool. By the way what can the agents research?
Webhound
@chilarai Anything you ask it to! We've used it to do investigative journalism, competitor research, market maps, gather context to build agent skills, prospect research, shopping research, product comparisons, and so much more.
It's also natively able to search over and access generally hard-to-access websites like LinkedIn, Reddit, X, Youtube and others. It also has code execution and download capabilities so it can fetch information from APIs or hosted files if needed.
Swytchcode
@mfkhalil Nice. I need to do a lot of research. Will try
the budget-as-stopping-primitive idea makes sense to me. curious about the opposite failure mode though - what happens when a topic just doesn't have much written about it, like an internal process at a small company or something too new to have coverage. does it recognize early that more budget won't surface anything and stop, or does it keep spending trying to find sources that don't exist? that seems like the case where the dial wouldn't actually save you money.