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
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
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?
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.
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?
makes sense, flagging the lack of evidence as a limitation instead of just going quiet is the right default. thanks for the answer
YourGPT
Congrats on the launch, Moe.
Webhound is tackling a really interesting problem with AI research the stopping problem is definitely something that gets overlooked. I especially like the idea of using a dollar budget as a research primitive instead of letting agents run indefinitely. I will defiently try this out
Webhound
@neha_8 Thanks a lot! Let me know if you have any feedback.