Launched this week
AnySearch
Real-time structured search trusted by agents and developers
1.2K followers
Real-time structured search trusted by agents and developers
1.2K followers
A search tool for agents, not a search box. AI agents are only as good as the information they receive. When connected to AnySearch, your agent gets filtered, de-duplicated, and structured information from trusted sources searched in parallel, helping it produce more reliable results. Free to start.
AnySearch
Hey Product Hunt 👋Grant here from the AnySearch team.
We’re a team of AI developers and engineers building search infrastructure specifically for AI agents.
Traditional search was built for people. We built search for AI agents.
People skim links, compare sources, and decide what to trust. Agents don't.
AnySearch delivers real-time structured search that agents and developers can trust.
When that information is stale, incomplete, poorly routed, or buried in messy HTML, the final output becomes less reliable. Sometimes agents search again and again. Sometimes they confidently build on weak context. Either way, the workflow breaks.
That's the problem we built AnySearch to solve.
🧠 Understands what a query is asking for
🔍 Searches trusted sources in parallel
🚫 Filters SEO spam, ads, and duplicate results
📄 Returns clean, structured information for agents
Why developers use it:
· Fewer repeated search calls
· Less HTML cleanup
· Cleaner context for models
· More reliable agent outputs
Works with your existing workflows
AnySearch is available through:
· Skill
· MCP
· API
Install AnySearch in your agent👇
1. Go to https://anysearch.com/
2. Click Add to Agent in the top right corner.
3. Select Skill, copy the prompt, and paste it into your agent.
Your agent will handle the installation automatically.
Try AnySearch today, add it to your agent, and get started for free.
We'd love your feedback.
PicWish
AnySearch
@mohsinproduct Good question! We don't try to solve challenges — we focus on not triggering them. Real browser engine, proper fingerprinting, human-like patterns, etc.
It works on most sites that trip up standard crawlers. For the really aggressive ones, honestly no silver bullet — but those are rare in practice.
AnySearch
@granthan Congratulations
RiteKit Company Logo API
@granthan Congrats on launching AnySearch — search infrastructure that agents and developers can actually trust is a real need, and the positioning is sharp. We made you a free launch video for it (below), yours to download or re-post anywhere, no strings. I suggest adding it to your launch page in here; launches with video tend to do better than those without.
We built it with FoxPlug: paste your site and it turns what you just shipped into a launch video, images, GIFs and posts in about 30 seconds. This one is on us — make your own free at https://foxplug.com
AnySearch
@saulfleischman Thanks Saul, really appreciate the support and the kind words.
We’re glad the positioning resonates — AnySearch is built to help agents and developers access reliable, structured real-time search. We’ll check out the video and consider adding more launch visuals to our PH page.
AnySearch
@saulfleischman Thank you so much, such a high-quality video！
AnySearch
@saulfleischman Whoa, this is awesome. Thanks for making it for us!
@granthan Congrats. For a developer building multi-step agents that must cite or justify actions, how does AnySearch handle provenance and source confidence over a chain of reasoning?
AnySearch
@granthan @swati_paliwal Great question. We think of AnySearch less as “the agent says trust me” and more as an evidence layer for the agent.
For each step, the agent can pull structured results with source attribution and confidence/freshness signals, then carry those references forward into its own justification. So instead of only getting a final answer, you can keep a trail of which sources supported which intermediate claim or action.
We’re also careful not to pretend confidence is magic. It’s a source/result-level signal that developers can combine with their own policies, especially when sources conflict or when a human review step is needed.
Foyer
The "real-time structured search trusted by agents" framing raises the question of what structured actually means here. Is the output schema defined by the caller, something like a typed JSON spec the agent passes in, or is AnySearch inferring structure from the query and returning whatever shape seems right? That distinction matters a lot when an agent is downstream and needs to reliably parse the response without a validation step. Also curious how you handle sources that block crawlers aggressively, since real-time web search quality tends to fall apart fast on exactly the sites that have the freshest information.
AnySearch
@fberrez1 The structured content fed back to the agent by AnySearch is in Markdown format, with a single core objective: the search results should be directly used by Agents. This means that the returned context is clean, comes with precise citations, and the agent can infer upon receiving it, rather than spending hundreds of tokens guessing first.
AnySearch
@fberrez1 Spot on—these are arguably the two biggest bottlenecks for agent builders right now!
1. On the "Structured" output: Currently, AnySearch infers the structure and returns Entity-Enriched Markdown (cleanly separating core facts, citations, and metadata). We standardize this to drastically reduce LLM cognitive load, giving your agent a reliable format without needing a heavy validation step. That said, letting developers pass strict JSON schemas is a fantastic idea, and we’re actively exploring it for our roadmap.
2. On aggressive anti-bot blocking: You're absolutely right—generic scraping fails when you need fresh data the most. We solve this structurally: rather than fighting Cloudflare as a headless browser, our Smart Intent Routing bypasses this entirely by tapping into directly integrated, authoritative vertical feeds (finance, health, cyber, etc.).
Really appreciate you digging into the architecture!"
AnySearch
@fberrez1 We don’t try to solve challenges, we just try not to trigger them in the first place, which gets us a lot further than standard crawlers in practice. By structured, I just mean a consistent markdown format (title, url, context) that works well for agents, plus a JSON API if you want actual structured data on the developer side.
The MCP + Skill support is the right call, that's clearly where agent tooling is heading. Curious about one thing: for slower-moving verticals like legal or academic sources vs something like finance that needs to stay close to real-time, are you running different caching/refresh strategies per domain, or is it one unified layer? Also nice that you published actual numbers against Brave and Parallel instead of the usual "faster and smarter" launch copy, that's rare to see.
AnySearch
@emir_citak Thanks for your recognition. We adopt different update strategies for various vertical search areas in our self-built sources. Welcome to experience.
AnySearch
@emir_citak Glad you appreciated the hard benchmarks—we're tired of vague marketing fluff too! 🤝
To your question: you nailed it, the caching is absolutely domain-specific. Our Hierarchical Routing applies dynamic TTLs based on the vertical. Fast-moving data (like live finance) hits real-time feeds directly, while deep-research domains (like academic/legal) rely on specialized caching layers.
That’s exactly how we balance deep retrieval while keeping our overall latency incredibly low!
AnySearch
@emir_citak Thanks — really appreciate that. We also believe agent tooling is moving toward MCP, Skills, and API-first workflows, so that is where we are focusing.
And yes, freshness is domain-aware rather than one-size-fits-all. Fast-moving areas like finance or news need fresher sources and shorter refresh windows, while slower-moving but source-sensitive areas like academic, legal, patents, or documentation can use longer cache windows with more emphasis on source quality, structure, and provenance.
That helps us balance latency, cost, and reliability without treating every source the same way.
And thanks for noticing the benchmarks. We wanted to publish actual numbers because developers should be able to evaluate search infrastructure with real measurements, not just vague claims like “faster” or “smarter.”
The de-dupe plus parallel trusted-source angle is the useful part here, since most agent failures I see are stale or duplicated context rather than missing data. One operator question: can I scope the trusted-source set per agent (e.g. pin a support bot to our own docs plus a couple of domains), or is the source list global across all calls? That is the line between this being safe for a customer-facing agent versus just research.
AnySearch
@hazy0 Context bloat and duplication are exactly what kill agent reasoning—spot on.
To answer your question: Yes, you can absolutely scope it. We built Private Capability Isolation (currently Enterprise-only) specifically for this use case.
While the global routing is amazing for open-ended research, for a customer-facing support bot, you can pin the search strictly to your own docs or a whitelisted set of domains. We completely agree with you—having that hard boundary is non-negotiable for production safety.
AnySearch
@hazy0 That’s a great point, and I agree this is a key requirement for customer-facing agents. Today, AnySearch is closer to request-level source control: developers can constrain or bias retrieval for a specific query or workflow when they want the agent to search within a defined scope. Per-agent trusted-source policies, like pinning a support bot to only your own docs and a few approved domains, are a very valuable kind of operator-level control, especially as teams move from research agents to production agents. We want to think carefully about this capability rather than just add a shallow toggle. Your example is very helpful, and we’ll take it into account as we continue improving source control and provenance in AnySearch.
The MCP + skill install path is the right call — "paste the prompt and the agent installs it" is exactly how agent-facing infra should distribute.
Two things I'd want to know before wiring it into an agent loop: what does structured actually mean here — a fixed result schema, or can the calling agent shape it per query (product/price/availability fields for a commerce lookup vs citation-style for research)?
And what latency should we budget? Parallel trusted-source search + dedup + structuring sounds like real work per call, and for a multi-step agent that searches five or six times per task, p95 per call matters more than anything.
Congrats on the launch @granthan
AnySearch
@akbar_b Thanks! To answer both:
Structured output: we have a fixed schema per result (title, url, context) in markdown, plus a JSON API for full structured data. The schema is consistent, so your agent can parse reliably without per-query shaping.
Latency: p50 is ~1s, p95 under 5s. For a multi-step agent loop, I'd budget 5-8s per call to be safe. We're actively working on bringing p95 down.
@granthan thanks for the details around percentiles, will check the product out.
The deduplication across parallel sources is the part I'm most curious about. In practice, the same story or data point gets syndicated everywhere, and agents end up with 4 near-identical chunks in context that all look authoritative. How are you handling that, string similarity or something semantic? And how do you manage source trust when a "trusted source" is just wrong about something recent?
AnySearch
@rnagulapalle
Thank you for the thoughtful comment — really sharp questions.
Improving the information density of AI Search results is genuinely one of our core objective functions. On the deduplication front, our approach falls into two categories:
1. URL-level dedup. Straightforward — if the same URL is recalled multiple times, we deduplicate at that layer.
2. Information-density ranking (this is the important one). The real challenge isn't URL duplication — it's exactly what you described: different sources reporting the same story with different phrasing but near-zero marginal information gain. To address this, we've built our own information-density ranking algorithm. For multi-intent queries, rather than optimizing purely for relevance, we optimize for maximizing information density when organizing the final result set. This involves jointly accounting for relevance, cross-passage redundancy, information entropy, and a corresponding length penalty — all to ensure that every token the user consumes delivers the largest possible information set, rather than having the same story rehashed three different ways.
As for the dynamic trust problem you raised — when an "authoritative source" gets breaking news wrong — you've called out a genuinely hard one. We're actively researching dynamic trust mechanisms for this, but honestly, it's very difficult to strike the right balance across quality, latency, and cost. We're committed to solving it and plan to roll out improvements in future releases.
Thanks again for the engagement!
@morecry The info-density ranking approach is interesting, optimizing across relevance + redundancy + entropy is basically MMR with extra steps, curious if you're doing that at retrieval time or as a reranking pass after. On the trust problem, the honest answer might just be recency weighting with a decay curve and accepting that no static trust score survives a fast-moving news cycle. Hard to get right without adding latency.
AnySearch
@rnagulapalle
We mainly do this at the ranking stage — or what I'd call the "selection" stage.
My take is that in AI/agent scenarios, the traditional notion of "ranking order" doesn't really hold anymore. Users don't need a sorted list to scan top-to-bottom; what they need is subset selection from a large recall pool. That essentially becomes the second stage of search in the agent era: it's no longer ranking, it's subset selection.
On the latency front, we try to keep it lean on two fronts: use word-level features wherever possible instead of document-level recomputation, and avoid re-running models on signals that were already computed in the first stage. The core idea is to keep the subset selection step as lightweight as possible by front-loading computation into the reusable stage.
This is a good direction for agent tooling. The hard part is not just search quality, it is making the agent carry source confidence forward instead of turning a clean JSON result into false certainty. I would love to see provenance, freshness, and failure states treated as first-class fields in the response.
AnySearch
@krekeltronics Good point on avoiding 'false certainty' in agent reasoning.
We currently use Entity Enrichment to separate raw facts from citations to preserve provenance. However, explicitly exposing 'freshness' and 'failure states' as first-class fields is an interesting angle to help agents reason better about the data quality.
We'll definitely consider this as we refine our API. Thanks for the feedback!