Launch HN: Airweave (YC X25) – Let agents search any app (opens in new tab)

(github.com)

164 pointslennertjansen5mo ago30 comments

Hey HN, we’re Lennert and Rauf. We’re building Airweave (https://airweave.ai/), an open-source tool that lets AI agents search and retrieve context from your existing apps and databases through a single LLM-friendly API (or an MCP server, if that’s your thing). Our Github is at https://github.com/airweave-ai/airweave. We previously did a Show HN https://news.ycombinator.com/item?id=43964201 and since then we’ve recently launched the managed service and new search functionality.

Here’s an example of Cursor using Airweave https://www.youtube.com/watch?v=IvxidK9Ciy4. And here’s a general example of our new search functionality: https://www.youtube.com/watch?v=iqEqc_iGUO8

We came to this problem while building agentic applications for webshop owners and customer service, and noticing most failure modes weren’t about tool execution, but finding the right internal context to enable the right actions.

We started solving, what seemed at the time, a problem for our own use case, and quickly fell into a rabbithole of issues. Company and user data lives across SaaS and databases; it’s sparse, messy, and constantly changing. Agents need a data orchestration and retrieval layer that accepts free-form natural language queries and returns actionable results quickly.

Simply pointing an agent at an MCP server does not equate to fine-grained search functionality or deep understanding of the underlying resource. Most MCP servers are thin wrappers that expose an existing API in a more LLM-friendly way, but this doesn’t actually give the agent any new capabilities beyond what the resource or app already offered. Specifically, it doesn’t give the agent a way to thoroughly search and understand the contents of the resource.

Airweave connects to sources via their APIs, crawls and normalizes content, chunks it, extracts entity relationships, and indexes the chunks in a vector store alongside keyword fields and lightweight graph metadata in Postgres. Data sync is orchestrated with Temporal (handles pagination/rate limits, schedules, and change detection via timestamps and content hashes) so collections stay close to real-time with their sources.

On retrieval, Airweave can run semantic and BM25 keyword search in parallel, fuse results (RRF), apply recency bias, and re-rank. Agents can fetch ranked chunks with citations or ask for a synthesized answer. The same interface is exposed via REST, Python/TS SDKs, and MCP so agents can discover it like any other tool.

It’s been fun to see what users have built with Airweave; from legal AI assistants to research discovery agents and context augmentation for coding agents. We’re currently experimenting with agentic search patterns, layering different types of enrichment and indexing, RBAC on indexed data, and streaming architectures.

If this is interesting to you, feel free to take it for a spin. Curious to hear your thoughts and feedback on the problem and our solution!

30 comments

btown5mo ago

How do you compare to Onyx? We've used it for some limited use cases, but one of the real challenges - and one I hope to see a lot of innovation on in the space - was permissioning.

I see in another comment that you encourage each user to build their own dataset with their own permissions, but often this breaks for founders. If I have a Super Secret Personnel Planning Google Doc at a founder level, how can I be the one to set up the system for our company, but ensure that only files that I've explicitly shared with the company are ingested? What if a file needs to be made anyone-with-link-can-access for sharing with a strategic partner, but that shouldn't be indexed for the entire company?

Far too much of the world relies on the security-by-obscurity of public-but-unindexed links, and communications that might look public from a metadata perspective but were carefully designed for a very specific group of people who have verbal/mental context about confidentiality expectations. Being able to categorize by likely confidentiality, and allowing an administrator to partition access on a project and sub-project basis based on that, might be crucial for growth.

My recollection is that Onyx had limited support for some security use cases, but very rudimentary. Hoping you can solve this in a thoughtful way!

Onyx links for comparison:

https://www.onyx.app/

https://docs.onyx.app/developers/guides/chat_guide

https://docs.onyx.app/admin/connectors/official/

raufakdemir5mo ago

It’s a good point. It IS hard to map the various “off-market RBACs” onto a unified model and this is part of the reason we delay that - and instead handle it with per-user syncs that include the q=“sharedWithMe” parameters.

As for intelligently - but probabilistically - determining confidentiality (if I read that correctly), that does sound pretty interesting in scenarios where metadata is just simply insufficient. Also tricky. Sounds like you thought about these problems pretty deeply.