raufakdemir

what language does this support? cypher/gremlin?

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.

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

Definitely worth looking into.

Great question. We do index the data!

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

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.

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

How can I migrate neo4j to this?

Yes, we create service accounts on the source platforms which can then be used to do an OAuth or key based integration. What would you like to do specifically?

So you would like to delete information for a specific user identifier? Currently that means resyncing excluding that user profile (which would have to be removed from the source system) but happy to hear more about this use case. Would a desired feature be a “delete by user email” for example?

This is exactly the reason we started building Airweave! The “context” in MCP is a bit deceiving, as it actually provides very little context.

Good questions.

1) the integrations are done traditionally so with REST/SQL. The MCP/REST search layer rests on the data that gets synced.

2) most providers are painless. Slack doesn’t want major exports in one go but most developers point at a single channel anyway so the rate limit errors don’t bite too much.

3) this is all orchestrated by the platform itself. Incremental syncs will receive the latest “watermark state” and sync from there. Hashes are used to compare data for persist actions (update/insert/keep)

Lol, good to know. Thanks

I assume you're talking about the data layer (not the control plane)? We are currently in PoC phase for mapping the role graphs from source systems (Asana, Google Drive) to our internal role model, but this is still in the works. The way developers work around this atm is by configuring a connection on a subset of the source info. Example: only make Airweave sync info from the `Shared Drive/Marketing/Branding` path

n8n is a good example of a tool that Airweave can enhance. n8n allows (no-code) developers to set up pre-determined automations but as soon as you want to process non-deterministic text into action on an app, you will still need a way to search the app. Example: you have a n8n workflow that gets you on track with Linear tickets. You hook it into a text-based human interface in which the user says: "I just created a task about database migration on Linear, can you start doing the preparations for it?". Airweave can 1. find that damn ticket, 2. give additional context on database migrations based on what else it finds in the integrated systems.