[HN Gopher] Launch HN: Airweave (YC X25) - Let agents search any...
___________________________________________________________________
Launch HN: Airweave (YC X25) - Let agents search any app
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!
Author : lennertjansen
Score : 127 points
Date : 2025-09-30 16:21 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| suprnurd wrote:
| 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 wrote:
| 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
| EGreg wrote:
| "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?
| ameyamk wrote:
| 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 wrote:
| 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.
| ripped_britches wrote:
| Cool deal. How is this different from Glean?
| raufakdemir wrote:
| 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
| andric wrote:
| Your pricing currently seems prohibitive for that kind of use
| case. Shouldn't it be usage-based so one can build a product
| where users can connect their apps without having to worry
| about arbitrary limits on plans? There should be a PAYG
| option that simply charges per connection, and automatic
| volume discounts.
| raufakdemir wrote:
| Definitely worth looking into.
| candiddevmike wrote:
| 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 wrote:
| 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 wrote:
| Hey Lennert, congrats on the launch! Still open to chat about
| uithub
| btown wrote:
| 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 wrote:
| 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.
| ashu1461 wrote:
| 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 wrote:
| Airweave always indexes everything. We do not do any direct
| tool calling currently.
| ori_b wrote:
| Can I have the application search without the LLM shit?
___________________________________________________________________
(page generated 2025-09-30 23:00 UTC)