Airweave bündelt Kontext aus vielen Quellen hinter einer Suche mit Vespa und Temporal
Projektüberblick: Open-Source-Kontextabrufschicht für KI-Agenten. Open-Source-Kontextabrufschicht für KI-Agenten und RAG-Systeme.
Auf einen Blick
- Was ist das?
- Airweave ist eine selbst hostbare Abrufschicht für Agenten und RAG-Systeme, MIT-lizenziert und in Python gebaut. Das README beschreibt Stack und Startweg präzise, lässt aber Ranking, Lastverhalten und die Konnektorliste offen.
- Für wen ist es gedacht?
- Airweave passt zu Teams mit vielen Quellen und mehreren Agenten, die eine gemeinsame Suchschnittstelle wollen und bereit sind, Temporal und Vespa mitzubetreiben. Weniger passend ist es für einen einzelnen Agenten mit zwei Quellen und für Vorhaben ohne Docker-Erfahrung, weil ./start.sh eine verteilte Umgebung hochzieht.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Nein. Die Eigentümer haben das Repository auf GitHub archiviert; es ist schreibgeschützt und erhält keine Änderungen mehr.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Airweave als Abrufschicht zwischen Datenquellen und Agenten
Bei Agentenprojekten taucht die eigentliche Hürde meist als zweite auf: Nicht welches Modell antwortet, ist die Frage, sondern woher der Kontext kommt. Laut README verbindet Airweave Anwendungen, Werkzeuge und Datenbanken, synchronisiert deren Daten fortlaufend und stellt sie über eine einheitliche, auf Sprachmodelle zugeschnittene Suchschnittstelle bereit. Ein Agent stellt eine Anfrage und erhält Kontext aus mehreren Quellen in einem Durchgang.
Die Positionierung im README ist deutlich formuliert. Airweave versteht sich als gemeinsame Abrufinfrastruktur zwischen Datenquellen und KI-Systemen, die Authentifizierung, Aufnahme, Synchronisierung, Indizierung und Abruf übernimmt, statt diese Schritte pro Agent neu zu bauen.
Die Metadaten stützen diese Einordnung nur teilweise. Python ist als Hauptsprache angegeben, die Lizenz ist MIT, der Standardzweig heißt main. Zur Qualität der Implementierung sagen diese Angaben nichts, und aus der README gehen keine Messwerte hervor, an denen sich die Schicht bewerten ließe.
Vier Schritte von der Quelle bis client.collections.search.instant
Der Ablauf ist in vier Schritte gegliedert. Quellen werden angebunden, und das README spricht von mehr als 50 Integrationen. Airweave synchronisiert und indiziert anschließend und stellt die Daten über eine einheitliche Schicht bereit. Agenten greifen über SDKs, die REST-API, MCP oder native Integrationen mit gängigen Agenten-Frameworks zu. Am Ende steht der Abruf auf Anfrage.
Konkreter als diese Aufzählung wird das README an keiner Stelle. Welches Verfahren die Treffer ordnet, wie Inhalte in Abschnitte zerlegt werden und was auf Sprachmodelle zugeschnitten für das Suchverhalten bedeutet, bleibt offen; die README benennt die Schnittstelle, nicht ihre Interna. Wer wissen will, ob eine Query über Stripe-Daten und Confluence-Seiten hinweg sinnvoll gewichtet wird, muss das im Code oder unter docs.airweave.ai nachlesen.
Erwähnenswert ist die Nennung von MCP. Damit ist die Schicht nicht nur aus eigenem Code erreichbar, sondern auch aus Werkzeugen, die dieses Protokoll sprechen. Wie weit die MCP-Anbindung reicht, steht im README nicht.
./start.sh, .env.example und die acht Ports beim Selbsthosting
Der Weg zum laufenden System ist kurz beschrieben: git clone https://github.com/airweave-ai/airweave.git, danach cd airweave und ./start.sh. Das README nennt Docker und docker-compose als Voraussetzung. Anschließend ist die Anwendung unter http://localhost:8080 erreichbar.
Was das Skript im Einzelnen tut, steht in einem verlinkten Setup-Prompt im README. Es legt .env aus .env.example an, erzeugt die Geheimnisse ENCRYPTION_KEY und STATE_SECRET, startet alle Dienste mit Health Checks und fragt optional nach API-Schlüsseln für OpenAI oder Mistral. Der erste Start dauert eigenen Angaben zufolge zwei bis drei Minuten, bis alle Dienste als gesund gelten.
Für den Betrieb sind drei Flags dokumentiert: ./start.sh --restart startet neu, ./start.sh --skip-frontend beschränkt den Start auf das Backend, ./start.sh --destroy räumt alles ab. Ausgaben liefern docker logs airweave-backend und docker logs airweave-frontend. Das README listet außerdem die belegten Ports 8080, 8001, 5432, 6333, 6379, 7233, 8081 und 8088, und Konflikte dort gehören zu den häufigsten Startproblemen.
PostgreSQL für Metadaten, Vespa für Vektoren, Temporal für Orchestrierung
Der Stack ist breit und wird im README ausdrücklich benannt. Das Frontend besteht aus React und TypeScript mit ShadCN, das Backend aus FastAPI. Bei der Speicherung wird getrennt: PostgreSQL hält Metadaten, Vespa die Vektoren. Temporal übernimmt die Orchestrierung, Redis die Pub/Sub-Kommunikation. Für die Entwicklung ist Docker Compose vorgesehen, für den Produktionsbetrieb Kubernetes.
Diese Aufzählung erklärt einiges. Sie macht verständlich, warum der Start Minuten dauert und acht Ports belegt, und sie erklärt die Kehrseite. Temporal und Vespa sind Komponenten mit eigenem Betriebsaufwand und eigenen Upgrade-Zyklen. Wer Airweave für ein einzelnes Projekt mit zwei Quellen einsetzt, betreibt dafür eine verteilte Infrastruktur, deren Ausfallbilder man kennen muss.
nicht zu unterschätzen ist die Aufteilung der Datenhaltung. Metadaten in PostgreSQL und Vektoren in Vespa heißt, dass eine Sicherung beide Systeme umfassen muss und dass ein Wiederherstellen ohne Abgleich zwischen ihnen unvollständig bleibt. Das README äußert sich zu Backup-Verfahren nicht.
airweave-sdk, @airweave/sdk und die CLI mit airweave search
Zwei SDKs sind dokumentiert: pip install airweave-sdk für Python und npm install @airweave/sdk für TypeScript. Das Python-Beispiel im README ist knapp und zeigt die Form der API. Aus airweave wird AirweaveSDK importiert, der Client erhält einen API-Schlüssel, und der Aufruf geht an client.collections.search.instant. Übergeben werden eine readable_id und eine Query, im Beispiel die Suche nach fehlgeschlagenen Zahlungen.
Auffällig ist der Parameter readable_id. Sammlungen werden über einen lesbaren Bezeichner adressiert, was Konfigurationsdateien lesbar hält und dafür sorgt, dass Umbenennungen an einer SammlungAufrufe brechen können, die den alten Wert führen. Wie Airweave mit solchen Änderungen umgeht, steht im README nicht.
Für das Terminal existiert eine eigene CLI, installiert mit pip install airweave-cli. Dokumentiert sind airweave auth login sowie airweave search mit dem Parameter --collection. Die CLI soll im Terminal aufbereitete Ergebnisse zeigen und sauberes JSON ausgeben, wenn sie in eine Pipe schreibt. Ein TypeScript-Beispiel fehlt, dort steht nur das Installationskommando.
v0.9.73 vom 5. Juni 2026 und die Lücken im README
Zur Aktivität liefern die Metadaten mehr als viele andere Projekte. Als letzte Push-Zeit ist der 5. Juni 2026 verzeichnet, und die drei jüngsten Releases sind v0.9.73 vom 5. Juni 2026, v0.9.72 vom 2. Juni 2026 sowie v0.9.71 vom 21. Mai 2026. Die Nummern liegen unter 1.0, und der Abstand zwischen den beiden letzten Veröffentlichungen beträgt drei Tage, davor zwölf.
Was das README nicht liefert, ist aufschlussreicher als die Liste der Komponenten. Benchmarks fehlen, Angaben zu Durchsatz und Latenz fehlen, Aussagen zu Mehrbenutzerbetrieb und zur Verschlüsselung ruhender Daten fehlen, obwohl ENCRYPTION_KEY beim Start erzeugt wird. Für eine Komponente, die Zugangsdaten zu Salesforce, Slack oder Jira hält, ist das eine bemerkbare Lücke in der Dokumentation.
Auch die Integrationsliste ist im erfassten Text nur Ankündigung. Zwischen den Marken START_APP_GRID und END_APP_GRID stehen keine Einträge; die vollständige Übersicht liegt unter docs.airweave.ai/connectors/overview. Wer eine bestimmte Quelle braucht, muss dort nachsehen, statt sich auf die genannte Zahl zu verlassen.
app.airweave.ai gegen Selbsthosting und gegen eigene Pipelines pro Agent
Die erste Alternative liegt im eigenen Angebot: die gehostete Fassung unter app.airweave.ai. Der Unterschied zum Selbsthosting betrifft nicht die Funktion, sondern den Betrieb. Wer die Cloud nimmt, gibt Temporal, Vespa und die acht Ports ab und zahlt mit dem Abfluss der Daten in eine fremde Instanz sowie mit einer Abhängigkeit von deren Verfügbarkeit und deren Schlüsselverwaltung.
Die zweite Alternative ist der Verzicht auf eine gemeinsame Schicht, also genau der Weg, den das README als brüchig beschreibt: eine eigene Pipeline pro Agent. Das skaliert schlecht mit der Zahl der Quellen, weil jede Korrektur an der Aufbereitung in jedem Agenten nachgezogen werden muss. Es erlaubt aber, jede Quelle einzeln abzustimmen und den Vektorspeicher frei zu wählen.
Airweave legt diese Wahl fest. Vespa ist im Stack gesetzt, Temporal übernimmt die Orchestrierung, und wer die Schicht einmal eingeführt hat, hängt an diesen Entscheidungen. Das ist der Preis für den Gewinn, Kontext für mehrere Agenten nur einmal aufzubauen.
Redaktionelles Fazit
Airweave passt zu Teams mit vielen Quellen und mehreren Agenten, die eine gemeinsame Suchschnittstelle wollen und bereit sind, Temporal und Vespa mitzubetreiben. Weniger passend ist es für einen einzelnen Agenten mit zwei Quellen und für Vorhaben ohne Docker-Erfahrung, weil ./start.sh eine verteilte Umgebung hochzieht. Vor einer Entscheidung zu prüfen: ob die benötigten Konnektoren unter docs.airweave.ai/connectors/overview stehen, ob v0.9.73 im eigenen Betrieb stabil synchronisiert, und welche der acht belegten Ports in der eigenen Umgebung schon vergeben sind.
Community-Notizen