Webhound - A research engine for your agent

Hi Product Hunt, I’m Moe, the founder of Webhound. I’ve worked on AI research since 2023.

I started Webhound because research agents have a stopping problem.

A coding agent can stop when the tests pass. Research has no equivalent finish line. An agent can spend ten minutes, two hours, or twenty hours on the same question, and each answer can look complete. Research agents tend to stop once they have enough evidence to sound confident.

You still do not know which leads they skipped, where sources disagreed, or whether another hour would uncover the fact that changes your decision. The agent makes that stopping decision for you.

Our thesis is that budget should be a research primitive. In plain English, your prompt tells Webhound what to investigate. Your dollar budget tells it how much work to put in and caps what you can spend. At our current rate, $5 funds about 75 minutes of research.

Search finds sources for the query in front of it. Research reads those sources and follows the leads they reveal. One source can change what Webhound needs to search for next.

You get a cited report or sourced dataset, along with the sources and research notes behind it. You can inspect how Webhound reached its conclusions and where the investigation still has gaps.

Extra budget must earn its cost. We judge a larger run by the useful evidence it adds and whether that evidence improves your decision. Extra length does not count.

You can run Webhound in the app or use it behind Codex, Claude Code, Cursor, Manus, or your own software. Your agent can hand off a question, continue working, and retrieve the finished research later.

New accounts include one $5 Report or Dataset. There is no subscription.

I want blunt feedback on the core idea: does a dollar budget feel like a useful way to control how much research gets done? Do the sources and research notes help you decide what to trust?

If you have a question where missing information could cost more than the research, leave it below. We’ll run a few in public today.

How does Webhound decide when to stop digging deeper versus continue researching, especially for open ended or ambiguous topics?

dollar budget as the stopping primitive is a genuinely clean idea, most research tools just stop when the output sounds confident rather than when it's actually verified. one thing I didn't see covered - when two sources genuinely disagree on a claim and the budget isn't there to fully resolve it, does the final report surface that disagreement explicitly, or does it pick a side (majority source, more authoritative domain, etc) and present one answer? for a cited research tool I'd actually want to see the unresolved conflict called out rather than smoothed over

Really like the "onboarding should be an MCP endpoint" framing — that serial next-step pattern is clean. One edge case I'd be curious about: if the health check passes but step 3 of 5 fails on a config mismatch, does the endpoint expect the agent to retry from that step, or restart the whole sequence? Partial-failure handling in a multi-step handshake like this seems like it'd need its own design pass separate from the happy path.

Does it search only public websites, or can it also work with my own documents and internal knowledge base?

Supercool. By the way what can the agents research?

Interesting! That framing of budget-as-stopping-primitive is definitely worth attention. Most research tools stop when the prose sounds finished rather than when the work is actually done. Curious whether you guys plan the search tree up front and rank leads by expected payoff? Is it greedy step by step and just stops when the meter hits zero?

I see that this is positioned as the "research engine" behind your AI agent, but it wasn't clear to me how this is different than getting the frontier model to do deep research and continually prompting it to continue researching after the default stopping point.

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.

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?