Launch HN: Airweave (YC X25) – Let agents search any app

[lennertjansen]

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!

[btown]

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/

[raufakdemir]

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.

[lennertjansen]

@btown: Biggest difference: Airweave is infra for devs, i.e., connectors, sync, indexing (semantic + keyword), and a retrieval API/MCP designed with LLMs in mind as the consumers. You bring the agent/UI. Onyx is an end-to-end search app that owns the agentic reasoning layers that orchestrates their search. You can think of Airweave as a dev tool that you would use if you were building an agentic application, where Onyx is a good example of one.

On permissioning: we default to per-user syncs that adopt the permissions of the syncing user and mirror source ACLs (e.g., Drive items a user owns or that are sharedWithMe). In practice, founders avoid leaking private docs by either (a) having each user sync their own corpus, or (b) using a centrally-scoped token limited to Shared Drives/team folders and excluding personal “My Drive.” You can also keep separate collections and only expose cross-user search behind your own checks. We’re exploring richer org-level RBAC mapping on a per-customer basis (e.g., mapping Drive/SharePoint groups to index ACLs), but the above works today.

@Weves: Thanks, appreciate it!

[Weves]

Don't mean to hijack (one of the Onyx founders here), but the example you described should be doable with Drive service accounts. Admittedly, our permissioning system is only implemented for a handful of connectors like Drive.

Congratulations on the launch Rauf & Lennert! Always great to have more innovation in the open source AI space :D. It looks like Airweave works well with Cursor, something we don't have nailed down yet!

[ashu1461]

Great release,

1. How do you decide whether to cache the data into a vector database or fetch it on runtime using a tool call ?

2. Slowly all players like Open AI / Claude are trying to provide a somewhat equivalent offering of connecting your workspaces and then providing search on top of it either via direct integrations / mcp servers, how do you see that spanning out ?

[raufakdemir]

Airweave always indexes everything. We do not do any direct tool calling currently.

[lennertjansen]

re 2.: I agree that there's a trend with OpenAI/Anthropic are adding Airweave-like connectors to ChatGPT and Claude Desktop. Imho this a good thing for us because it's showing the utility of our use case

[suprnurd]

Looks great! It's cool how you are able to unify multiple sources into a single searchable layer. I’m curious how you chose which connectors to support first (e.g. GitHub, Notion, Slack) and how you plan to scale connector coverage? Thanks!

[lennertjansen]

it's currently guided by community feedback, github issues, and user talks. and we rely on private e2e test suites for maintaining quality as we scale coverage

[ameyamk]

Looks good. Curious, how is auth handled? Lot of docs have permissions etc. Can you clarify how this is handled in both indexing side and searching side of things?

[raufakdemir]

Great question. We usually sync per user in cases where this matters. That seems inefficient until you realize the following: for most teams, workspace data is pretty small - at least compared to other data workloads (CRMs << 1gb).

We plan to implement unified ACL syncs to dedupe the data or even have 1 sync per org, but that’s mostly a cost optimization; Airweave will just scale horizontally until then.

[Blahah]

This is pretty cool and I could see myself recommending this to our team for some applications. Congrats on the launch!

A couple of bits of feedback:

1. Code samples on the site have broken whitespace on mobile (Android/Brave) so look a bit intense.

2. The pricing is complex to reason about - I have to consider the technical aspects and the number of users? Why don't I just get an API key?

[lennertjansen]

1. thanks for the feedback, testing it on a smartphone and changing that asap. 2. What about the pricing do you find complex? And what would make it easier to understand for you? Just want to add that you can just get an API key by using the free developer version or local instance (API-key is shown immediately in the top-right panel). You can also create more in your org settings

and ofc, feel free to reach out if your team needs help with setup

[candiddevmike]

Seems like Google Agentspace but without the UI. Do you folks keep a persistent copy of the data being ingested? How are you planning on solving RBAC? IMO, all of these "search anything" apps are going to be leaky by design unless you're indexing/gathering on the fly using passthrough credentials...

[raufakdemir]

Great question. We do index the data!

We usually sync per user. That way we make sure that no information leaks to another interface.

[janwilmake]

Hey Lennert, congrats on the launch! Still open to chat about uithub

[lennertjansen]

thanks Jan, lets definitely chat

[hommes-r]

Awesome to see the Cursor Airweave example!

[lennertjansen]

thanks!

[ripped_britches]

Cool deal. How is this different from Glean?

[raufakdemir]

Glean is enterprise search for humans. Airweave is built for agent developers that want to access their user’s (so the person using the agent product) information

[orliesaurus]

is this like RAG for cloud services that store my content?

[lennertjansen]

Yes thats an accurate description. I'd add the nuance that our retrieval is designed to give agents the right actionable context to perform work on users' workspaces, and not necessarily to synthesize a final answer for a human end-user. But ofc you can use it for that.

[ori_b]

Can I have the application search without the LLM shit?

[lennertjansen]

yes, you don’t have to use LLM operations during search. You can set the search-endpoint to just use BM25 keyword search.

[EGreg]

"Give us access to any information on your computer."

And who is "us"?

"Well, our agents, of course. We'll send the information down to our servers, because -- surprise -- we have the GPU infrastructure to run it, and you don't. Don't worry, it's secure."

"Alright, well--"

https://www.wiz.io/blog/38-terabytes-of-private-data-acciden...

"Oops! Well don't worry, it's not like we're the first ones to sell your usage data..."

https://ferrumit.com/resources/it-s-now-legal-for-isps-to-se...

"You see! Well, just send us your DNA we'll analyze it -- with science! I mean with AI..."

"Alright, here is--"

https://www.nytimes.com/2025/05/19/business/regeneron-pharma...

"Oops! Well don't worry, it's not like the company that bought us will do anything with your data, that we wouldn't have done."

Here's my question...

1) How much can we feasibly run on a consumer-grade GPU today, on-board the computer, either the latest macbook or latest mobile iphone? Does Apple Metal + Silicon ship with any models that are on board the latest iOS 26?

2) How can we extend the security boundary to GPU servers that are attested black boxes that store data encrypted at rest, guaranteed not to train on it and are not owned by some corporation that can peek at the data?