# Intro to Localmind Source: https://docs.localmind.ai/Intro-to-Localmind Der schnellste Weg zu deiner ersten Aufgabe in Localmind — plus Orientierung, wie alles zusammenhängt. Localmind ist die KI-Plattform deines Unternehmens: Du arbeitest mit KI-Agenten, befragst deine Dokumente und automatisierst Abläufe — alles an einem Ort. ## Womit willst du starten? | Du willst … | Start hier | | ---------------------------------------- | --------------------------------------------------------------------------- | | Mit einem KI-Agenten arbeiten | [Dein erster Agent](/quickstart/Dein-erster-Agent) | | Fragen zu deinen Dokumenten stellen | [Wissensquellen anbinden](/arbeiten-mit-ki/Wissensquellen) | | Dokumente analysieren oder vergleichen | [Analyse](/apps/Document-Analysis) · [Vergleich](/apps/Document-Comparison) | | Daten aus Dokumenten extrahieren | [Dokumentenextraktion](/apps/Document-Extraction) | | Meetings und Audiodateien transkribieren | [Transkription](/apps/transcription) | | Abläufe automatisieren | [Automate-Grundlagen](/automate/basics) | | Bessere Antworten bekommen | [Arbeiten mit KI](/arbeiten-mit-ki/einstieg) | Du richtest Localmind für dein Team ein? Der [Initial Admin Guide](/administration/Initial-Admin-Guide) führt dich durch Organisation, Mitglieder, Modelle und Sicherheit. ## So hängt alles zusammen Deine [Organisation](/navigation/Organisationen) bildet den Rahmen, gearbeitet wird in [Spaces](/navigation/Spaces) — jeder bündelt Agenten, Dokumente, Apps und Werkzeuge für ein Team oder Projekt. In die Plattform führen vier Wege: Chat, Apps, [Automate](/automate/overview) und die [API](/api-reference/introduction). Alle vier arbeiten auf denselben Daten — einmal angebunden, überall nutzbar. ## Die Doku im Überblick | Bereich | Inhalt | | ----------------------------------------------------- | ------------------------------------------------- | | [Plattform](/navigation/Organisationen) | Tägliche Arbeit: Spaces, Agenten, Dokumente, Apps | | [Automate](/automate/overview) | Workflows mit der integrierten n8n-Engine | | [Administration](/administration/Initial-Admin-Guide) | Einrichtung, Mitglieder, Rechte, Sicherheit | | [API](/api-reference/introduction) | OpenAI-kompatible Schnittstelle für Entwickler | | [Changelog](/changelog/overview) | Was sich mit jedem Release ändert | | [Troubleshooting](/troubleshooting/overview) | Lösungen für häufige Probleme | ## Wenn du nicht weiterkommst Die häufigsten Probleme samt Lösungen stehen im [Troubleshooting](/troubleshooting/overview). Für alles andere: [Stelle eine Support-Anfrage](https://get.support.localmind.ai/servicedesk/customer/portal/134/group/181/create/10285) — unser Team kümmert sich. # Custom Domains Source: https://docs.localmind.ai/administration/Custom-Domains Eigene Domains konfigurieren Diese Seite wird derzeit erarbeitet. Für aktuelle Informationen zu diesem Thema wenden Sie sich an den [Localmind Support](mailto:support@localmind.ai). # Einstieg Source: https://docs.localmind.ai/administration/Einstieg Library Management – Ressourcen erstellen, bearbeiten, freigeben und an Spaces verteilen. Das Library Management umfasst alle Verwaltungsfunktionen der [Bibliothek](/library/overview): Ressourcen erstellen und bearbeiten, Veröffentlichungsanfragen prüfen und die Verteilung an Spaces steuern. Der Zugriff auf Library Management erfordert **Library-Manager-Rechte** oder eine gleichwertige Administratorrolle. Reguläre Benutzer können die Bibliothek nur im Lesemodus nutzen. ## Rollen und Berechtigungen | Aktion | Berechtigung | | --------------------------------------- | ---------------------------------------------------------------------- | | Bibliothek durchsuchen und installieren | Alle Benutzer (sofern Space-Rolle und Installationsoption es erlauben) | | Ressourcen erstellen und bearbeiten | Library Manager / Admin | | Veröffentlichungsanfragen prüfen | Library Manager / Admin | | Verteilungseinstellungen konfigurieren | Library Manager / Admin | | Ressourcen löschen | Library Manager / Admin | ## Verwaltungsbereiche Bearbeitungsmaske für Agenten, Werkzeuge und Basismodelle – von Grundinformationen bis Verteilungseinstellungen. Veröffentlichungsanfragen aus Spaces prüfen, annehmen oder ablehnen. Tool-Server zentral in der Bibliothek anlegen und an Spaces verteilen. # Freigaben Source: https://docs.localmind.ai/administration/Freigaben Freigabeanfragen aus Spaces prüfen und den Proposal-Workflow verwalten. Wenn Benutzer Ressourcen aus ihrem Space zur [Bibliothek](/library/overview) vorschlagen, durchlaufen diese einen Freigabeprozess. Hier verwalten Library Manager alle eingehenden Anfragen. Erfordert **Library-Manager-Rechte** oder eine gleichwertige Administratorrolle. ## Veröffentlichungsanfragen reviewen **Navigation:** Bibliothek → (Zahnrad) **Bibliothekseinstellungen** → **Anfragen** Die Liste zeigt alle eingegangenen Anfragen: | Spalte | Beschreibung | | ------------------------ | -------------------------------------------- | | Ressourcenname + Version | Name und Version des vorgeschlagenen Agenten | | Status | Aktueller Status (z.B. „Ausstehend") | | Angefragt am | Zeitpunkt der Anfrage | | Aktion | **Review Now** – öffnet die Prüfansicht | Über das **Status-Filter-Dropdown** (z.B. „Ausstehend") können Sie die Liste eingrenzen. ## Vorschläge aus Spaces (Proposals) Benutzer können [Agenten](/core-functions/agents) aus ihrem Space zur Bibliothek vorschlagen. Der Ablauf: Ein Benutzer schlägt einen Agenten aus seinem Space zur Veröffentlichung vor. Die Anfrage wird unter **Bibliothekseinstellungen → Anfragen** sichtbar. Ein Library Manager prüft den Vorschlag und akzeptiert oder lehnt ihn ab. Bei Annahme wird der Agent in die Bibliothek aufgenommen und ist für alle Benutzer verfügbar. # Initial Admin Guide Source: https://docs.localmind.ai/administration/Initial-Admin-Guide Schritt-für-Schritt-Anleitung für die Ersteinrichtung Ihrer Localmind-Instanz – vom ersten Login bis zum ersten verteilten Agenten. Diese Anleitung führt Sie als frisch eingerichteten Administrator durch die wichtigsten Schritte, um Ihre Localmind-Instanz betriebsbereit zu machen. Am Ende haben Sie einen ersten Space erstellt, Mitglieder eingeladen, ein Basismodell zugewiesen und Ihren ersten Agenten firmenweit bereitgestellt. Sie erhalten Ihre initialen Login-Daten bei der Bereitstellung Ihrer Instanz. Ändern Sie Ihr Initialpasswort sofort nach dem ersten Login unter **Profilmenü → Passwort ändern**. Nach dem Login sehen Sie eine leere Instanz – noch ohne [Spaces](/navigation/Spaces), [Teams](/navigation/Teams) oder weitere Mitglieder. Localmind nach dem ersten Login ohne konfigurierte Spaces oder Teams Als erstes sollten Sie die Organisationseinstellungen anpassen. Klicken Sie auf das **Einstellungsrad unten links** in der Sidebar – dort finden Sie sowohl die Instanz-Einstellungen (organisationsübergreifend) als auch die [Org-Einstellungen](/settings/organization/Einstieg). Unter [Profil](/settings/organization/Profil) können Sie den Organisationsnamen, das Logo und die Beschreibung anpassen. **Multi-Org-Setup:** Der Organisationsname bestimmt den **Org-Identifier**, der beim Login verwendet wird. Beispiel: Org-Name `ACME GmbH` ergibt den Identifier `ACME-GmbH`. Verwenden Sie einen möglichst einfachen, kurzen Namen ohne Sonderzeichen. Als Instanz-Administrator können Sie über den **Org-Switcher** in der oberen linken Ecke zwischen Organisationen wechseln. Das ist relevant, wenn Ihre Instanz mehrere Organisationen verwaltet. Jedes eingeladene Mitglied erhält automatisch einen **Privaten Space** für persönliches Arbeiten. Wenn Sie bereits eine Space-Struktur für kollaboratives Arbeiten vorgesehen haben, empfiehlt es sich, jetzt einen ersten gemeinsamen Space anzulegen – z.B. „KI-Workshop". Wechseln Sie nun in die [Library](/library/overview). Hier weisen Sie KI-Ressourcen wie Basismodelle Ihren Spaces zu. Damit stellen Sie sicher, dass Mitglieder in ihren Spaces sofort mit einem Modell arbeiten können. Neue Mitglieder werden als **Org Member** angelegt und haben initial: * Zugriff auf ihren **Privaten Space** * **Leserechte** in der [Library](/library/overview) Sie können Mitglieder einem Space **direkt hinzufügen** oder über [Teams](/navigation/Teams) provisionieren. Teams können mehrere Spaces beinhalten und werden verwendet, um mehreren Usern in mehreren Spaces eine Space-Rolle zuzuweisen. Detaillierte Informationen zu Rollen und Berechtigungen finden Sie unter [Library Management](/administration/Einstieg) und [Teams](/navigation/Teams). Bevor Mitglieder einem Space oder Team zugewiesen werden können, müssen sie zur Organisation eingeladen werden. Damit Einladungslinks per E-Mail versendet werden, richten Sie zuerst einen **Postausgangsserver** unter [Org-Einstellungen → E-Mail](/settings/organization/E-Mail-SMTP) ein. Falls der E-Mail-Versand technisch nicht verfügbar ist, können Sie Einladungslinks auch **manuell kopieren und verteilen**. ## Zwischenfazit **Stand jetzt:** Sie haben Ihren ersten Space erstellt, Mitglieder eingeladen und ein Basismodell über die Library verteilt. Ihre Instanz ist einsatzbereit – im nächsten Schritt erstellen Sie Ihren ersten Agenten und stellen ihn firmenweit bereit. Wechseln Sie in Ihren Privaten Space oder den erstellten Space und navigieren Sie zu **Ressourcen → Agenten → Neuer Agent**. Erstellen Sie z.B. einen allgemeinen Assistenten mit Basiswissen und aktivierter Websuche. Zugewiesene [Werkzeuge](/core-functions/Werkzeuge) und [Daten](/core-functions/Einstieg) werden bei der Verteilung über die Library ebenfalls bereitgestellt. Eine ausführliche Schritt-für-Schritt-Anleitung für Ihren ersten Agenten finden Sie unter [Bauen Sie Ihren ersten Agent](/quickstart/Dein-erster-Agent). Details zu Agenten-Konfiguration, Tools und Datenquellen unter [Agenten](/core-functions/agents), [Werkzeuge](/core-functions/Werkzeuge) und [Daten](/core-functions/Einstieg). Wechseln Sie in die [Library](/library/overview) und stellen Sie den erstellten Agenten in allen Privaten Spaces bereit. Normale User können Ressourcen nicht direkt über die Library verteilen. Sie durchlaufen einen **Veröffentlichungsantrag**, der von einem Administrator mit den nötigen Rechten geprüft und angenommen werden muss. Details unter [Freigaben](/administration/Freigaben). # Langfuse anbinden Source: https://docs.localmind.ai/administration/Langfuse-Anbindung Native Langfuse-Integration für LLM-Tracing: Prompts, Tool-Aufrufe, Token und Kosten — Cloud oder self-hosted. Langfuse zeichnet auf, was das LLM tatsächlich getan hat: den gesendeten Prompt, die zurückgelieferte Antwort, aufgerufene Tools sowie Token-Verbrauch, Latenz und Kosten je Aufruf. Das funktioniert mit jedem Modell — Cloud wie self-hosted —, denn das Tracing passiert auf Localmind-Seite. Sie binden Langfuse über wenige Variablen in `backend/.env` an; als Ziel dient [Langfuse Cloud](https://cloud.langfuse.com) oder eine selbst betriebene Langfuse-Installation. Die Anbindung ist getrennt vom OpenTelemetry-Export für Infrastruktur-Monitoring (Grafana): Der sieht nur HTTP-, Datenbank- und Redis-Spans und nie Prompts oder Completions. Beide können parallel laufen. Die eingebauten Ansichten für Nutzung und Systemzustand sind unter [Observability](/administration/observability) beschrieben; was Sie in den Langfuse-Traces sehen und wie Sie sie filtern, unter [Langfuse-Traces auswerten](/administration/Langfuse-Traces-Auswerten). Langfuse-Tracing ist ein lizenzpflichtiges Feature — dieselbe Freischaltung wie der OTLP-Trace-Export. Ohne Freischaltung bleibt das Tracing **still** ausgeschaltet, auch wenn alles korrekt konfiguriert ist. Die Freischaltung ist Teil Ihrer [Lizenz](/settings/instance/Lizenz) — stimmen Sie sie mit Localmind ab. ## Voraussetzungen | Voraussetzung | Details | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Langfuse-Projekt mit API-Schlüsseln | Langfuse Cloud (`https://cloud.langfuse.com`) oder selbst betriebene Installation. Self-hosted-Server erst in Planung? Richtwerte unter [Dimensionierung](#dimensionierung-des-langfuse-servers-richtwerte) | | Zugriff auf den Localmind-Server | SSH, Zugriff auf das Installationsverzeichnis (`backend/.env`) | | Kurzes Wartungsfenster | Backend **und** Worker werden einmal neu gestartet | | Lizenz-Freischaltung | Siehe Hinweis oben — mit Localmind abstimmen | ## Einrichtung Legen Sie in Langfuse ein Projekt an (z. B. „Localmind Produktion"). Erstellen Sie in der Langfuse-Oberfläche unter **Project Settings → API Keys** ein Schlüsselpaar und notieren Sie beide Werte: Public Key (`pk-lf-…`) und Secret Key (`sk-lf-…`, wird nur einmal angezeigt). Alle Einstellungen liegen in `backend/.env` im Installationsverzeichnis Ihrer Instanz: | Variable | Pflicht | Default | Zweck | | ---------------------- | ------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `LANGFUSE_ENABLED` | ja | `false` | Master-Switch — ohne `true` passiert nichts | | `LANGFUSE_PUBLIC_KEY` | ja | — | Public Key des Projekts (`pk-lf-…`) | | `LANGFUSE_SECRET_KEY` | ja | — | Secret Key (`sk-lf-…`) — geheim halten | | `LANGFUSE_BASE_URL` | ja | `https://cloud.langfuse.com` | Ziel-URL — Default ist Langfuse Cloud (EU-Region); self-hosted: die eigene URL | | `LANGFUSE_HOST` | nein | — | Legacy-Name — auf denselben Wert wie `LANGFUSE_BASE_URL` setzen; bei Konflikt gewinnt `BASE_URL` | | `LANGFUSE_SAMPLE_RATE` | nein | `1.0` | Anteil aufgezeichneter Runs (`1.0` = alle, `0.1` = 10 %) | | `LANGFUSE_MASK_IO` | nein | `false` | `true` redigiert Prompts und Completions — siehe [Datenschutz und Trace-Volumen](#datenschutz-und-trace-volumen) | Ein typischer Block: ```ini backend/.env theme={null} LANGFUSE_ENABLED=true LANGFUSE_PUBLIC_KEY=pk-lf-xxxxxxxx LANGFUSE_SECRET_KEY=sk-lf-xxxxxxxx LANGFUSE_BASE_URL=https://cloud.langfuse.com LANGFUSE_HOST=https://cloud.langfuse.com LANGFUSE_SAMPLE_RATE=1.0 LANGFUSE_MASK_IO=false ``` ```bash theme={null} cd docker compose restart backend worker ``` Chat-Konversationen laufen im **Worker**-Prozess. Wenn Sie nur das Backend neu starten, erhalten Sie Traces für die Dokumenten-Analyse, aber keine Chat-Traces. Prüfen Sie nach dem Neustart das Backend-Log (`docker compose logs backend`) — genau eines dieser Events erscheint: | Log-Event | Bedeutung | | -------------------------------------- | ----------------------------------------------------------- | | `langfuse_initialized` | Tracing aktiv — loggt Base-URL, Environment und Sample-Rate | | `langfuse_disabled` | `LANGFUSE_ENABLED` steht nicht auf `true` | | `langfuse_enabled_without_credentials` | Schalter an, aber ein Schlüssel fehlt | | `langfuse_init_failed` | URL falsch, Host unerreichbar oder Konfiguration defekt | Senden Sie danach eine Chat-Nachricht und öffnen Sie in Langfuse **Tracing → Traces** — neue Traces erscheinen innerhalb weniger Sekunden. Das Tracing ist fail-safe: Ist Langfuse nicht erreichbar oder falsch konfiguriert, funktioniert Localmind normal weiter — es fehlen nur die Traces. ## Self-hosted Langfuse Betreiben Sie Langfuse selbst, muss `LANGFUSE_BASE_URL` aus den Backend- **und** Worker-Containern per HTTP/S erreichbar sein — Langfuse unterstützt kein gRPC. Sitzt Ihre Installation hinter einer internen Zertifizierungsstelle (CA), muss das Zertifikat in beiden Containern als vertrauenswürdig hinterlegt sein. Richtwerte für die Server-Größe finden Sie unter [Dimensionierung](#dimensionierung-des-langfuse-servers-richtwerte). ## Datenschutz und Trace-Volumen Mit `LANGFUSE_MASK_IO=true` ersetzt Localmind jeden Prompt und jede Completion durch ``. Struktur, Modell- und Tool-Namen, Token-Zahlen, Latenz und Kosten bleiben sichtbar — nur der Inhalt fehlt. Nutzen Sie diese Einstellung, wenn kein Prompt-Text die Instanz verlassen darf, Sie aber Performance- und Kosten-Transparenz behalten wollen. `LANGFUSE_SAMPLE_RATE` steuert das Volumen: `1.0` zeichnet jeden Run auf — sinnvoll für Qualitätssicherung und beim Eingrenzen eines gemeldeten Problems. Auf Produktivinstanzen mit hohem Aufkommen senken Sie den Wert, wenn Trace-Volumen oder Langfuse-Kosten zum Problem werden. Haben Sie die frühere OTLP-Anbindung eingerichtet (`OTEL_EXPORTER_OTLP_ENDPOINT` auf `…/api/public/otel`), stellen Sie auf die native Integration um: Setzen Sie die `LANGFUSE_*`-Variablen wie oben beschrieben — die `OTEL_`-Zeilen für Langfuse entfallen. ## Fehlerbehebung | Problem | Mögliche Ursache | Lösung | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | | Keine Traces | `LANGFUSE_ENABLED` nicht `true`, Schlüssel fehlen oder Dienste nicht neu gestartet | `backend/.env` prüfen, dann `docker compose restart backend worker` | | Analyse-Traces erscheinen, Chat-Traces nicht | Worker nicht neu gestartet — Chat läuft im Worker-Prozess | `docker compose restart worker` | | Alles konfiguriert, keine Fehler, trotzdem keine Traces | Lizenz umfasst das Feature nicht | Freischaltung mit Localmind abstimmen ([support@localmind.ai](mailto:support@localmind.ai)) | | `langfuse_init_failed` im Log | Base-URL falsch, Host aus den Containern nicht erreichbar oder Zertifikat nicht vertrauenswürdig | URL prüfen; Erreichbarkeit aus dem Container testen; bei interner CA das Zertifikat hinterlegen | | Traces ohne Prompts und Completions | `LANGFUSE_MASK_IO=true` | Gewollt bei aktivierter Maskierung — sonst Variable auf `false` setzen und neu starten | | Nur ein Teil der Runs erscheint | `LANGFUSE_SAMPLE_RATE` unter `1.0` | Für vollständige Aufzeichnung auf `1.0` setzen | | `provider`-Tag fehlt an Traces | Erwartet bei Modellen hinter einem Proxy-Alias | Kein Fehler — siehe [Tags und Attribution](/administration/Langfuse-Traces-Auswerten#tags-und-attribution) | ## Dimensionierung des Langfuse-Servers (Richtwerte) Ein selbst betriebenes Langfuse besteht aus vier Komponenten: | Komponente | Aufgabe | | ----------------- | --------------------------------- | | Postgres | Transaktionale Daten | | ClickHouse | Trace-Analytik | | Redis/Valkey | Queue/Cache | | S3-/Blob-Speicher | Rohdaten aller eingehenden Events | Im Standard-Docker-Setup laufen alle vier auf einer VM; der Blob-Speicher ist der größte Speichertreiber. Offizielle Anhaltspunkte: * Langfuse veröffentlicht bewusst keine festen Sizing-Zahlen (Stand Juli 2026). * Persistentes Volume ab 100 GB als Startwert. * Kubernetes-Produktivsetups: Ressourcen-Preset „large", 3 Replicas. * Postgres und ClickHouse zwingend in Zeitzone UTC. Die folgenden Werte sind eine Modellrechnung — nach etwa 4 Wochen Realbetrieb am tatsächlichen Verbrauch nachkalibrieren. ``` Traces/Monat ≈ aktive Nutzer × KI-Anfragen je Nutzer und Arbeitstag × 21 Speicher/Monat ≈ Traces/Monat × Ø-Trace-Größe × 2 (Rohdaten im Blob + Kopie in ClickHouse) ``` Beispiel: 1.000 aktive Nutzer × 10 KI-Anfragen je Arbeitstag ≈ 210.000 Traces/Monat. Bei Ø 100 KB je Trace (Prompt, Antwort, RAG-Kontext, Metadaten) ≈ 40 GB/Monat; bei 12 Monaten Aufbewahrung ≈ 500 GB — mit Reserve also eine 1-TB-Disk. | Aktive Nutzer | vCPU | RAM | SSD (12 Monate Retention) | Anmerkung | | ------------- | ---- | ----- | ------------------------- | -------------------------------------------------------- | | bis 250 | 4 | 16 GB | 250 GB | alles auf einer VM (Docker-Compose-Standard) | | bis 1.000 | 8 | 32 GB | 1 TB | alles auf einer VM; Disk-Monitoring einrichten | | bis 5.000 | 16 | 64 GB | 2–4 TB | ClickHouse ggf. eigener Node; Blob auf externes S3/MinIO | Multimodale Inhalte (Bilder/Audio) erhöhen die Ø-Trace-Größe deutlich — wählen Sie dann die nächsthöhere Stufe. Retention konfigurieren statt unbegrenzt sammeln — die Aufbewahrungsdauer ist der größte Hebel für den Speicherbedarf. # Langfuse-Traces auswerten Source: https://docs.localmind.ai/administration/Langfuse-Traces-Auswerten Trace-Namen, chat-turn-Diagnose, Sessions und Tags: wie Sie Langfuse-Traces lesen und filtern. Wenn Sie nachvollziehen wollen, warum ein Agent geantwortet hat, wie er geantwortet hat, wo die Latenz einer Anfrage herkommt oder was ein einzelner Run gekostet hat, finden Sie die Antwort in den Langfuse-Traces. Diese Seite zeigt, wie Sie die Traces lesen und filtern — Voraussetzung ist eine eingerichtete Anbindung, siehe [Langfuse anbinden](/administration/Langfuse-Anbindung). Die eingebauten Ansichten zu Nutzung und Systemzustand (Analytik, Audit-Logs, System-Info) sind davon unabhängig und unter [Observability](/administration/observability) beschrieben. ## Was getraced wird Bei **Agents** (Chat) erfasst Langfuse den kompletten Agent-Run: jeden Modell-Aufruf, jeden Tool-Aufruf und delegierte Sub-Agents — verschachtelt in der Reihenfolge, in der sie ausgeführt wurden. Auch die **Apps**, die das Modell direkt und ohne Agent aufrufen, werden getraced: Dokumenten-Analyse, Dokumenten-Vergleich, Dokumenten-Extraktion, Transkription, die Prompt-Verbesserung und Guardrail-Prüfungen von Widget-Konversationen. ## Trace-Namen-Referenz Der Trace-Name sagt Ihnen, welcher Teil des Produkts einen Trace erzeugt hat — er ist Ihr primärer Filter in der Trace-Liste (**Tracing → Traces**). | Trace-Name | Quelle | | --------------------------- | --------------------------------------------------------- | | `chat-turn` | Eine User-Nachricht in einer Konversation | | `chat-resume` | Fortsetzung nach einer Tool-Freigabe oder einem Interrupt | | `agent-execution` | Ein direkt über die API aufgerufener Agent | | `openai-completion` | OpenAI-kompatible API, ohne Streaming | | `openai-completion-stream` | OpenAI-kompatible API, mit Streaming | | `analysis.llm_call` | Dokumenten-Analyse | | `comparison.llm_call` | Dokumenten-Vergleich | | `extraction.llm_completion` | Dokumenten-Extraktion | | `transcription_processing` | Transkription | | `improve_prompt` | Prompt-Verbesserung | | `widget_guardrail_check` | Guardrail-Prüfung einer Widget-Konversation | ## `chat-turn` lesen — das wichtigste Debug-Objekt Wenn Sie Agent-Verhalten debuggen, beginnen Sie beim `chat-turn`. Ein `chat-turn` entspricht einer User-Nachricht plus allem, was das System getan hat, um sie zu beantworten. Öffnen Sie den Trace, zeigt die Timeline die gesamte Kette von oben nach unten: ```text theme={null} chat-turn ← die gesamte Runde ├─ Modell-Aufruf ← das Modell entscheidet, was zu tun ist │ Input: System-Prompt + Verlauf + User-Nachricht │ Output: „Tool mit Parameter X aufrufen" │ Token, Latenz, Kosten ├─ Tool-Aufruf ← das Tool läuft, mit Input und Output ├─ Modell-Aufruf ← das Modell liest das Tool-Ergebnis ├─ Sub-Agent ← delegierte Arbeit, verschachtelt │ └─ eigene Modell- und Tool-Aufrufe └─ Modell-Aufruf ← die finale Antwort an den User ``` Damit beantworten Sie die vier Fragen, die in der Praxis am häufigsten auftauchen: * **Warum hat der Agent das gesagt?** Der Input des letzten Modell-Aufrufs zeigt den exakten System-Prompt und Verlauf, mit dem das Modell gearbeitet hat. * **Warum hat er das Tool nicht benutzt?** Der Tool-Span fehlt dann schlicht — und der Modell-Aufruf davor zeigt, was das Modell stattdessen entschieden hat. * **Warum war die Antwort langsam?** Jeder Span hat seine eigene Dauer; der langsame sticht heraus. * **Warum war der Run teuer?** Token-Zahlen stehen an jedem Aufruf und sind auf dem Trace summiert. Einzelne Modell-Aufrufe isoliert betrachtet reichen selten — die Kette innerhalb des `chat-turn` ist die Diagnose. ## Sessions — zusammengehörige Traces Sessions bündeln mehrere Traces, die zusammengehören. Statt Traces einzeln anzuklicken, öffnen Sie eine Session und sehen den gesamten Ablauf in Reihenfolge. * **Chat:** Die Session-ID ist die Conversation-ID. Jede Runde derselben Konversation landet in einer Session — Sie spielen die ganze Konversation nach, so wie sie stattgefunden hat. * **Dokumenten-Analyse und -Vergleich:** Die Session-ID ist die Job-ID. Diese Apps rufen das Modell einmal pro Frage und Seite auf — ein 50-Seiten-Job wäre sonst hunderte lose Traces in der Liste; als Session ist er ein einziges Objekt. Die übrigen Operationen sind One-Shot und setzen keine Session — ihre Traces stehen für sich. ## Tags und Attribution Jeder Trace ist getaggt, damit Sie die Liste eingrenzen können: | Trace-Typ | Tags | | ---------------------- | ---------------------------------------------------------- | | Agent-Runs | `org`, `space`, `agent`, `agent_type`, `model`, `provider` | | App- und Direktaufrufe | `operation`, `model`, `org`, `space` | Tags, deren Wert nicht auflösbar ist, werden weggelassen statt als `None` geschrieben. Ein fehlender `provider`-Tag bei self-hosted-Modellen hinter einem Proxy-Alias ist deshalb erwartet — kein Fehler. Zusätzlich trägt jeder Trace drei Attributionsfelder: * **User** — wer den Run ausgelöst hat. Widget-Konversationen sind by design anonym und tragen keinen User. * **Environment** — trennt z. B. dev und prod im selben Langfuse-Projekt. * **Release** — die Localmind-Version, mit der Sie Verhalten über Versionen hinweg vergleichen. Ist die [Maskierung](/administration/Langfuse-Anbindung#datenschutz-und-trace-volumen) aktiv, sehen Sie Prompts und Completions als redigierte Platzhalter — Struktur, Token-Zahlen und Kosten bleiben vollständig erhalten. # Nutzungsübersicht Source: https://docs.localmind.ai/administration/Nutzungsübersicht Ressourcenverbrauch und Kosten aller Spaces in Echtzeit überwachen, Nutzungsberichte exportieren und Preismodelle festlegen. Die Nutzungsübersicht zeigt Ihnen in Echtzeit, welche Ressourcen die Spaces Ihrer Organisation verbrauchen und welche Kosten dabei entstehen. Sie sehen den Verbrauch über alle Spaces hinweg an einer Stelle — als Grundlage für Kostenkontrolle und die interne Verrechnung innerhalb Ihrer Organisation. Das Einsehen der Nutzungsübersicht erfordert die Rolle **Org Admin** oder eine Billing-Berechtigung. Der Export von Nutzungsberichten erfordert die Billing-Aktion *Exportieren*, die Preiskonfiguration die Sub-Permission **Billing.Pricing**. Wie Sie diese Berechtigungen vergeben, beschreiben die [Rollenvorlagen](/settings/instance/Role-Templates). ## Kostenaufschlüsselung nach Dienst Die Kosten werden nach Dienst aufgeschlüsselt: Sie erkennen, welcher Anteil des Gesamtverbrauchs auf welchen Dienst entfällt, statt nur eine Summe zu sehen. Da die Werte in Echtzeit vorliegen, bemerken Sie ungewöhnliche Verbrauchsspitzen, während sie entstehen — nicht erst am Monatsende. ## Nutzungsberichte exportieren Für Auswertungen außerhalb von Localmind exportieren Sie Nutzungsberichte — etwa zur Weitergabe an das Controlling oder als Beleg für die interne Leistungsverrechnung. Der Export ist über die Billing-Aktion *Exportieren* separat berechtigt, sodass Sie Lesezugriff und Berichtsweitergabe getrennt vergeben können. ## Preismodelle, Tarife und Währungen Administratoren legen fest, mit welchen Preismodellen, Tarifen und Währungen der Verbrauch bewertet wird. Diese Konfiguration bestimmt, wie die Nutzungsübersicht Verbrauch in Kosten übersetzt — sie dient der org-internen Kostenverrechnung, etwa wenn Sie Kosten auf Abteilungen oder Kostenstellen umlegen. Die Preiskonfiguration ist über die Sub-Permission **Billing.Pricing** geschützt und sollte restriktiv vergeben werden: Wer Tarife ändert, verändert die Kostenbewertung für die gesamte Organisation. ## Abgrenzung zur Analytik Die [Analytik](/administration/observability) beantwortet die Frage, *wie* Ihre Organisation Localmind nutzt — Aktivitäten, Konversationen und Feedback. Die Nutzungsübersicht beantwortet, *was* diese Nutzung kostet: Verbrauch und Kosten in Echtzeit plus die Konfiguration der Preismodelle. Beide Ansichten ergänzen sich — für Kapazitätsfragen starten Sie in der Analytik, für Kostenfragen in der Nutzungsübersicht. Die Nutzungsübersicht wurde mit [Localmind 1.0.0](/changelog/v1.0.0) eingeführt. # Ressourcen bearbeiten Source: https://docs.localmind.ai/administration/Ressourcen-Bearbeiten Bearbeitungsmaske für Bibliotheksressourcen – Avatar, Grundinformationen, Sichtbarkeit, Verteilung und mehr. Die Bearbeitungsmaske ist für alle Ressourcentypen (Agenten, Werkzeuge, Basismodelle) einheitlich aufgebaut. Sie erreichen sie über die Detailansicht einer Ressource. Erfordert **Library-Manager-Rechte** oder eine gleichwertige Administratorrolle. ## Kopfbereich Oben in der Maske sehen Sie den **Ressourcennamen** und den **Ressourcentyp** (z.B. „Basismodell" oder „Agent"). ## Item Avatar Laden Sie ein quadratisches Bild als Avatar für die Ressource hoch. | Feld | Beschreibung | Hinweis | | ------ | ------------------ | -------------------- | | Avatar | Quadratisches Bild | 256–400 px empfohlen | ## Grundinformationen | Feld | Beschreibung | Pflicht | | ---------------------- | --------------------------------------------------------------------- | ------- | | Anzeigename | Name der Ressource, wie er im Katalog erscheint | Ja | | Version | Versionsnummer der Ressource | Nein | | Beschreibung | Kurzbeschreibung für Benutzer im Katalog | Nein | | Installationsanleitung | Freitext-Anleitung, die Benutzern bei der Installation angezeigt wird | Nein | ## Links Über **Link hinzufügen** können Sie externe Verweise ergänzen – z.B. zu Dokumentation, Demos oder weiterführenden Informationen. ## Bilder Ein Upload-Bereich für zusätzliche Bilder der Ressource (z.B. Screenshots oder Diagramme). ## Änderungsprotokoll Über **Eintrag hinzufügen** dokumentieren Sie Änderungen an der Ressource. Das Protokoll ist für Benutzer sichtbar und hilft bei der Nachvollziehbarkeit von Updates. ## Tags Fügen Sie Tags hinzu, um die Ressource kategorisierbar und über den Tag-Filter in der Bibliothek auffindbar zu machen. ## Sichtbarkeit Der Toggle **Sichtbarkeit** steuert, ob die Ressource im Bibliothekskatalog für Benutzer angezeigt wird. Ausgeblendete Ressourcen sind als „Versteckt" markiert und erscheinen nicht in der Standardansicht. ## Installationsoptionen | Option | Beschreibung | | -------------------- | ---------------------------------------------------------------------- | | Verknüpfung erlauben | Benutzer können die Ressource als Verknüpfung in ihrem Space einbinden | | Duplizieren erlauben | Benutzer können eine Kopie der Ressource in ihrem Space erstellen | Diese Optionen steuern, welche Installationsarten Benutzern in Spaces zur Verfügung stehen. Die beiden Arten unterscheiden sich grundlegend: * **Verknüpfung** — der Ziel-Space erhält eine **schreibgeschützte Referenz** auf die Original-Ressource. Änderungen am Original wirken sich automatisch auf alle Verknüpfungen aus; bearbeiten lässt sich die Ressource nur im Quell-Space. * **Duplikat** — der Ziel-Space erhält eine **einmalige, unabhängige Kopie** ohne Verbindung zum Original. Sie ist dort frei bearbeitbar (entsprechende Space-Rechte vorausgesetzt); spätere Änderungen am Original erreichen das Duplikat nicht. Neben der hier freigegebenen Installationsart benötigt der Benutzer die passende Rolle im Ziel-Space – beides muss erfüllt sein. Details zur Nutzerperspektive finden Sie in der [Library-Übersicht](/library/overview). ## Verteilungseinstellungen Legen Sie fest, an welche Spaces die Ressource automatisch verteilt wird: | Bereich | Optionen | Beschreibung | | ------------------ | ---------------------- | ----------------------------------------------------------- | | Öffentliche Spaces | Alle / Auswahl / Keine | Steuert die automatische Verteilung an kollaborative Spaces | | Private Spaces | Alle / Auswahl / Keine | Steuert die automatische Verteilung an Private Spaces | Bei **Auswahl** können Sie gezielt einzelne Spaces bestimmen. Verteilungseinstellungen greifen nur für **neu erstellte** Spaces – auf bereits bestehende Spaces wirken sie **nicht rückwirkend**. Dort verteilen Sie die Ressource manuell über **Zu Spaces hinzufügen** (als Verknüpfung oder Kopie). Bei **Basismodellen** ist das der org-weite Weg der Modellbereitstellung: Erst nachdem ein Modell einem Space zugewiesen wurde, erscheint es dort im Modell-Dropdown von Agenten und Apps – siehe [Modellauswahl](/arbeiten-mit-ki/modellauswahl). ## Gefahrenbereich Über **Ressource löschen** entfernen Sie die Ressource dauerhaft aus der Bibliothek. Prüfen Sie vor dem Löschen, ob die Ressource noch in Spaces verwendet wird. Bereits erstellte **Duplikate** in Spaces bleiben vom Löschen unberührt – sie sind unabhängige Kopien ohne Verbindung zum Original. # VPN Source: https://docs.localmind.ai/administration/VPN VPN-Konfiguration und Verwaltung Diese Seite wird derzeit erarbeitet. Für aktuelle Informationen zu diesem Thema wenden Sie sich an den [Localmind Support](mailto:support@localmind.ai). # Werkzeuge in der Library Source: https://docs.localmind.ai/administration/Werkzeuge Tool-Server zentral in der Bibliothek anlegen und an Spaces verteilen. Werkzeuge können analog zu Agenten zentral in der Bibliothek angelegt und an Spaces verteilt werden. So stellen Sie sicher, dass alle Spaces auf einheitlich konfigurierte Tool-Server zugreifen. Erfordert **Library-Manager-Rechte** oder eine gleichwertige Administratorrolle. ## Funktionsweise Die Konfiguration eines Tool-Servers (MCP) in der Bibliothek entspricht dem Ablauf auf Space-Ebene: Sie vergeben einen Namen, wählen einen der sechs Verbindungstypen (Remote-HTTP, NPX-Paket, Python-Paket, HTTP API, OpenAPI, Skill), hinterlegen die Konfiguration und prüfen sie über den Verbindungstest. Der Unterschied: Ein in der Bibliothek angelegtes Werkzeug kann über die [Verteilungseinstellungen](/administration/Ressourcen-Bearbeiten#verteilungseinstellungen) automatisch an ausgewählte Spaces verteilt werden. Details zu Verbindungstypen und Einrichtung eines Tool-Servers finden Sie unter [Werkzeuge](/core-functions/Werkzeuge). Für vorgebaute Integrationen (Jira, Confluence, Notion, SharePoint, Outlook, Microsoft Teams) verwenden Sie nicht die hier beschriebenen Tool-Server, sondern die jeweiligen Konnektor-Setup-Seiten unter **Administration → Integrationen** – zum Beispiel [Jira](/integrations/Jira) oder [Outlook](/integrations/Outlook). Diese OAuth-basierten Konnektoren sind getrennt von selbst konfigurierten Tool-Servern (MCP). ## Code-Sandbox konfigurieren Werkzeuge vom Verbindungstyp **Skill** führen Code in einer isolierten **Code-Sandbox** aus. Seit [v1.2.0](/changelog/v1.2.0) wird die Code-Ausführung automatisch aktiviert, sobald ein Agent Skills verwendet – Sie müssen sie nicht mehr als separates Werkzeug konfigurieren. Die Sandbox konfigurieren Sie zentral unter **Org-Einstellungen → KI-Konfiguration → Code-Sandbox**. Die Code-Sandbox-Einstellungen erfordern die Rolle **Org Admin**. Sie gelten org-weit für alle Spaces – eine abweichende Konfiguration auf Space-Ebene gibt es nicht. Die Instanz-Einstellungen definieren die Obergrenzen; Org-Werte können diese nur unterschreiten. ### Verknüpfte Zugangsdaten Hier steuern Sie, welche [Zugangsdaten](/settings/organization/Zugangsdaten) innerhalb der Sandbox verfügbar sind: * Nur **Organisations-Zugangsdaten**, die Sie hier explizit verknüpfen (anhaken), werden der Sandbox als **Umgebungsvariablen** bereitgestellt. * **Space-Zugangsdaten** werden nicht in die Sandbox injiziert. * Änderungen wirken nur für **neu gestartete** Sandboxen – bereits laufende Sandboxen behalten ihre Umgebung. Verknüpfen Sie nur die Zugangsdaten, die Ihre Skills tatsächlich benötigen. Jede verknüpfte Anmeldeinformation ist für sämtlichen Code sichtbar, der in der Sandbox ausgeführt wird. ### Ressourcen-Grenzen Zusätzlich begrenzen Sie hier, wie viele Ressourcen eine einzelne Sandbox-Ausführung beanspruchen darf. Passen Sie die Grenzen nur an, wenn Skills reproduzierbar an Ressourcen-Grenzen scheitern. Wie Sie einen Skill anlegen und welche Dateien in die Sandbox gehören, beschreibt die Plattform-Seite [Werkzeuge](/core-functions/Werkzeuge). # Automate und API-Zugriff Source: https://docs.localmind.ai/administration/api Wie Sie Automate-Workflows verwalten und programmatisch mit Localmind verbinden — und wann eine dedizierte Management-API folgt. Automate-Workflows verwalten Sie vollständig über die Web-App: Im Bereich **Automatisierung** Ihres Space erstellen, aktivieren und überwachen Sie Workflows und deren Executions. Den Einstieg finden Sie in der [Automate-Übersicht](/automate/overview). ## Workflows programmatisch mit Localmind verbinden Für die programmatische Anbindung Ihrer Workflows an Localmind — etwa um aus einem Workflow heraus Agenten aufzurufen oder Dokumente zu verarbeiten — nutzen Sie die verifizierte Localmind-API: Rufen Sie Localmind-Agenten direkt aus Ihren Automate-Workflows auf. Authentifizierung, Endpoints und Code-Beispiele der Localmind-API. ## Management-API für Automate Eine dedizierte Management-API für Automate — also das programmatische Verwalten von Workflows und Executions — dokumentieren wir, sobald die Schnittstelle final verifiziert ist. Sie benötigen schon heute programmatischen Zugriff auf Ihre Automate-Workflows? Wenden Sie sich an den [Localmind Support](mailto:support@localmind.ai) — wir beraten Sie zu Ihrem Anwendungsfall. # Observability Source: https://docs.localmind.ai/administration/observability Nutzung und Systemzustand im Blick behalten — eingebaute Ansichten, OpenTelemetry-Export und Langfuse-LLM-Tracing. Localmind bringt drei eingebaute Ansichten mit, über die Sie Nutzung und Zustand Ihrer Umgebung nachvollziehen: die **Analytik** auf Organisationsebene, die **Audit-Logs** als Aktivitätsprotokoll und die **System-Info** auf Instanzebene. Beim Managed Hosting übernimmt Localmind zusätzlich die laufende technische Überwachung Ihrer Instanz. Trace-Daten können Sie darüber hinaus per OpenTelemetry an ein eigenes Monitoring exportieren; LLM-Tracing — Prompts, Tool-Aufrufe, Token und Kosten — liefert die native Langfuse-Integration. Die Ansichten liegen auf unterschiedlichen Ebenen: **Analytik** und die **Org-Ansicht der Audit-Logs** erfordern entsprechende Org-Berechtigungen (z.B. **Org Admin** oder **Auditor**). Das **instanzweite Gesamtprotokoll der Audit-Logs** und die **System-Info** erfordern **Instanz-Administrator**-Rechte. Details zum Rollenmodell finden Sie unter [Rollenvorlagen](/settings/instance/Role-Templates). ## Wo Sie welche Signale finden | Frage | Ansicht | Ebene | Pfad | | ----------------------- | ------------------------ | ------------ | -------------------------------------- | | Wie viel wird genutzt? | Analytik | Organisation | **Org-Einstellungen → Analytik** | | Wer hat wann was getan? | Audit-Logs (Org-Ansicht) | Organisation | **Org-Einstellungen → Sicherheit** | | Wie geht es dem System? | System-Info | Instanz | **Instanz-Einstellungen → Systeminfo** | ## Analytik Die Analytik erreichen Sie über **Org-Einstellungen → Analytik**. Sie beantwortet die Frage, *wie* Ihre Organisation Localmind nutzt: Verbrauch von Credits und Token in Ihrer Organisation — die Grundlage für Kapazitätsplanung und Kostenkontrolle. Chronologische Übersicht der Aktivitäten in Ihrer Organisation — nützlich, um Nutzungsspitzen zeitlich einzuordnen. Auswertung der geführten Konversationen inklusive des Feedbacks, das Benutzer zu Agent-Antworten geben. Vollständige Gesprächsverläufe von Konversationen, die mit Admins geteilt wurden, öffnen und exportieren Sie ebenfalls hier — seit [v1.2.0](/changelog/v1.2.0) einschließlich Chats aus dem Website-Widget, die zuvor nicht einsehbar waren. Für die Kostenperspektive in Echtzeit — Kostenaufschlüsselung nach Dienst, exportierbare Nutzungsberichte und die Konfiguration von Preismodellen — nutzen Sie die [Nutzungsübersicht](/administration/Nutzungsübersicht). Die Analytik zeigt, *wie* Ihre Organisation Localmind nutzt; die Nutzungsübersicht, *was* diese Nutzung kostet. Prüfen Sie die Analytik regelmäßig, bevor Sie Limits anpassen — so erkennen Sie, ob einzelne Spaces oder Agenten überproportional Credits verbrauchen. ## Audit-Logs Für die lückenlose Nachvollziehbarkeit einzelner Aktionen — wer hat wann was geändert — nutzen Sie die Audit-Logs im Sicherheitsbereich Ihrer Organisation. Sie bieten Filter nach Zeitraum, Benutzer, Aktionstyp und Ressource sowie einen CSV-Export für externe Auswertungen und Archivierung. Im Unterschied zur Analytik aggregieren Audit-Logs nicht, sondern protokollieren **einzelne Ereignisse** — sie sind das Werkzeug für Compliance-Prüfungen und Sicherheitsanalysen. Instanz-Administratoren sehen zusätzlich das **instanzweite Gesamtprotokoll** über alle Organisationen in den Instanz-Einstellungen. Alle Funktionen, die Aufbewahrungsdauer und Datenschutz-Hinweise finden Sie unter [Audit Logs](/settings/instance/Audit-Logs). ## System-Info Den technischen Zustand der Instanz — **CPU, RAM, Festplattenspeicher und Netzwerk** — zeigt die System-Info in den Instanz-Einstellungen. Sie ist rein diagnostisch: Hier werden keine Einstellungen verändert, aber Sie erkennen auf einen Blick, ob Ressourcenengpässe die Ursache für langsame Antwortzeiten sind, und haben belastbare Werte für Gespräche mit dem Support-Team. Details zu den einzelnen Metriken finden Sie unter [Systeminfo](/settings/instance/systeminfo). ## Trace-Export an eigenes Monitoring (OpenTelemetry) Über die eingebauten Ansichten hinaus exportiert die Plattform Trace-Daten — die Aufrufketten des Backends — über den offenen Standard OpenTelemetry (OTLP) an ein eigenes Monitoring. Der Export ist eingebaut; Sie müssen nichts nachinstallieren. Das Zielszenario ist Infrastruktur-Monitoring mit Grafana/Tempo/Loki: Der Export liefert HTTP-, Datenbank- und Redis-Spans und zeigt damit, wo im Backend Zeit verloren geht. Die Einrichtung beschreibt die On-Premise-Deployment-Checkliste, die On-Premise-Kunden mit den Installationsunterlagen erhalten. ## LLM-Tracing mit Langfuse Was das Modell tatsächlich getan hat — Prompts, Completions, Tool-Aufrufe, Token und Kosten — sieht der OTel-Export nie. Diese Ebene liefert die native Langfuse-Integration, die unabhängig vom OTLP-Export läuft; beide können parallel aktiv sein. Die Einrichtung finden Sie unter [Langfuse anbinden](/administration/Langfuse-Anbindung), das Lesen und Filtern der Traces unter [Langfuse-Traces auswerten](/administration/Langfuse-Traces-Auswerten). ## Observability als Managed-Hosting-Leistung Betreibt Localmind Ihre Instanz im Managed Hosting, ist die technische Überwachung des Betriebs Teil der Hosting-Leistung: Das Localmind-Team beobachtet Verfügbarkeit und Ressourcenauslastung Ihrer Instanz und kümmert sich um den laufenden Betrieb — Sie müssen keine eigene Monitoring-Infrastruktur aufbauen. Bei Fragen zu den Betriebsmodellen hilft Ihnen der Support weiter — die Übersichtsseite [Hosting Options](/pricing/Hosting-Options) wird derzeit erarbeitet. Unabhängig vom Betriebsmodell bleiben die drei eingebauten Ansichten (Analytik, Audit-Logs, System-Info) Ihre primären Diagnose-Werkzeuge im Alltag. # Settings Source: https://docs.localmind.ai/administration/settings Automate-Einstellungen im Überblick: Workflow-Settings, Umgebungsvariablen, Credentials sowie Execution-, Timeout- und Retry-Verhalten. Hier finden Sie die Konfigurationsbereiche von Automate: Einstellungen pro Workflow, Umgebungsvariablen für wiederverwendbare Konfigurationswerte, Credentials für Zugangsdaten externer Dienste sowie das Execution-Verhalten (Timeout und Retry). Workflow-Einstellungen bearbeiten Sie direkt in der App **Automatisierung** des jeweiligen Space — dafür benötigen Sie Bearbeitungsrechte in diesem Space. Org-weite [Zugangsdaten](/settings/organization/Zugangsdaten) für andere Localmind-Apps verwaltet dagegen ein **Org Admin** in den Org-Einstellungen. ## Workflow-Settings Jeder Workflow hat eigene Einstellungen, die Sie in der Workflow-Ansicht über die **Workflow-Einstellungen** erreichen. Änderungen an einem Workflow werden automatisch versioniert: Frühere Versionen sehen Sie im **Versions**-Tab ein und stellen sie bei Bedarf wieder her. Details: [Versionierung](/automate/versioning). Trennen Sie Konfiguration von Logik: Werte, die sich zwischen Umgebungen unterscheiden (Schlüssel, Schwellwerte, Log-Level), gehören in Umgebungsvariablen oder Credentials — nicht fest verdrahtet in einzelne Nodes. ## Umgebungsvariablen Umgebungsvariablen halten Konfigurationswerte zentral und außerhalb des Workflow-Codes — z.B. `MAX_RETRIES=3` oder `WEBHOOK_SECRET=`. In Nodes greifen Sie per Expression auf die Werte zu: `{{ $env.VARIABLE_NAME }}`. Umgebungsvariablen werden auf **Betreiber-Ebene** gepflegt (Instanz-Konfiguration), nicht in der Workflow-UI. Benötigen Sie neue Variablen, wenden Sie sich an Ihren Instanz-Betreiber bzw. den Support. Zugangsdaten externer Dienste gehören dagegen in den [Credential Store](#credentials-und-zugangsdaten). Beispiel für die Verwendung in einer HTTP Request Node: ```json Authorization-Header aus Umgebungsvariable theme={null} { "headers": { "Authorization": "Bearer {{ $env.API_KEY }}" } } ``` Verwenden Sie GROSSBUCHSTABEN mit Unterstrichen (`MAX_RETRIES`, `WEBHOOK_SECRET`) und sprechende Namen, damit Variablen in Expressions eindeutig erkennbar sind. * Hardcoden Sie Credentials niemals direkt in Nodes. * Nutzen Sie unterschiedliche Werte für verschiedene Umgebungen (Test/Produktion). * Rotieren Sie Schlüssel und Secrets regelmäßig. * Speichern Sie Secrets nie in Git-Exporten Ihrer Workflows. Mehr dazu unter [Security](/automate/security). ## Credentials und Zugangsdaten Automate bringt einen integrierten **Credential Store** mit: Zugangsdaten werden verschlüsselt gespeichert, sind zugriffskontrolliert und lassen sich in mehreren Workflows wiederverwenden. In den Node-Einstellungen wählen Sie die passende Credential aus — der eigentliche Schlüssel taucht damit weder im Workflow-JSON noch in geteilten Workflows auf. Legen Sie API-Schlüssel nie direkt im Workflow-JSON ab — immer als Credential. Nur so bleiben sie verschlüsselt und in geteilten oder exportierten Workflows unsichtbar. Typische Anwendungsfälle: * **Header Auth** für API-Aufrufe mit Bearer-Token — zum Beispiel, wenn ein Workflow einen Localmind Agent aufruft. Die vollständige Anleitung finden Sie unter [Localmind Agent](/automate/Localmind-Agent). * **Trigger-Credentials** wie IMAP-Zugangsdaten für E-Mail-Trigger — siehe [Workflow Basics](/automate/basics). Schlagen Credentials fehl, prüfen Sie sie einzeln in den Node-Einstellungen und kontrollieren Sie, ob sie abgelaufen sind — Schritt-für-Schritt-Hilfe bietet [Debugging](/automate/debugging). **Abgrenzung:** Der Automate Credential Store ist von den org-weiten [Zugangsdaten](/settings/organization/Zugangsdaten) getrennt. Letztere verwalten Credentials für andere Localmind-Apps (z.B. den DeepL-Schlüssel der Übersetzungs-App) auf Org- oder Space-Ebene — nicht die Credentials Ihrer Automate-Workflows. ## Execution, Timeout und Retry Das Ausführungsverhalten steuern Sie auf zwei Ebenen: * **Node-Level:** Retry-Optionen direkt in den Node-Einstellungen — geeignet für einzelne fehleranfällige Operationen wie API-Calls. * **Workflow-Level:** Fehlerbehandlung über einen **Error Trigger**, der bei Fehlschlägen eine eigene Retry-Logik anstößt. ```json Node-Level Retry (Node-Optionen) theme={null} { "retryOnFail": true, "maxTries": 3, "waitBetweenTries": 1000 } ``` Setzen Sie angemessene Timeouts: Zu kurze Timeouts erzeugen unnötige Retries, zu lange verzögern die Fehlerbehandlung. Läuft eine Node wiederholt in Timeout-Fehler, erhöhen Sie den Timeout-Wert der Node oder implementieren Sie Retry-Logik — siehe [Debugging](/automate/debugging). Begrenzen Sie Retries immer mit einem Maximum, um Endlosschleifen zu vermeiden. Unterscheiden Sie außerdem zwischen wiederholbaren Fehlern (z.B. temporäre Netzwerkprobleme) und nicht wiederholbaren Fehlern (z.B. ungültige Anfragen) — die vollständigen Patterns inklusive Exponential Backoff finden Sie unter [Retry Logic](/automate/Retry-Logic). ## Nächste Schritte Retry-Strategien, Exponential Backoff und Error-Trigger-Patterns im Detail. Credentials, Umgebungsvariablen und Webhook-Absicherung in Automate. Grundlagen zu Nodes, Triggern und dem Aufbau von Workflows. Org-weite Credentials für Localmind-Apps verwalten. **Brauchen Sie Hilfe?** Unser Support-Team hilft Ihnen gerne bei der Konfiguration. Kontaktieren Sie uns unter [support@localmind.ai](mailto:support@localmind.ai). # Agenten Source: https://docs.localmind.ai/api-reference/Agenten Agenten programmatisch finden und ihre vollständige Konfiguration lesen — read-only Discovery über die Localmind API. Ein **Agent** ist die Einheit, die Sie über die Localmind API ansprechen: Er bündelt System-Prompt, Modell, Tools und den Zugriff auf Wissensquellen. Im Chat referenzieren Sie einen Agent über seine UUID (`model = `). Diese Seite beschreibt, wie Sie Agenten **read-only** finden und ihre vollständige Konfiguration auslesen. Zum **Auflisten** der Agenten, auf die Ihr Key Zugriff hat, gibt es zusätzlich den schlankeren OpenAI-kompatiblen Endpunkt `GET /v1/models` — er liefert nur `id` und `name`. Die hier beschriebenen Endpunkte liefern die **vollständige** Agent-Konfiguration. Siehe [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel). ## `POST /v1/agents/search` Paginierte Suche über die für Ihren Key zugänglichen Agenten. Antwortet im Pagination-Envelope; `items[]` enthält vollständige Agent-Objekte. `Bearer sk-…` — Ihr persönlicher API-Key. Anzahl der Einträge pro Seite. Seitennummer (1-basiert). Filter im Format `feld__operator` (z. B. `space_id__exact`). Filter können den Zugriff nur **eingrenzen**, nie erweitern. Siehe [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler). ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/agents/search?page=1&limit=10" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "filters": {} }' ``` ```json 200 OK theme={null} { "items": [ { "id": "{agent_id}", "name": "Test-INT1", "description": "", "version": "1.0.0", "agent_type": "simple", "model": "", "system_prompt": "Du bist ein hilfreicher Assistent.", "temperature": null, "max_tokens": 4096, "reasoning_config": null, "tool_attachments": [ { "tool_id": "{id}", "config": null } ], "is_public": false, "show_citations": true, "data_access_mode": "origin", "allowed_folder_ids": null, "organization_id": "{org_id}", "space_id": "{space_id}", "from_system": false, "conversation_count": 3, "created_at": "2026-06-13T10:33:54.125058Z", "updated_at": "2026-06-13T10:33:54.125058Z", "created_by": { "id": "{user_id}", "name": "Beispiel Nutzer", "avatar_url": null } } ], "total_items": 1, "total_pages": 1, "page": 1, "page_size": 10 } ``` ## `GET /v1/agents/{agent_id}` Liefert die vollständige Konfiguration eines einzelnen Agents. `Bearer sk-…` — Ihr persönlicher API-Key. Die Agent-UUID (z. B. aus `GET /v1/models` oder `POST /v1/agents/search`). ```bash cURL theme={null} curl "https://-api.localmind.ai/v1/agents/{agent_id}" \ -H "Authorization: Bearer sk-…" ``` ```json 200 OK theme={null} { "id": "{agent_id}", "name": "Test-INT1", "description": "", "version": "1.0.0", "agent_type": "simple", "model": "", "system_prompt": "Du bist ein hilfreicher Assistent.", "temperature": null, "max_tokens": 4096, "reasoning_config": null, "tool_attachments": [ { "tool_id": "{id}", "config": null } ], "is_public": false, "show_citations": true, "data_access_mode": "origin", "allowed_folder_ids": null, "organization_id": "{org_id}", "space_id": "{space_id}", "from_system": false, "conversation_count": 3, "created_at": "2026-06-13T10:33:54.125058Z", "updated_at": "2026-06-13T10:33:54.125058Z", "created_by": { "id": "{user_id}", "name": "Beispiel Nutzer", "avatar_url": null }, "last_edited_by": { "id": "{user_id}", "name": "Beispiel Nutzer", "avatar_url": null } } ``` ## Das Agent-Objekt Beide Endpunkte liefern dasselbe Agent-Objekt mit den folgenden Feldern. Die Agent-UUID. Wird im Chat als `model` verwendet. Anzeigename des Agents. Freitext-Beschreibung (kann leer sein). Versionskennung der Agent-Konfiguration, z. B. `"1.0.0"`. Typ des Agents, z. B. `"simple"`. Das hinter dem Agent konfigurierte Sprachmodell (Deployment-Name, z. B. `""`). Dieser Wert wird am Agent konfiguriert (**Agent bearbeiten → Modell**) und ist **nicht** der Wert, den Sie im Chat als `model` senden — dort verwenden Sie immer die Agent-UUID (`id`). Das System-Prompt, das das Verhalten des Agents bestimmt. Voreingestellte Sampling-Temperatur, oder `null` für den Modell-Default. Im Chat überschreibbar. Voreingestellte maximale Token-Anzahl. Im Chat überschreibbar. Optionale Reasoning-Konfiguration des Agents. Die dem Agent zugeordneten Tools. Jeder Eintrag hat ein `tool_id` und ein optionales `config`. Diese Tools führt der Agent serverseitig aus. Gibt an, ob der Agent öffentlich (innerhalb seiner Sichtbarkeit) bereitgestellt ist. Ob der Agent Quellenangaben zu seinen Antworten anzeigt. Steuert, auf welche Daten der Agent zugreift, z. B. `"origin"`. Schränkt den Wissenszugriff auf bestimmte Ordner ein, oder `null` für keine Einschränkung. Organisation, der der Agent gehört. Der Space, in dem der Agent lebt. Anzahl der bisherigen Konversationen mit diesem Agent. Erstellungszeitpunkt (ISO-8601). Ersteller des Agents mit `id`, `name` und `avatar_url`. Das analoge Feld `last_edited_by` beschreibt den letzten Bearbeiter. ## Mehrstufige Chats Eine persistente Conversation-API (`/v1/conversations/*`) ist derzeit **nicht** Teil der öffentlichen Dokumentation und folgt zu einem späteren Zeitpunkt. Für **mehrstufige Chats** nutzen Sie aktuell den **stateless** Endpunkt `POST /v1/chat/completions` und senden den bisherigen Verlauf bei jedem Aufruf im `messages`-Array mit. Ein vollständiges Beispiel finden Sie unter [Use Cases](/api-reference/Use-Cases). ## Verwandte Seiten Agenten per `GET /v1/models` auflisten und per Chat Completions ansprechen. Mehrstufige Chats stateless umsetzen und weitere Rezepte. Pagination, Filter-DSL und das Fehlermodell. Welche Agenten Ihr Key sieht und wie der Zugriff verengt wird. # Authentifizierung und Rollen Source: https://docs.localmind.ai/api-reference/Authentifizierung-und-Rollen Wie Sie sich gegenüber der Localmind API authentifizieren und welche Rechte ein API-Key hat — für Entwickler und Admins. Die Localmind API kennt zwei Authentifizierungsmethoden auf denselben Endpunkten. Diese Seite erklärt beide, grenzt sie vom separaten Automate-API-Key ab und beschreibt das zentrale Sicherheitsprinzip, das Admins kennen müssen: **Ein API-Key kann Zugriff nur verengen, niemals erweitern.** Diese Seite ist für **Entwickler** (die programmatisch auf Localmind zugreifen) und für **Admins** (die verstehen wollen, welche Rechte ein ausgestellter Key hat) gleichermaßen relevant. ## Die zwei Authentifizierungsmethoden Beide Methoden senden ein Bearer-Token im `Authorization`-Header. Sie wirken auf denselben Endpunkten, unterscheiden sich aber in der Token-Quelle: | Methode | Header | Quelle | Typischer Einsatz | | ---------------- | ----------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **User-API-Key** | `Authorization: Bearer sk-…` | In der Web-App erstellt (Benutzereinstellungen → API-Schlüssel) | Programmatischer Zugriff: eigene Apps, n8n, OpenAI-SDK-Umstieg, RAG über eigene Dokumente | | **Keycloak-JWT** | `Authorization: Bearer ` | Frontend-Session der Web-App | Die Localmind-Web-App selbst | ```bash theme={null} curl -X GET "https://-api.localmind.ai/v1/models" \ -H "Authorization: Bearer sk-…" ``` Der **User-API-Key** ist die kanonische Methode für die programmatische Nutzung. Er wirkt nur in der **Heimat-Org** des Users, der ihn erstellt hat — der Key eines Users aus einer **anderen** Organisation funktioniert nicht (die Web-App warnt bereits beim Erstellen davor). Den Scope wählen Sie beim Anlegen: **alle Spaces** oder **ausgewählte Spaces**. Wie Sie einen Key in der Web-App anlegen und widerrufen, beschreibt die Plattform-Seite [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel). ### Abgrenzung: Automate Der hier dokumentierte User-API-Key gilt für die `/v1`-Endpunkte der Localmind-API. Für das programmatische **Verwalten von Automate-Workflows** gilt er **nicht** — wie Sie Ihre Workflows verwalten, beschreibt [Automate und API-Zugriff](/administration/api). ## Kernprinzip: Ein Key verengt, er erweitert nie Ein User-API-Key hat **exakt die Berechtigungen seines Besitzers** — nicht mehr und nicht weniger. Er kann den Zugriff gegenüber dem Besitzer nur **verengen** (per Scope), niemals über dessen Rolle hinaus **erweitern**. Bei jeder Anfrage mit einem Key greifen drei Gates. Bei Keycloak-JWT sind diese Gates No-Ops, das Frontend-Verhalten bleibt unverändert. | Gate | Wirkung | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **User-Permissions** | Es gilt dieselbe Space- und Rollen-Prüfung wie im Frontend. Der Key sieht und darf genau das, was der Besitzer sieht und darf. | | **Org-Binding** | Der Key ist an **eine** Organisation gebunden (die Heim-Org des Besitzers). Fremde Organisationen sind unerreichbar. | | **Space-Scope** | Ein *scoped* Key erreicht nur die beim Anlegen gewählten Spaces. Ein *org-weiter* Key erreicht alles, was der Besitzer in seiner Org sieht. | Das Prinzip ist für Admins die wichtigste Aussage: Sie müssen einem ausgestellten Key keine eigenen Rechte zuweisen. Der Key kann strukturell nie mehr, als die Rolle des Besitzers erlaubt. Wer einem Key weniger Reichweite geben will, schränkt den Scope auf ausgewählte Spaces ein. ## Rolle bestimmt die erlaubten Aktionen Da der Key die Rolle des Besitzers 1:1 erbt, entscheidet die **Space-Rolle**, welche Aktionen erlaubt sind. Lesen, Suchen und Chatten funktionieren mit jeder Rolle. Schreibende Aktionen (Anlegen, Hochladen, Löschen) erfordern Schreibrechte im jeweiligen Space. | Rolle im Space | Lesen / Suchen / Chatten | Anlegen / Upload / Löschen | | ------------------------------------------------- | ------------------------ | -------------------------- | | **Owner / Editor** (z. B. eigener Privater Space) | erlaubt | erlaubt — voller CRUD | | **Viewer** | erlaubt | abgelehnt mit **403** | Ein Viewer-Key kann lesen und suchen, aber **nicht** schreiben. Eine Schreibanfrage wird mit einem `403` und einer sprechenden Meldung abgelehnt: ```json theme={null} { "detail": "Permission denied: documents:create" } ``` Schreiben funktioniert nur in Spaces, in denen der Besitzer Schreibrechte hat. Der natürliche Ort dafür ist der eigene **Private Space** — jeder User ist dessen Owner und kann dort per Key alles verwalten. Die Rollenstruktur (Instanz → Org → Space) ist im [Berechtigungsmodell](/settings/instance/Role-Templates) und für die Org-Mitgliederverwaltung unter [Mitglieder](/settings/organization/Mitglieder) beschrieben. ## Opt-in pro Endpunkt Nicht jeder Endpunkt akzeptiert einen API-Key. Endpunkte, die nicht für den Key-Zugriff freigeschaltet sind, antworten bewusst mit `401` und verweisen auf die Frontend-Session: ```json theme={null} { "detail": "API key not accepted on this endpoint. Use a Keycloak access token." } ``` Ein Beispiel ist `GET /v1/me` (Ihr eigenes Benutzerprofil): Mit einem User-API-Key liefert dieser Endpunkt absichtlich `401`. Solche Endpunkte sind ausschließlich über eine Keycloak-Session erreichbar. ## Narrowing ist wasserdicht Das Scope-Modell verhindert Datenlecks über Filter. Ein Filter auf einen Space, den der Key nicht erreicht (fremder oder nicht-gescopter Space), liefert keinen Fehler, der Existenz verraten würde — er liefert **0 Treffer**: ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/data/hybrid-search" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{"query": "Vertrag", "space_id": ""}' # -> 200 { "total_results": 0, "results": [] } ``` Fremde Spaces tauchen in `POST /v1/spaces/search` gar nicht erst auf. Der vom Aufrufer gesetzte Filter wird mit der für den Key erreichbaren Menge **geschnitten**, nie erweitert. ### Suche/Filter vs. direkter ID-Zugriff: das stille 404 Außerhalb des Key-Scopes verhält sich die API je nach Zugriffsart unterschiedlich — beide Varianten sind bewusst so gestaltet, dass die **Existenz** fremder Ressourcen nicht verraten wird: | Zugriffsart | Verhalten außerhalb des Key-Scopes | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Suche/Filter** (z. B. `POST /v1/data/hybrid-search`, `POST /v1/spaces/search`) | `200` mit **0 Treffern** — kein Fehler, leeres Ergebnis | | **Direkter ID-Zugriff** (z. B. `GET /v1/data/{document_id}` mit einer ID außerhalb des Scopes) | bewusst **`404`** statt `403` — die Ressource erscheint als nicht vorhanden („stilles 404") | Das stille 404 ist Absicht: Ein `403` würde bestätigen, dass die Ressource existiert. Erhalten Sie bei einer bekannten, korrekten ID ein `404`, prüfen Sie deshalb zuerst den **Space-Scope Ihres Keys** — nicht die ID. Eine Übersicht der Fehlercodes mit Lösungswegen bietet [HTTP-Fehlercodes](/troubleshooting/HTTP-Fehlercodes). ## Nachvollziehbarkeit: Audit und last\_used\_at Jede Key-Nutzung ist nachvollziehbar: * **`last_used_at`** wird bei jeder Anfrage aktualisiert. * Key-Aktionen werden im **Audit-Log** mit `auth_method=api_key` und der Key-ID attribuiert. Diese Informationen sind in der Web-App einsehbar, aber **nicht** über den Key selbst auslesbar. Behandeln Sie API-Keys wie Passwörter: niemals in öffentlichen Repositories, Client-seitigem Code oder Logs ablegen. Bei Verdacht auf Kompromittierung widerrufen Sie den betroffenen Key gezielt, statt alle zu rotieren. ## Verwandte Seiten Base-URL, Pagination, Filter-DSL, Fehlermodell und Statuscodes. `GET /v1/models` und `POST /v1/chat/completions` als Drop-in für OpenAI-SDKs. Plattform-Sicht: Keys in der Web-App anlegen, scopen und widerrufen. Admin-Sicht auf Mitglieder, deren Rollen und damit die Reichweite ihrer Keys. # Dateien und Ordner Source: https://docs.localmind.ai/api-reference/Dateien-und-Ordner Raw-File-Storage eines Space verwalten und Dokumente über die Folder-Resource-API strukturieren und schachteln. Diese Seite behandelt den **Raw-File-Layer** eines Space — pfad-basierte, pro Organisation verschlüsselte Rohdateien — sowie die **Folder-Resource-API** zum Strukturieren von Dokumenten. Den durchsuchbaren Documents-Layer (Knowledge-Base, Hybrid Search) beschreibt [Dokumente und Suche](/api-reference/Dokumente-und-Suche). Localmind hat zwei Storage-Layer. Ein Upload über den File-Endpunkt `POST /v1/spaces/{space_id}/data/upload` legt **beides** an: die Rohdatei **und** ein durchsuchbares Document. Die beiden Delete-Pfade unterscheiden sich jedoch in der Wirkung — siehe [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler#querschnittsthemen). Alle Beispiele nutzen die Base-URL `https://-api.localmind.ai/v1`. Ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix). Jeder Request trägt den Header `Authorization: Bearer sk-…`. ## Raw Files Die Raw-File-Endpunkte liegen unter `/v1/spaces/{space_id}/data/*` und arbeiten **pfad-basiert**: Sie adressieren Dateien über ihren Pfad innerhalb des Space-Storage. | Methode & Pfad | Zweck | | ----------------------------------------------- | ------------------------------------------------------------------------------------- | | `POST /v1/spaces/{space_id}/data/upload` | Datei hochladen (`file` + `path`) → `201`; wird **auch** ein durchsuchbares Document. | | `GET /v1/spaces/{space_id}/data/files?prefix=` | Dateien auflisten, optional nach Pfad-Präfix gefiltert. | | `GET /v1/spaces/{space_id}/data/download?path=` | Download über eine Proxy-URL — braucht den Key (kein öffentlicher Link). | | `PATCH /v1/spaces/{space_id}/data/rename` | Datei umbenennen oder verschieben (`old_path` → `new_path`) → `204`. | | `DELETE /v1/spaces/{space_id}/data/files?path=` | Rohdatei physisch löschen → `204`; entfernt auch Vektoren und abgeleiteten Record. | ### Datei hochladen Die hochzuladende Datei. Das aktuelle Größenlimit pro Datei zeigt Ihnen das Upload-Feld in der Web-App; für Details kontaktieren Sie den Support. Zielpfad der Datei innerhalb des Space-Storage. ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/spaces/{space_id}/data/upload" \ -H "Authorization: Bearer sk-…" \ -F "path=vertraege/2026/" \ -F "file=@vertrag.pdf" ``` ```json 201 theme={null} { "object_name": "spaces/{space_id}/data/vertraege/2026/vertrag.pdf" } ``` Da der Upload auch ein Document anlegt, läuft anschließend die Verarbeitungs-Pipeline. Wie Sie ihren Status verfolgen, beschreibt [Dokumente und Suche](/api-reference/Dokumente-und-Suche). ### Dateien auflisten, herunterladen, umbenennen, löschen ```bash Auflisten theme={null} curl "https://-api.localmind.ai/v1/spaces/{space_id}/data/files?prefix=vertraege/" \ -H "Authorization: Bearer sk-…" ``` ```bash Umbenennen / Verschieben theme={null} curl -X PATCH "https://-api.localmind.ai/v1/spaces/{space_id}/data/rename" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "old_path": "vertraege/2026/vertrag.pdf", "new_path": "archiv/vertrag.pdf" }' ``` ```bash Löschen theme={null} curl -X DELETE "https://-api.localmind.ai/v1/spaces/{space_id}/data/files?path=archiv/vertrag.pdf" \ -H "Authorization: Bearer sk-…" ``` Der Download läuft über eine **Proxy-URL** des Backends, nicht über einen öffentlichen vorsignierten Link. Ein Download-Aufruf **ohne** gültigen `Authorization`-Header wird mit `403` abgelehnt, da die Inhalte pro Organisation verschlüsselt sind. Senden Sie den Key auch beim Download mit. ## Folders (Resource-API) Ordner verwalten Sie über die **Resource-API** unter `/v1/folders`. Diese Ordner sind eigenständige Ressourcen mit eigener UUID und lassen sich beliebig schachteln — abzugrenzen von den pfad-basierten Datei-Ordnern (siehe Sicherheits-Hinweis unten). | Methode & Pfad | Zweck | | -------------------------------------- | ------------------------------------------------------------------------------------------ | | `POST /v1/folders` | Ordner anlegen. Root: `{"name","space_id"}`; verschachtelt: zusätzlich `parent_folder_id`. | | `GET /v1/folders/space/{space_id}` | Alle Ordner eines Space auflisten (optional `?parent_folder_id=` für Kinder). | | `GET /v1/folders/{folder_id}` | Einzelnen Ordner abrufen. | | `PATCH /v1/folders/{folder_id}` | Umbenennen (`{"name"}`) oder verschieben (`{"parent_folder_id"}`). | | `GET /v1/folders/{folder_id}/contents` | Unterordner **und** Dokumente in einem Call. | | `DELETE /v1/folders/{folder_id}` | `204` — löscht den Ordner samt allen Kindern (Cascade). | ### Ordner anlegen und schachteln Anzeigename des Ordners. UUID des Space. **Auch beim Verschachteln Pflicht** — fehlt das Feld, antwortet die API mit `422`. UUID des übergeordneten Ordners. Weglassen, um einen Ordner auf Root-Ebene anzulegen. ```bash Root-Ordner theme={null} curl -X POST "https://-api.localmind.ai/v1/folders" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "name": "Verträge", "space_id": "{space_id}" }' ``` ```bash Unterordner theme={null} curl -X POST "https://-api.localmind.ai/v1/folders" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "name": "2026", "parent_folder_id": "{folder_id}", "space_id": "{space_id}" }' ``` ```json 201 theme={null} { "id": "{folder_id}", "name": "Verträge", "parent_folder_id": null, "org_id": "{org_id}", "home_space_id": "{space_id}", "from_system": false, "created_by": { "id": "{user_id}", "name": "Beispiel Nutzer", "avatar_url": null } } ``` `space_id` ist beim Anlegen **immer** Pflicht — auch dann, wenn Sie über `parent_folder_id` verschachteln. Fehlt es, liefert die API `422` mit `loc: ["body", "space_id"]`. ### Ordnerinhalt in einem Call abrufen `GET /v1/folders/{folder_id}/contents` liefert Unterordner und Dokumente gemeinsam — Sie sparen sich zwei separate Aufrufe. ```json 200 theme={null} { "folder_id": "{folder_id}", "sub_folders": [], "documents": [], "sub_folder_count": 0, "document_count": 0 } ``` Direkte Unterordner. Dokumente direkt in diesem Ordner. Anzahl der direkten Unterordner. Anzahl der Dokumente in diesem Ordner. ### Umbenennen, verschieben, löschen `PATCH /v1/folders/{folder_id}` benennt um oder hängt den Ordner unter einen anderen Eltern-Ordner (`parent_folder_id`). `DELETE /v1/folders/{folder_id}` löscht den Ordner **kaskadierend** — alle enthaltenen Unterordner und ihre Verweise verschwinden mit; ein anschließender Zugriff auf ein Kind liefert `404`. ```bash Umbenennen theme={null} curl -X PATCH "https://-api.localmind.ai/v1/folders/{folder_id}" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "name": "Verträge (Archiv)" }' ``` ```bash Cascade-Delete theme={null} curl -X DELETE "https://-api.localmind.ai/v1/folders/{folder_id}" \ -H "Authorization: Bearer sk-…" ``` ## Sicherheits-Verhalten Das Zugriffsmodell ist role-aware und fail-closed verifiziert. Ein API-Key erbt die Rolle seines Besitzers 1:1 und kann den Zugriff nur **verengen**, nie erweitern — Details unter [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). **Schreiben braucht Schreibrechte.** Ein Viewer-Key darf lesen und suchen, aber nicht schreiben: Folder- oder Document-Anlegen, Upload und Löschen werden mit `403` abgelehnt (`Permission denied: write on folders` bzw. `documents:create`). Schreiben gelingt nur in Spaces, in denen der Besitzer Schreibrechte hat — etwa im eigenen Private Space. Weitere verifizierte Eigenschaften des Zugriffsmodells: * **Download ohne Auth → `403`.** Inhalte sind pro Organisation verschlüsselt; es gibt keinen öffentlichen Link. * **Narrowing ist wasserdicht.** Ein Filter auf einen fremden oder unerreichbaren Space liefert `200` mit 0 Treffern (kein Leak); fremde Spaces tauchen in `spaces/search` gar nicht erst auf. * **Fail-closed.** Eine ungültige (Nicht-UUID-)ID führt zu `422` aus der Pfad-Validierung — nie zu `500` und nie zu einem Datenleck. * **Dateigrößen-Limit.** Zu große Uploads werden mit `400` abgelehnt (`File size … exceeds maximum allowed`). Das aktuelle Limit pro Datei zeigt Ihnen das Upload-Feld in der Web-App; für Details kontaktieren Sie den Support. **Für Integrationen `/v1/folders` verwenden — nicht die Path-Folders.** Die pfad-basierten Ordner-Endpunkte `POST /v1/spaces/{space_id}/data/folders` sind **JWT-only**: Ein API-Key wird dort mit `401` abgelehnt (`GET` darauf liefert `405`). Die hier dokumentierte Resource-API `/v1/folders` ist der key-fähige Weg für programmatische Ordner-Verwaltung. ## Verwandte Seiten Knowledge-Base, Pipeline-Status und Hybrid Search. Welche Rechte ein API-Key hat und wie Narrowing wirkt. Base-URL, Statuscodes und die zwei Storage-Layer im Querschnitt. Dokumente und Ressourcen aus der UI-Perspektive. # Dokumente und Suche Source: https://docs.localmind.ai/api-reference/Dokumente-und-Suche Dokumente in die Knowledge-Base hochladen, die Pipeline überwachen und per Hybrid Search semantisch durchsuchen. Localmind trennt zwei Storage-Layer: **Raw Files** sind pfad-basierte Rohdateien in einem Space, **Documents** sind Dateien, die die Verarbeitungs-Pipeline durchlaufen haben und per Hybrid Search durchsuchbar sind. Diese Seite behandelt den **Documents-Layer** — die Knowledge-Base, aus der RAG-Retrieval gespeist wird. Den Raw-File-Layer und die Ordner-Verwaltung beschreibt [Dateien und Ordner](/api-reference/Dateien-und-Ordner). Ein Upload über `POST /v1/data/upload` befüllt **beide** Layer gleichzeitig: Die Rohdatei wird gespeichert **und** ein durchsuchbares Document angelegt. Sie müssen nicht separat hochladen. Alle Beispiele nutzen die Base-URL `https://-api.localmind.ai/v1`. Ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix). Jeder Request trägt den Header `Authorization: Bearer sk-…`. Die geltenden Konventionen zu Base-URL, Paginierung und Statuscodes beschreibt [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler). ## Documents verwalten Die folgenden Endpunkte decken den Lebenszyklus eines Dokuments in der Knowledge-Base ab — vom Upload über die Inspektion bis zum Neuverarbeiten. | Methode & Pfad | Zweck | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `POST /v1/data/upload` | Datei (multipart) hochladen → `201` + `processing_state`; triggert die Pipeline automatisch. | | `GET /v1/data/{document_id}` | Metadaten und `processing_state` lesen. Unbekannte ID → `404`. | | `PATCH /v1/data/{document_id}` | Metadaten schreiben (`doc_metadata`) — **kein** Reprocess. | | `DELETE /v1/data/{document_id}` | `204` — entfernt den Knowledge-Base-Record samt Chunks; das Dokument verschwindet binnen Sekunden aus der Suche. | | `GET /v1/data/{document_id}/text` | Extrahierte Content-Units (markdown-aware) abrufen. | | `GET /v1/data/{document_id}/chunks` | Chunks samt Embedding-Metadaten abrufen. | | `GET /v1/data/{document_id}/versions` | Reprocess-Historie eines Dokuments. | | `POST /v1/data/{document_id}/reprocess` | `202` + `pipeline_run_id`; verarbeitet die bestehende Originaldatei neu. | | `POST /v1/data/batch-reprocess` | Mehrere Dokumente in einem Aufruf neu verarbeiten. | ### Dokument hochladen Senden Sie die Datei und die Ziel-`space_id` als `multipart/form-data`. Die Pipeline (parse → chunk → embed) startet automatisch im Hintergrund. Die hochzuladende Datei. Das aktuelle Größenlimit pro Datei zeigt Ihnen das Upload-Feld in der Web-App; für Details kontaktieren Sie den Support. Dateien über dem Limit lehnt die API mit `400` ab. UUID des Ziel-Space. Sie benötigen Schreibrechte in diesem Space — andernfalls antwortet die API mit `403`. Fehlt das Feld, ist die Antwort `422`. ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/data/upload" \ -H "Authorization: Bearer sk-…" \ -F "space_id={space_id}" \ -F "file=@reisekostenrichtlinie.md" ``` ```python Python theme={null} import requests resp = requests.post( "https://-api.localmind.ai/v1/data/upload", headers={"Authorization": "Bearer sk-…"}, data={"space_id": "{space_id}"}, files={"file": ("reisekostenrichtlinie.md", open("reisekostenrichtlinie.md", "rb"))}, ) document = resp.json() print(document["id"], document["processing_state"]) ``` ```json 201 — direkt nach dem Upload theme={null} { "id": "{document_id}", "file_type": "MARKDOWN", "file_size": 412, "file_path": "spaces/{space_id}/documents/{document_id}/original/reisekostenrichtlinie.md", "doc_metadata": { "original_filename": "reisekostenrichtlinie.md", "content_type": "text/markdown" }, "processing_state": { "parsed": false, "chunked": false, "embedded": false }, "space_id": "{space_id}", "organization_id": "{org_id}", "created_by": "{user_id}" } ``` Direkt nach dem Upload stehen alle drei `processing_state`-Flags auf `false` — die Pipeline läuft noch. Wie Sie auf den Abschluss warten, zeigt der nächste Abschnitt. ### Auf den Pipeline-Abschluss warten Der Upload ist **asynchron**. Fragen Sie `GET /v1/data/{document_id}` ab, bis die Verarbeitung abgeschlossen ist. Maßgeblich ist das Feld `processing_state`: Status der Verarbeitungs-Pipeline. `true`, sobald die Datei geparst (Text extrahiert) wurde. `true`, sobald der extrahierte Text in Chunks zerlegt wurde. `true`, sobald die Chunks eingebettet (Embeddings berechnet) wurden. Gesamtstatus. Bei Abschluss `"completed"` — dann ist das Dokument durchsuchbar. Anzahl der erzeugten Chunks. Verwendetes Embedding-Modell, z. B. `localmind-embeddings`. ```json 200 — pipeline_status: completed theme={null} { "processing_state": { "parsed": true, "chunked": true, "embedded": true, "parser_name": "markdown", "chunker_name": "page_based", "chunk_count": 1, "embedding_model": "localmind-embeddings", "embedded_chunk_count": 1, "pipeline_status": "completed" } } ``` Pollen Sie `processing_state.pipeline_status` so lange, bis es `"completed"` ist, bevor Sie ein frisch hochgeladenes Dokument durchsuchen. Vorher liefert die Suche es nicht zurück. ### Dokumente neu verarbeiten Wenn sich die Parser- oder Chunker-Konfiguration geändert hat, verarbeiten Sie ein bestehendes Dokument neu. Die Originaldatei bleibt dabei erhalten. `POST /v1/data/{document_id}/reprocess` antwortet mit `202` und einer `pipeline_run_id`, über die Sie den neuen Lauf verfolgen können. Für mehrere Dokumente nutzen Sie `POST /v1/data/batch-reprocess` mit einem Objekt, das die IDs unter dem Schlüssel `document_ids` enthält: ```bash Einzelnes Dokument theme={null} curl -X POST "https://-api.localmind.ai/v1/data/{document_id}/reprocess" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "chunker_name": "page_based" }' ``` ```bash Batch theme={null} curl -X POST "https://-api.localmind.ai/v1/data/batch-reprocess" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "document_ids": ["{document_id}", "{document_id}"] }' ``` Der Body von `batch-reprocess` ist ein **Objekt** mit dem Schlüssel `document_ids` — kein rohes Array. Eine ungültige ID bricht den Batch nicht ab; die Antwort listet pro Dokument den Erfolg unter `results[]`. ## Semantische Suche `POST /v1/data/hybrid-search` durchsucht die Documents eines Space mit **Hybrid Search** — einer Kombination aus dichter Vektor-Suche und lexikalischer BM25-Keyword-Suche (sparse). Das Ergebnis ist eine nach `score` sortierte Liste relevanter Chunks mit Quellenangabe. Dieselbe Suche nutzen Agenten intern für RAG-Retrieval. Die Suchanfrage in natürlicher Sprache. UUID des zu durchsuchenden Space. Die Suche ist **space-scoped**. Optionale Liste von Document-UUIDs, auf die der Suchraum eingegrenzt wird. Die Antwort enthält das Feld `results` mit den Treffern: Nach `score` absteigend sortierte Treffer. UUID des Chunks. UUID des Quell-Dokuments. Dateiname des Quell-Dokuments. Kombinierter Relevanz-Score (Hybrid). Höher = relevanter. Anteil der Vektor-Suche am Score. Anteil der BM25-Keyword-Suche am Score. Der Chunk-Text — die eigentliche Beleg-Passage. Chunk-Metadaten wie `heading_text`, `format` und `word_count`. ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/data/hybrid-search" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "query": "Hotelübernachtung Erstattung pro Nacht", "space_id": "{space_id}" }' ``` ```json 200 theme={null} { "query": "Hotelübernachtung Erstattung pro Nacht", "space_id": "{space_id}", "total_results": 10, "results": [ { "chunk_id": "{chunk_id}", "document_id": "{document_id}", "document_name": "reisekostenrichtlinie.md", "file_type": "MARKDOWN", "folder_path": null, "chunk_index": 0, "score": 0.913, "dense_score": null, "sparse_score": null, "text": "## Übernachtung\nHotelübernachtungen werden bis 120 EUR pro Nacht erstattet. …", "metadata": { "heading_text": "Übernachtung", "format": "markdown", "word_count": 11 } } ] } ``` Ein in `document_ids` oder über Folder-Pfade gesetzter Filter wird mit der für Ihren Key **erreichbaren Menge geschnitten**, nie erweitert. Ein Filter auf ein Dokument außerhalb Ihres Zugriffs liefert keine Treffer statt eines Fehlers — siehe [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## End-to-End: eigenes Dokument hochladen und abfragen Das folgende Beispiel ist end-to-end verifiziert. Es zeigt den vollständigen RAG-Ablauf: vom Auffinden des eigenen Private Space über den Upload bis zur semantischen Suche. Jeder Nutzer ist Owner seines [Privaten Space](/api-reference/Authentifizierung-und-Rollen) und darf dort per Key hochladen. Listen Sie Ihre Spaces auf und wählen Sie den Eintrag mit `"is_private": true`. ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/spaces/search" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{}' ``` ```json Antwort (gekürzt) theme={null} { "items": [ { "name": "Private Space", "id": "{space_id}", "is_private": true, "owner_id": "{user_id}" } ], "total_items": 2, "total_pages": 1, "page": 1, "page_size": 10 } ``` Sie haben die `id` des Private Space — das ist Ihr `{space_id}` für die nächsten Schritte. Laden Sie die Datei per multipart hoch. Die Antwort ist `201`; die Pipeline läuft asynchron an. ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/data/upload" \ -H "Authorization: Bearer sk-…" \ -F "space_id={space_id}" \ -F "file=@reisekostenrichtlinie.md" ``` Notieren Sie die `id` aus der Antwort — das ist Ihr `{document_id}`. Alle `processing_state`-Flags stehen zunächst auf `false`. Fragen Sie das Dokument ab, bis `pipeline_status` den Wert `"completed"` hat. ```bash theme={null} curl "https://-api.localmind.ai/v1/data/{document_id}" \ -H "Authorization: Bearer sk-…" ``` `processing_state.parsed`, `chunked` und `embedded` sind alle `true`, `pipeline_status` ist `"completed"` — das Dokument ist durchsuchbar. Stellen Sie die Suchanfrage an `hybrid-search`. Der passende Chunk steht mit dem höchsten `score` oben. ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/data/hybrid-search" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "query": "Hotelübernachtung Erstattung pro Nacht", "space_id": "{space_id}" }' ``` Im verifizierten Beispiel lieferte diese präzise Frage den Ziel-Chunk auf Platz 1 mit `score` 0.91. **Retrieval scopen:** In einem Space mit vielen oder großen Dokumenten kann ein großes Dokument die Top-Treffer dominieren. Beobachtet: Dieselbe Frage präzise gestellt → Ziel-Chunk auf Platz 1; umgangssprachlich gestellt → nur auf Platz 4. Verwenden Sie präzise Begriffe und/oder grenzen Sie den Suchraum per `document_ids` ein: ```json theme={null} { "query": "Hotel Erstattung", "space_id": "{space_id}", "document_ids": ["{document_id}"] } ``` Als Alternative zum direkten `hybrid-search`-Aufruf können Sie einen [Agent](/api-reference/Agenten) mit Daten-Tool ansprechen — dann genügt `POST /v1/chat/completions`, und der Agent zieht die Belege selbst aus seinem Space. Der direkte `hybrid-search`-Aufruf oben ist der explizit verifizierte Weg. ## IDs finden (Discovery) IDs ermitteln Sie ausschließlich über diese Such-Endpunkte — die Web-App zeigt sie nicht an. Alle drei Endpunkte sind paginiert und **auto-narrowing**: Sie liefern nur, was Ihr Key erreicht. | Methode & Pfad | Zweck | | ------------------------ | ------------------------------------------------------------------------------------------------- | | `POST /v1/spaces/search` | Spaces auflisten (Body `{}` für alle erreichbaren). `is_private` markiert den Private Space. | | `POST /v1/data/search` | Documents eines Space auflisten — mit `filters` und `order_by` im Body, `page`/`limit` als Query. | | `POST /v1/agents/search` | Agenten samt vollständiger Konfiguration auflisten — siehe [Agenten](/api-reference/Agenten). | ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/data/search?page=1&limit=20" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "filters": { "space_id__exact": "{space_id}", "file_type__exact": "PDF" }, "order_by": ["-created_at"] }' ``` Die Antwort ist ein Pagination-Envelope (`items`, `total_items`, `total_pages`, `page`, `page_size`); jedes Element enthält die Document-Metadaten samt `processing_state`. Das Envelope-Format und die Filter-DSL beschreibt [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler). ## Verwandte Seiten Der Raw-File-Layer und die Resource-Ordner unter `/v1/folders`. RAG, Chatbot und n8n als fertige Rezepte. Base-URL, Paginierung, Filter-DSL und Statuscodes. Dieselbe Knowledge-Base aus der UI-Perspektive. # Konventionen und Fehler Source: https://docs.localmind.ai/api-reference/Konventionen-und-Fehler Base-URL, Pagination, Filter-DSL, das Fehlermodell und alle Statuscodes der Localmind API auf einen Blick. Diese Seite fasst die Konventionen zusammen, die für **alle** Endpunkte der Localmind API gelten: wie Sie die richtige Base-URL bilden, wie Paginierung und Filter funktionieren, wie Fehler aussehen und was die einzelnen Statuscodes bedeuten. ## Base-URL und `/v1`-Prefix Jede Localmind-Instanz hat einen eigenen **API-Host** mit dem Suffix `-api`. Alle Pfade tragen den Prefix `/v1`: ``` https://-api.localmind.ai/v1 ``` Ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix). Verwenden Sie nicht den `-app`-Host — der bedient nur das Frontend. Und es gibt **keinen** geteilten Host `https://api.localmind.ai/…`: Die API ist immer instanz-spezifisch unter der `-api`-Subdomain mit `/v1`-Prefix erreichbar. ### Health-Check Ob die API erreichbar ist, prüfen Sie ohne Authentifizierung über den Health-Endpunkt: ```bash theme={null} curl "https://-api.localmind.ai/health" # -> {"status":"ok"} ``` ## Paginierung Such-Endpunkte (`POST /v1/*/search`) liefern ihre Ergebnisse in einem **Pagination-Envelope**: ```json theme={null} { "items": [], "total_items": 142, "total_pages": 15, "page": 1, "page_size": 10 } ``` Die Ergebnisse der aktuellen Seite. Gesamtanzahl der Treffer über alle Seiten. Gesamtanzahl der Seiten. Aktuelle Seitennummer (1-basiert). Anzahl der Einträge pro Seite. Seite und Seitengröße steuern Sie über `page` und `limit`. Zusätzlich senden Sie `filters` und `order_by` im **Request-Body**: ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/data/search?page=1&limit=20" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "filters": { "file_type__exact": "MARKDOWN" }, "order_by": ["-created_at"] }' ``` ## Filter-DSL Im `filters`-Objekt verwenden Sie Schlüssel im Format `feld__operator`. Sortiert wird über `order_by` als Array von Feldnamen; ein vorangestelltes Minus kehrt die Reihenfolge um. | Beispiel | Bedeutung | | -------------------------------------- | ------------------------------------------ | | `"agent_id__exact": ""` | Exakte Übereinstimmung auf `agent_id` | | `"file_type__exact": "PDF"` | Exakte Übereinstimmung auf `file_type` | | `"space_id__in": ["", ""]` | `space_id` ist in der Liste enthalten | | `"order_by": ["-created_at"]` | Absteigend nach Erstellungsdatum sortieren | ```json theme={null} { "filters": { "agent_id__exact": "", "space_id__in": ["", ""] }, "order_by": ["-created_at"] } ``` Filter können den Zugriff nur **eingrenzen**, nie erweitern. Ein Filter auf einen Space, den Ihr Key nicht erreicht, liefert 0 Treffer statt eines Fehlers — siehe [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## Fehlermodell Die API kennt zwei Fehlerformate. **Allgemeine Fehler** liefern ein `detail` als String: ```json theme={null} { "detail": "Model 'x' not found" } ``` ```json theme={null} { "detail": "Permission denied: documents:create" } ``` **Validierungsfehler** (Statuscode `422`) liefern `detail` als Array mit Feld-Position, Meldung und Typ: ```json theme={null} { "detail": [ { "loc": ["body", "space_id"], "msg": "Field required", "type": "missing" } ] } ``` Pfad zum fehlerhaften Feld, z. B. `["body", "space_id"]`. Menschenlesbare Beschreibung des Fehlers. Maschinenlesbarer Fehlertyp, z. B. `missing`. ## Statuscodes | Code | Bedeutung | | ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `200` | Erfolg | | `201` | Ressource erstellt | | `202` | Asynchron angenommen (Pipeline läuft) | | `204` | Erfolgreich, kein Inhalt (z. B. gelöscht) | | `400` | Bad Request — z. B. überschrittenes Größenlimit | | `401` | Auth fehlt/ungültig oder Endpunkt nicht für den Key freigeschaltet | | `403` | Keine Berechtigung, falsche Org oder Download ohne Auth | | `404` | Ressource nicht gefunden — oder der API-Key hat keinen Zugriff auf die Ressource (stilles 404 bei Direkt-ID-Zugriff; Such-Endpunkte liefern stattdessen `200` mit leerem Ergebnis, siehe [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen)) | | `405` | Method Not Allowed — häufig **fehlender Trailing-Slash** | | `422` | Request-Validierung fehlgeschlagen | Wie Sie `422`, `403` und das stille `404` in der Praxis diagnostizieren — Symptom, Ursache, Lösung — zeigt [HTTP-Fehlercodes verstehen](/troubleshooting/HTTP-Fehlercodes). Der `405` ist eine typische Stolperfalle: Einige Erstellungs-Endpunkte verlangen den abschließenden Schrägstrich — achten Sie auf die exakte Pfadangabe in der jeweiligen Referenz. ## Querschnittsthemen Einige Eigenschaften der API betreffen mehrere Endpunkte und sind beim Aufbau einer Integration wichtig. Localmind trennt **Raw Files** (pfad-basierte Rohdateien im Space, per Organisation verschlüsselt) von **Documents** (Dateien, die die Pipeline durchlaufen haben und per Hybrid Search durchsuchbar sind). Ein Upload über `POST /v1/data/upload` befüllt **beide** Layer: die Rohdatei und das durchsuchbare Document. Details und Endpunkte siehe [Dateien und Ordner](/api-reference/Dateien-und-Ordner) sowie [Dokumente und Suche](/api-reference/Dokumente-und-Suche). Es gibt zwei Wege zu löschen, mit unterschiedlicher Wirkung: * `DELETE /v1/data/{id}` entfernt den Knowledge-Base-Record samt Chunks. Das Dokument verschwindet binnen Sekunden aus der Suche; die Rohdatei und die Vektoren im Storage bleiben bestehen. * `DELETE /v1/spaces/{space_id}/data/files` entfernt die Rohdatei physisch — samt Vektoren und abgeleitetem Record. Aus Sicht der Suche verhalten sich beide gleich (das Dokument ist weg). Welcher Pfad der richtige ist, hängt davon ab, ob Sie die Rohdatei behalten wollen. Upload und Reprocessing laufen **asynchron**. Der Status ist über das Feld `processing_state` abfragbar (z. B. via `GET /v1/data/{id}`): Die Flags `parsed`, `chunked` und `embedded` werden nacheinander `true`, abgeschlossen ist die Verarbeitung bei `pipeline_status: "completed"`. Pollen Sie dieses Feld, bevor Sie ein frisch hochgeladenes Dokument durchsuchen. Downloads laufen über eine **Proxy-URL** des Backends — es gibt **keinen** öffentlichen, vorsignierten Link. Ein Download-Aufruf ohne gültigen `Authorization`-Header wird mit `403` abgelehnt (die Inhalte sind pro Organisation verschlüsselt). Mit gültigem Key erhalten Sie `200`. ## Verwandte Seiten Bearer-Token, Scopes und welche Rechte ein API-Key hat. Agenten per `GET /v1/models` und `POST /v1/chat/completions` ansprechen. Upload, Pipeline-Status und Hybrid Search über eigene Dokumente. Raw-File-Storage und die Resource-Ordner unter `/v1/folders`. # OpenAI-kompatibel Source: https://docs.localmind.ai/api-reference/OpenAI-Kompatibel Localmind als Drop-in für OpenAI-SDKs: Agenten auflisten und stateless per Chat Completions ansprechen. Die Localmind API stellt eine **OpenAI-kompatible** Oberfläche bereit. Eine bestehende OpenAI-SDK-Codebasis stellen Sie mit drei Änderungen auf Localmind um: `base_url` auf Ihre Instanz, `api_key` auf Ihren persönlichen API-Key und `model` auf eine **Agent-UUID** statt eines Modellnamens. ```python theme={null} from openai import OpenAI client = OpenAI( base_url="https://-api.localmind.ai/v1", # Host Ihrer Instanz, -api-Suffix beachten api_key="sk-…", ) ``` In Localmind wählt der `model`-Parameter **keinen** Modellnamen wie `gpt-4`, sondern einen **Agent** über dessen UUID. Welches Sprachmodell der Agent nutzt, ist am Agent hinterlegt (**Agent bearbeiten → Modell**); verfügbar sind die dem Space über die Library bereitgestellten Modelle. Die Modell-Aufrufe laufen hinter einem LiteLLM-Proxy. Die UUIDs der für Sie zugänglichen Agenten liefert `GET /v1/models`. ## `GET /v1/models` Listet alle Agenten, auf die Ihr API-Key Zugriff hat (nicht gelöscht, keine System-Agenten), im OpenAI-`/models`-Format. Das Feld `name` spart einen zusätzlichen Lookup; `owned_by` ist die Org-ID. `Bearer sk-…` — Ihr persönlicher API-Key. ```bash cURL theme={null} curl "https://-api.localmind.ai/v1/models" \ -H "Authorization: Bearer sk-…" ``` ```python Python (OpenAI-SDK) theme={null} for m in client.models.list().data: print(m.id, m.name) # id = Agent-UUID, name = Anzeigename ``` ```json 200 OK theme={null} { "object": "list", "data": [ { "id": "{agent_id}", "name": "Bürgerservice Assistent", "object": "model", "created": 1781346834, "owned_by": "{org_id}" } ] } ``` Immer `"list"`. Die zugänglichen Agenten. Jeder Eintrag hat die folgenden Felder. Die **Agent-UUID**. Diesen Wert verwenden Sie als `model` in `POST /v1/chat/completions`. Anzeigename des Agents (nur zur Lesbarkeit, nicht zum Routing). Immer `"model"`. Erstellungszeitpunkt als Unix-Timestamp. Die Organisation, der der Agent gehört (Org-ID). Die Liste ist auf das verengt, was Ihr Key erreicht: Ein Key mit dem Scope „ausgewählte Spaces" zeigt nur Agenten aus diesen Spaces. Wie der Key Rollen und Spaces einschränkt, beschreibt [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## `POST /v1/chat/completions` OpenAI-kompatibler Chat-Endpunkt — **stateless** und **single-shot**: Es gibt keinen serverseitigen Conversation-State. Den bisherigen Verlauf senden Sie bei jedem Aufruf vollständig im `messages`-Array mit. `Bearer sk-…` — Ihr persönlicher API-Key. Die **Agent-UUID** aus `GET /v1/models`. Kein Modellname-Routing. Eine unbekannte UUID liefert `404 {"detail":"Model '…' not found"}`. Die Nachrichten der Konversation. Jede Nachricht hat ein `role` (`system`, `user` oder `assistant`) und ein `content`. Bei `true` wird die Antwort als Server-Sent-Events (SSE) gestreamt. Überschreibt den am Agent hinterlegten Default. Maximale Anzahl generierter Tokens; überschreibt den Agent-Default. Das Alias `max_completion_tokens` wird ebenfalls akzeptiert. JSON-Mode über `{"type": "json_object"}`. Wird via LiteLLM an das Modell durchgereicht — die **strikte Gültigkeit ist modellabhängig** und wird nicht hart erzwungen. Mit `{"include_usage": true}` enthält der Stream am Ende einen zusätzlichen Chunk mit den Usage-Zahlen. Die Parameter `top_p`, `stop`, `presence_penalty`, `frequency_penalty`, `seed`, `n` und `logit_bias` werden **akzeptiert, aber ignoriert** — sie lösen keinen `422`-Fehler aus, haben aber keine Wirkung. ### Hinweise zum Verhalten * **Tools laufen intern.** Ruft der Agent ein Tool auf (z. B. Hybrid Search über seine Wissensquellen), geschieht das serverseitig. Im Response ist `tool_calls` deshalb immer `null` — es gibt keine `function_call`-Ausgabe. * **Kein Conversation-State.** Der Endpunkt persistiert nichts. Für mehrstufige Chats senden Sie den Verlauf im `messages`-Array mit. Siehe auch [Agenten](/api-reference/Agenten). ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/chat/completions" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "model": "{agent_id}", "messages": [ {"role": "user", "content": "Wie beantrage ich einen Reisepass?"} ], "stream": false, "temperature": 0.7, "max_tokens": 2048 }' ``` ```python Python (OpenAI-SDK) theme={null} resp = client.chat.completions.create( model="{agent_id}", # Agent-UUID, kein Modellname messages=[ {"role": "user", "content": "Wie beantrage ich einen Reisepass?"} ], ) print(resp.choices[0].message.content) ``` ```json Request-Body theme={null} { "model": "{agent_id}", "messages": [ {"role": "user", "content": "Wie beantrage ich einen Reisepass?"} ], "stream": false, "temperature": 0.7, "max_tokens": 2048, "response_format": {"type": "json_object"}, "stream_options": {"include_usage": true} } ``` ```json 200 OK theme={null} { "id": "chatcmpl-…", "object": "chat.completion", "created": 1781435623, "model": "{agent_id}", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Einen Reisepass beantragen Sie …", "tool_calls": null, "refusal": null }, "finish_reason": "stop", "logprobs": null } ], "usage": { "prompt_tokens": 3787, "completion_tokens": 6, "total_tokens": 3793 }, "system_fingerprint": null, "service_tier": null } ``` Eindeutige ID der Antwort (`chatcmpl-…`). Immer `"chat.completion"` (nicht-gestreamt). Die angefragte Agent-UUID. Die generierten Antworten. `choices[0].message.content` enthält den Text des Agents; `tool_calls` ist immer `null`; `finish_reason` ist typischerweise `"stop"`. Token-Verbrauch mit `prompt_tokens`, `completion_tokens` und `total_tokens`. ### Streaming Mit `"stream": true` antwortet der Endpunkt als Server-Sent-Events. Jede Zeile beginnt mit `data:` und enthält ein `chat.completion.chunk`-Objekt; der jeweilige Text-Teil steht in `choices[0].delta`. Mit `stream_options.include_usage` folgt am Ende ein Chunk mit den Usage-Zahlen. Den Abschluss markiert die Zeile `data: [DONE]`. ```text Stream (gekürzt) theme={null} data: {"object":"chat.completion.chunk","choices":[{"delta":{"role":"assistant"}}],"usage":null} data: {"object":"chat.completion.chunk","choices":[{"delta":{"content":"Einen "}}],"usage":null} data: {"object":"chat.completion.chunk","choices":[{"delta":{"content":"Reisepass …"}}],"usage":null} data: {"object":"chat.completion.chunk","choices":[{"delta":{}}],"usage":{"prompt_tokens":3787,"completion_tokens":6,"total_tokens":3793}} data: [DONE] ``` ## Fehler ```json 404 — Agent-UUID unbekannt theme={null} { "detail": "Model '{agent_id}' not found" } ``` Eine unbekannte oder nicht zugängliche `model`-UUID liefert `404`. Listen Sie die gültigen Agenten erneut mit `GET /v1/models`. Alle Statuscodes und das Fehlermodell beschreibt [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler). ## Verwandte Seiten Key erstellen, Agenten auflisten und die erste Anfrage senden. Agenten programmatisch finden und ihre vollständige Konfiguration lesen. Fertige Rezepte: OpenAI-Drop-in, RAG, Chatbot, n8n. Wie Ihr Key Rollen erbt, an die Org gebunden ist und den Zugriff verengt. # Quickstart Source: https://docs.localmind.ai/api-reference/Quickstart API-Key erstellen, Agenten auflisten und die erste Chat-Anfrage senden — in wenigen Minuten. In wenigen Minuten haben Sie einen API-Key erstellt, die verfügbaren Agenten Ihrer Instanz aufgelistet und die erste Anfrage an einen Agent gesendet. Die Beispiele nutzen die Base-URL `https://-api.localmind.ai/v1` — ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix). Sie brauchen Zugriff auf eine Localmind-Instanz und mindestens einen Space mit einem konfigurierten Agent. Ihr API-Key kann nie mehr als Ihre eigene Rolle — Schreibzugriff haben Sie zum Beispiel immer in Ihrem [Privaten Space](/api-reference/Authentifizierung-und-Rollen). Öffnen Sie **Benutzereinstellungen → API-Schlüssel** und legen Sie einen neuen Schlüssel an (Admins können Schlüssel auch über **Einstellungen → Sicherheit → API-Schlüssel** ausstellen). Wählen Sie den Scope **„alle Spaces"** oder **„ausgewählte Spaces"**. Der Key gilt nur für Ihre Heim-Organisation und wird **nur einmal** angezeigt — kopieren Sie ihn sofort. ```bash theme={null} # Linux/macOS export LOCALMIND_API_KEY="sk-…" # Windows PowerShell $env:LOCALMIND_API_KEY = "sk-…" ``` Speichern Sie API-Keys nie im Code-Repository. Verwenden Sie Umgebungsvariablen oder ein Secret-Management-Tool. Das vollständige Zugriffsmodell beschreibt [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). `GET /v1/models` liefert alle Agenten, auf die Ihr Key Zugriff hat — im OpenAI-`/models`-Format. Das Feld `id` ist die **Agent-UUID**, die Sie im nächsten Schritt als `model` verwenden; `name` dient nur der Lesbarkeit. ```bash theme={null} curl "https://-api.localmind.ai/v1/models" \ -H "Authorization: Bearer $LOCALMIND_API_KEY" ``` ```json theme={null} { "object": "list", "data": [ { "id": "{agent_id}", "name": "Bürgerservice Assistent", "object": "model", "created": 1781346834, "owned_by": "{org_id}" } ] } ``` Senden Sie eine Chat-Anfrage an `POST /v1/chat/completions`. Setzen Sie `model` auf die **Agent-UUID** aus dem vorigen Schritt — **kein** Modellname wie `gpt-4`. Das Modell, die Tools und die Wissensquellen verwendet der Agent automatisch. ```python Python (OpenAI-SDK) theme={null} import os from openai import OpenAI client = OpenAI( base_url="https://-api.localmind.ai/v1", api_key=os.environ["LOCALMIND_API_KEY"], ) # verfügbare Agenten (nur die, auf die Ihr Key Zugriff hat) for m in client.models.list().data: print(m.id, m.name) resp = client.chat.completions.create( model="{agent_id}", # Agent-UUID, kein Modellname messages=[{"role": "user", "content": "Wie beantrage ich einen Reisepass?"}], ) print(resp.choices[0].message.content) ``` ```bash cURL theme={null} curl -X POST "https://-api.localmind.ai/v1/chat/completions" \ -H "Authorization: Bearer $LOCALMIND_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "{agent_id}", "messages": [ {"role": "user", "content": "Wie beantrage ich einen Reisepass?"} ] }' ``` ```javascript JavaScript (fetch) theme={null} const response = await fetch( "https://-api.localmind.ai/v1/chat/completions", { method: "POST", headers: { Authorization: `Bearer ${process.env.LOCALMIND_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ model: "{agent_id}", // Agent-UUID, kein Modellname messages: [ { role: "user", content: "Wie beantrage ich einen Reisepass?" }, ], }), }, ); const data = await response.json(); console.log(data.choices[0].message.content); ``` ## Die Antwort Die Response folgt dem OpenAI-Chat-Completions-Format. Die Assistent-Antwort liegt in `choices[0].message.content`: ```json theme={null} { "id": "chatcmpl-…", "object": "chat.completion", "created": 1781434980, "model": "{agent_id}", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Einen Reisepass beantragen Sie …", "tool_calls": null, "refusal": null }, "finish_reason": "stop", "logprobs": null } ], "usage": { "prompt_tokens": 3787, "completion_tokens": 6, "total_tokens": 3793 }, "system_fingerprint": null, "service_tier": null } ``` Sie erhalten `HTTP 200` und ein `chat.completion`-Objekt mit der Agent-Antwort in `choices[0].message.content`. Damit ist Ihr Setup vollständig — Sie können jetzt eigene Workflows bauen. Erhalten Sie `404 {"detail":"Model '…' not found"}`, ist die `model`-UUID kein gültiger Agent — listen Sie die Agenten erneut mit `GET /v1/models`. Erhalten Sie `401`, prüfen Sie den `Authorization`-Header. Siehe [Konventionen und Fehler](/api-reference/Konventionen-und-Fehler). ## Nächste Schritte Alle Parameter von `/v1/chat/completions`, Streaming und JSON-Mode. Fertige Rezepte: OpenAI-Drop-in, RAG, Chatbot, n8n, Dokumenten-Organisation. Dokumente hochladen und per Hybrid Search semantisch abfragen. Wie Ihr Key Rollen erbt, an die Org gebunden ist und den Zugriff verengt. # Use Cases Source: https://docs.localmind.ai/api-reference/Use-Cases Praxis-Rezepte für die v1-API: OpenAI-Drop-in, RAG, Chatbot, n8n und Dokumenten-Organisation. Diese Rezepte zeigen, wie die Localmind v1-API real eingesetzt wird. Jedes Beispiel ist eigenständig und verweist auf die passende Referenz-Page. Alle Beispiele nutzen die Base-URL `https://-api.localmind.ai/v1`. Ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix) und authentifizieren Sie jeden Request mit `Authorization: Bearer sk-…`. ## A) OpenAI-Drop-in Stellen Sie eine bestehende OpenAI-Codebasis auf Localmind um, ohne die Logik zu ändern: Sie setzen nur `base_url`, `api_key` und `model` (= Agent-UUID). ```python theme={null} from openai import OpenAI client = OpenAI(base_url="https://-api.localmind.ai/v1", api_key="sk-…") resp = client.chat.completions.create( model="{agent_id}", # Agent-UUID aus GET /v1/models messages=[{"role": "user", "content": "Fasse den Quartalsbericht zusammen."}], ) print(resp.choices[0].message.content) ``` Die verfügbaren Agent-UUIDs finden Sie über `GET /v1/models`. Alle Parameter und das Streaming-Format beschreibt [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel). ## B) RAG über eigene Dokumente Jeder Nutzer ist Owner seines [Privaten Space](/api-reference/Authentifizierung-und-Rollen) und darf dort per Key Dokumente verwalten. Der Ablauf: Space finden, Dokument hochladen, auf die Pipeline warten, semantisch suchen. ```python theme={null} import httpx client = httpx.Client( base_url="https://-api.localmind.ai/v1", headers={"Authorization": "Bearer sk-…"}, ) # 1) Privaten Space finden spaces = client.post("/spaces/search", json={}).json()["items"] space_id = next(s["id"] for s in spaces if s["is_private"]) # 2) Dokument hochladen — die Pipeline läuft automatisch an (parse → chunk → embed) doc = client.post( "/data/upload", data={"space_id": space_id}, files={"file": ("handbuch.pdf", open("handbuch.pdf", "rb"))}, ).json() # 3) Auf Fertigstellung pollen: client.get(f"/data/{doc['id']}") # bis processing_state.pipeline_status == "completed" # 4) Semantisch suchen hits = client.post( "/data/hybrid-search", json={"query": "Wie kündige ich?", "space_id": space_id}, ).json()["results"] for hit in hits: print(hit["score"], hit["document_name"], hit["text"][:80]) ``` Die `hybrid-search`-Treffer kommen mit `score`-Werten sortiert zurück. Den vollständigen Upload-, Polling- und Such-Ablauf — inklusive Response-Feldern und dem Eingrenzen des Suchraums per `document_ids` — beschreibt [Dokumente und Suche](/api-reference/Dokumente-und-Suche). Als Alternative zum direkten `hybrid-search`-Aufruf können Sie einen [Agent](/api-reference/Agenten) mit Daten-Tool ansprechen — dann genügt `POST /v1/chat/completions`, und der Agent zieht die Belege selbst aus seinem Space. ## C) Chatbot und WhatsApp Für Chatbots (z. B. eine WhatsApp-Anbindung) nutzen Sie den **statelessen** Weg über `POST /v1/chat/completions`. Localmind persistiert hier keinen Verlauf — den **Gesprächsverlauf hält Ihr Client** und sendet ihn bei jeder Anfrage vollständig im `messages`-Array mit. ```python theme={null} def antwort(verlauf: list[dict], frage: str) -> str: verlauf.append({"role": "user", "content": frage}) resp = client.chat.completions.create(model="{agent_id}", messages=verlauf) antwort_text = resp.choices[0].message.content verlauf.append({"role": "assistant", "content": antwort_text}) # Verlauf wächst im Client return antwort_text # Pro Nutzer einen eigenen Verlauf halten (z. B. in Ihrem Backend / Cache) verlauf: list[dict] = [] print(antwort(verlauf, "Welche Öffnungszeiten hat das Bürgeramt?")) print(antwort(verlauf, "Und am Samstag?")) # Kontext kommt aus dem mitgesendeten Verlauf ``` In einer WhatsApp-Integration verbinden Sie das eingehende Nachrichten-Webhook mit diesem Aufruf — typischerweise über einen n8n-Workflow (siehe nächstes Rezept). Speichern Sie das `messages`-Array pro Nutzer in Ihrem eigenen Speicher. Mehr zum Request-Aufbau unter [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel). ## D) n8n und Automatisierung In n8n rufen Sie die API über einen **HTTP-Request-Node** auf: Methode `POST`, URL `https://-api.localmind.ai/v1/chat/completions`, Header `Authorization: Bearer sk-…`, Body als JSON. ```json theme={null} { "model": "{agent_id}", "messages": [ { "role": "user", "content": "={{ $json.text }}" } ] } ``` Da `chat/completions` stateless ist, hält der Workflow den Gesprächskontext selbst — etwa indem er das `messages`-Array zwischen den Node-Ausführungen mitführt. So bauen Sie Chatbots, geplante Verarbeitungen oder Event-getriggerte Abläufe. Die Plattform-Sicht auf die n8n-Anbindung beschreibt [Localmind-Agent in Automate](/automate/Localmind-Agent). ## E) Dokumenten-Organisation Strukturieren Sie Dokumente in Ordnern über die Folder-Resource-API. Ordner lassen sich beliebig schachteln; `space_id` ist beim Anlegen Pflicht. ```python theme={null} import httpx client = httpx.Client( base_url="https://-api.localmind.ai/v1", headers={"Authorization": "Bearer sk-…"}, ) # space_id wie in Rezept B über POST /spaces/search ermitteln # Ordner anlegen (Root) folder = client.post( "/folders", json={"name": "Verträge", "space_id": space_id}, ).json() # Unterordner anlegen — space_id ist auch beim Verschachteln Pflicht sub = client.post( "/folders", json={"name": "2026", "parent_folder_id": folder["id"], "space_id": space_id}, ).json() # Inhalte eines Ordners in einem Call browsen contents = client.get(f"/folders/{folder['id']}/contents").json() print(contents["sub_folder_count"], contents["document_count"]) ``` Alle Folder-Endpunkte (Anlegen, Schachteln, Umbenennen, Verschieben, Cascade-Delete) und die Abgrenzung zu pfad-basierten Datei-Ordnern beschreibt [Dateien und Ordner](/api-reference/Dateien-und-Ordner). ## F) Externes System (Formular/DMS/Fachanwendung) anbinden Ein externes Formular-, DMS- oder Fachsystem ruft einen Localmind-Agenten über einen **persönlichen API-Key mit passendem Space-Scope** auf. Der Aufruf ist ein einzelner `POST /v1/chat/completions` gegen `https://-api.localmind.ai/v1` mit `Authorization: Bearer `; als `model` senden Sie die Agent-UUID aus `GET /v1/models`. Der Agent verarbeitet die übergebenen Feld- oder Dokumentinhalte (z. B. Klassifikation, Zusammenfassung, Extraktion) und liefert die Antwort **synchron** zurück — das externe System wartet auf die Response und verarbeitet sie direkt weiter. ```bash theme={null} curl -X POST "https://-api.localmind.ai/v1/chat/completions" \ -H "Authorization: Bearer sk-…" \ -H "Content-Type: application/json" \ -d '{ "model": "{agent_id}", "messages": [ { "role": "user", "content": "Klassifiziere die folgende Anfrage und begründe kurz: …" } ], "response_format": { "type": "json_object" } }' ``` Für strukturierte Rückgaben, die Ihr Fachsystem maschinell weiterverarbeitet, setzen Sie `response_format: { "type": "json_object" }` — der Agent antwortet dann mit einem JSON-Objekt statt Fließtext. `response_format` ist **modellabhängig** — nicht jedes Modell unterstützt den JSON-Mode. Prüfen Sie das Verhalten mit dem Modell, das dem Ziel-Agenten zugewiesen ist, bevor Sie sich in der Integration darauf verlassen. Scopen Sie den Key für solche Integrationen auf **ausgewählte Spaces**: Das externe System erreicht dann nur den Space des Ziel-Agenten — mehr Reichweite braucht es nicht. Verwenden Sie dafür den Key eines **org-eigenen Users**: In Multi-Org-Setups funktioniert der Key eines org-fremden Users nicht, da er nur in dessen Heimat-Org wirkt. Wie Scopes wirken, beschreibt [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## Weiterführend `/v1/models` und `/v1/chat/completions` mit allen Parametern. Upload, Pipeline-Status und Hybrid Search im Detail. Folder-Resource-API und Raw-File-Storage. Agenten per API auflisten und ihre Konfiguration lesen. # API-Einführung Source: https://docs.localmind.ai/api-reference/introduction Überblick über die Localmind v1-API: Agenten programmatisch nutzen, RAG über eigene Dokumente, OpenAI-SDK-Drop-in. Die Localmind v1-API gibt Ihnen programmatischen Zugriff auf die KI-Funktionen Ihrer Localmind-Instanz. Sie sprechen Ihre konfigurierten Agenten direkt an, durchsuchen Ihre eigenen Dokumente per Hybrid Search und automatisieren Abläufe — alles über eine **OpenAI-kompatible** Schnittstelle. ## Was Sie mit der API tun können Senden Sie Anfragen an einen Agent und erhalten Sie dessen Antwort — Tools und Wissensquellen nutzt der Agent dabei serverseitig; die Antwort enthält das Endergebnis. Laden Sie Dokumente in einen Space, lassen Sie die Pipeline sie verarbeiten und durchsuchen Sie sie semantisch per Hybrid Search. Stellen Sie eine bestehende OpenAI-Codebasis auf Localmind um — nur `base_url`, `api_key` und `model` ändern. Rufen Sie die API aus n8n-Workflows oder eigenen Diensten auf, etwa für Chatbots oder geplante Verarbeitungen. ## Plattform-Modell Die API spiegelt die Hierarchie der Localmind-Plattform wider: * **Instance** — die vollständige Localmind-Installation (multi-tenant). * **Organization (Org)** — Tenant-Einheit mit Mitgliedern, Audit-Logs, Library und Billing. Ein API-Key ist immer an **genau eine** Org gebunden. * **Space** — Arbeits- und Berechtigungs-Container. Ein Space enthält **Agents**, **Documents**, **Files**, **Folders** und **Conversations**. Es gibt zwei Space-Typen: Ihr **Privater Space** (jeder Nutzer ist automatisch dessen Owner und darf dort per API alles verwalten) und **Shared Spaces** (geteilt, rollenbasiert). Der Private Space ist der natürliche Ort, um per API eigene Dokumente zu verwalten. Welche Spaces und Agenten ein Key sieht, bestimmt die Rolle seines Besitzers. Ein Key kann den Zugriff nur *verengen*, nie *erweitern*. Details finden Sie unter [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## Zwei Storage-Layer Hochgeladene Dateien existieren in zwei Schichten: als **Files** (pfad-basierte Rohdateien, per-Org verschlüsselt) und als **Documents** (durch die Pipeline verarbeitet — parse, chunk, embed — und damit per Hybrid Search durchsuchbar). Ein Upload über den Daten-Endpunkt befüllt beide Layer gleichzeitig. Die Details und alle Endpunkte beschreibt [Dokumente und Suche](/api-reference/Dokumente-und-Suche). ## Base-URL Jede Localmind-Instanz hat einen eigenen **API-Host** mit `-api`-Suffix. Alle Pfade tragen den **`/v1`**-Prefix: ``` https://-api.localmind.ai/v1 ``` Ersetzen Sie `` durch den Host Ihrer Instanz (beachten Sie das `-api`-Suffix). Es gibt **keinen** geteilten Host `https://api.localmind.ai`. Die API läuft ausschließlich auf der instanz-spezifischen Subdomain mit `-api`-Suffix und `/v1`-Prefix. ## Authentifizierung (Kurzfassung) Authentifizieren Sie jeden Request mit einem persönlichen **User-API-Key** (`sk-…`) im `Authorization`-Header: ```bash theme={null} curl "https://-api.localmind.ai/v1/models" \ -H "Authorization: Bearer sk-…" ``` Den Key erstellen Sie in den **Benutzereinstellungen → API-Schlüssel** (Admins über **Einstellungen → Sicherheit → API-Schlüssel**). Beim Anlegen wählen Sie den Scope „alle Spaces" oder „ausgewählte Spaces". Das vollständige Rollen- und Zugriffsmodell beschreibt [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## OpenAI-Kompatibilität Localmind bietet eine OpenAI-kompatible Oberfläche. Sie listen verfügbare Agenten mit `GET /v1/models` und chatten mit `POST /v1/chat/completions`. Wichtig: Der `model`-Parameter ist immer eine **Agent-UUID** (aus `GET /v1/models`), kein Modellname wie `gpt-4`. ```python theme={null} from openai import OpenAI client = OpenAI(base_url="https://-api.localmind.ai/v1", api_key="sk-…") resp = client.chat.completions.create( model="{agent_id}", # Agent-UUID, kein Modellname messages=[{"role": "user", "content": "Hallo"}], ) print(resp.choices[0].message.content) ``` Mehr dazu unter [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel). ## Nächste Schritte API-Key erstellen, Agenten auflisten und die erste Anfrage senden — in wenigen Minuten. Die Endpunkte `/v1/models` und `/v1/chat/completions` mit allen Parametern und Responses. Dokumente hochladen, die Pipeline verfolgen und per Hybrid Search abfragen. Wie ein API-Key Rollen erbt, an die Org gebunden ist und den Zugriff verengt. # Dokumentenanalyse Source: https://docs.localmind.ai/apps/Document-Analysis Dokumente mit Vorlagen inhaltlich auswerten – seitenweise analysiert und zu einer Synthese zusammengeführt. Mit der Dokumentenanalyse wertest du Dokumente inhaltlich aus: Lass PDFs, Verträge oder Berichte zusammenfassen, Fristen und Risiken identifizieren oder Finanzdaten aufbereiten – über eine spezialisierte Oberfläche, die weit über einen einfachen Chat hinausgeht. Fertige Vorlagen decken die häufigsten Fragestellungen ab. Du findest die App in deinem Space in der Sidebar unterhalb der Standard-Ressourcen als **Analyse**. ## So analysierst du ein Dokument Die App führt dich in vier Schritten durch jede Analyse: Wähle die Analyse-Vorlage, die zu deiner Fragestellung passt (siehe unten). Wähle ein oder mehrere Dokumente aus, die du auswerten möchtest. Ergänze optional eigene Fragestellungen, die zusätzlich zur Vorlage beantwortet werden sollen. Kontrolliere deine Auswahl und starte die Analyse. Die App wertet jede Seite entlang der Vorlage aus und führt die Einzelergebnisse zu einer Synthese zusammen – prüfe das Gesamtergebnis und die Befunde je Seite. ## Analyse-Vorlagen | Vorlage | Fokus | | ------------------------------ | ---------------------------------------------- | | **Management-Zusammenfassung** | Kernaussagen des Dokuments kompakt aufbereitet | | **Fristen & Termine** | Termine und Fristen im Dokument | | **Finanzanalyse** | Beträge, Kennzahlen und finanzielle Angaben | | **Risiken & Probleme** | Risiken und kritische Punkte | | **Vertragsprüfung** | Vertragliche Regelungen und Klauseln | | **Rechtliche Anforderungen** | Rechtliche Vorgaben und Pflichten | ## Seitenweise Analyse und Synthese Die Analyse arbeitet in zwei Stufen: Zuerst wird jede Seite einzeln entlang der Vorlage ausgewertet, anschließend führt die App die Seitenergebnisse zu einer **Synthese** zusammen. So bleibt auch bei langen Dokumenten jede Seite berücksichtigt – und du bekommst trotzdem ein zusammenhängendes Gesamtergebnis. ## Modellwahl Welche Modelle für die Analyse zur Verfügung stehen, hängt davon ab, welche Basismodelle deinem Space über die [Library](/library/overview) bereitgestellt sind – mehr dazu unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). Empfohlen als Analysemodell: **Opus 4.8** oder **Sonnet 5**. Das gewählte Modell muss dem Space über die [Library](/library/overview) provisioniert sein. ## Grenzen: kein API-Zugriff Die Dokumentenanalyse ist eine reine UI-App – sie hat **keinen API-Zugriff**. Wenn du Dokumentanalysen programmatisch brauchst, nutze einen [Agent](/core-functions/agents) mit dem Data-Tool (RAG): Der Agent durchsucht deine Dokumente per [Hybrid Search](/arbeiten-mit-ki/Wissensquellen) und beantwortet Fragen zu den Inhalten – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte Strukturierte Felder aus Dokumenten ziehen – mit Konfidenz, Quellenbeleg und Review. Zwei Dokumente vergleichen – die Unterschiede werden strukturiert gegenübergestellt. Modellkategorien verstehen und das richtige Modell für deinen Anwendungsfall wählen. Dokumente als Wissensquelle für Agents nutzen. # Dokumentenvergleich Source: https://docs.localmind.ai/apps/Document-Comparison Zwei Dokumente vergleichen – die Unterschiede werden strukturiert gegenübergestellt. Mit dem Dokumentenvergleich stellst du zwei Dokumente systematisch gegenüber – zum Beispiel zwei Vertragsversionen, eine alte und eine neue Richtlinie oder zwei Angebotsfassungen. Die App gleicht beide Fassungen inhaltlich mit KI-Unterstützung ab und stellt die Unterschiede strukturiert gegenüber, statt dass du beide Fassungen manuell nebeneinanderlegen musst. Du findest die App in deinem Space in der Sidebar unterhalb der Standard-Ressourcen als **Vergleich**. Der Vergleich arbeitet mit **genau zwei Dokumenten** pro Lauf – nicht mit einem und nicht mit mehreren. ## So vergleichst du zwei Dokumente Wähle das Ausgangsdokument – zum Beispiel die bisherige Vertragsversion. Wähle das Vergleichsdokument – zum Beispiel die neue Fassung. Die App gleicht beide Dokumente inhaltlich ab. Das Ergebnis stellt die Unterschiede zwischen den beiden Fassungen strukturiert gegenüber – so prüfst du gezielt die geänderten Stellen, statt beide Dokumente vollständig zu lesen. ## Grenzen: kein API-Zugriff Der Dokumentenvergleich ist eine reine UI-App – sie hat **keinen API-Zugriff**. Vergleiche führst du direkt in der Oberfläche durch. ## Nächste Schritte Dokumente inhaltlich auswerten – mit Vorlagen wie Management-Zusammenfassung oder Vertragsprüfung. Strukturierte Felder aus Dokumenten ziehen – mit Konfidenz, Quellenbeleg und Review. Dokumente hochladen und als Datenquelle in deinem Space nutzen. # Dokumentenextraktion Source: https://docs.localmind.ai/apps/Document-Extraction Strukturierte Felder aus Dokumenten extrahieren – mit Konfidenz, Quellenbeleg und Human-in-the-Loop-Review. Mit der Dokumentenextraktion ziehst du strukturierte Felder aus Rechnungen, Formularen, Verträgen oder Belegen – zum Beispiel Rechnungsnummer, Betrag und Fälligkeitsdatum. Jeder extrahierte Wert kommt mit einer Konfidenz und einem Quellenbeleg und durchläuft ein **Human-in-the-Loop-Review**: Erst wenn eine Person den Wert bestätigt, gilt er als geprüft. Du findest die App in deinem Space in der Sidebar unterhalb der Standard-Ressourcen als **Extraktion**. ## So funktioniert eine Extraktion Die App führt dich in vier Schritten durch jeden Extraktionslauf: Wähle eine Vorlage mit festen Feldern – sie eignet sich für wiederkehrende Dokumenttypen mit gleichbleibenden Feldern. Alternativ beschreibst du mit einem **benutzerdefinierten Prompt** frei, was extrahiert werden soll. Wähle ein oder mehrere Dokumente aus, aus denen du Daten extrahieren möchtest. Passe die Felder der Vorlage an deine Fragestellung an: Felder ergänzen, entfernen oder ihre Beschreibung präzisieren. Kontrolliere Vorlage, Felder und Dokumentauswahl und starte die Extraktion. Optional läuft sie im Modus **„Seite für Seite"** (siehe unten). Die extrahierten Werte prüfst und bestätigst du anschließend im Review – bis zur Bestätigung steht jedes Feld auf dem Review-Status „pending". ## Modus „Seite für Seite" Neben dem Standard-Lauf gibt es den Modus **„Seite für Seite"** (intern: `unit_by_unit`). Damit verarbeitet die Extraktion dein Dokument seitenweise, statt es als Ganzes zu behandeln. ## Modellwahl je Lauf Unter **Experten-Einstellungen** wählst du das Extraktionsmodell für den jeweiligen Lauf. Welche Modelle zur Auswahl stehen, hängt davon ab, welche Basismodelle deinem Space über die [Library](/library/overview) bereitgestellt sind – mehr dazu unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). Wähle als Extraktionsmodell **Opus 4.8** oder **Sonnet 5**. Das veraltete Opus 4.7 bricht Extraktionen still ab („Keine Ergebnisse") – ein Modell-Artefakt, kein Plattform-Fehler. Das Modell muss dem Space über die [Library](/library/overview) provisioniert sein. ## Output verstehen Der Output je Feld enthält vier Bestandteile: | Bestandteil | Bedeutung | | ------------------------ | ----------------------------------------------------------------- | | **Wert** | Der extrahierte Inhalt des Felds | | **Konfidenz** | Wie sicher sich das Modell ist, angegeben in % | | **Quellenbeleg** („src") | Die Fundstelle im Dokument, aus der der Wert stammt | | **Review-Status** | „pending", bis eine Person den Wert bestätigt – Human-in-the-Loop | Über den Quellenbeleg kannst du beim Review jeden Wert direkt gegen das Original prüfen, statt dem Modell blind zu vertrauen. ## Gescannte Dokumente und Bild-PDFs Das Dokument-Parsing nutzt OCR-Modelle. Damit funktioniert die Extraktion auch für gescannte Dokumente und Bild-PDFs ohne eingebetteten Text. ## Grenzen: kein API-Zugriff Die Dokumentenextraktion ist eine reine UI-App – sie hat **keinen API-Zugriff**. Wenn du strukturierte Extraktion programmatisch brauchst, nutze einen [Agent](/core-functions/agents) mit `response_format: json_object` über die Localmind-API. Rezepte dazu findest du in den [API Use Cases](/api-reference/Use-Cases). ## Nächste Schritte Dokumente inhaltlich auswerten – mit Vorlagen wie Management-Zusammenfassung oder Vertragsprüfung. Zwei Dokumente vergleichen – stellt die Unterschiede strukturiert gegenüber. Modellkategorien verstehen und das richtige Modell für deinen Anwendungsfall wählen. Dokumente hochladen und als Datenquelle in deinem Space nutzen. # Poststelle (Beta) Source: https://docs.localmind.ai/apps/Poststelle Eingehende Post im Space sichten, regelbasiert klassifizieren lassen und Weiterleitungen sowie KI-Antwortentwürfe nach Freigabe versenden. Die Poststelle verbindet Postfächer deiner Organisation per IMAP, holt eingehende Post ab und klassifiziert sie über Regeln. Zu jeder Sendung schlägt sie Aktionen vor — eine Weiterleitung an interne Empfänger, einen KI-Antwortentwurf oder beides. Versendet wird über einen eigenen SMTP-Ausgang, und standardmäßig passiert das nie ohne menschliche Freigabe. Du findest die App in deinem Space in der Sidebar unter **Apps** als **Poststelle**, gekennzeichnet mit dem Badge „BETA". Die Poststelle ist als Beta-Version verfügbar. Details zum Release findest du im [Changelog v1.2.0](/changelog/v1.2.0). ## So arbeitet die Poststelle Jede Sendung durchläuft denselben Weg: 1. **Empfang** — ein verbundener Kanal (Postfach) holt neue Post ab. 2. **Klassifizierung** — die Regeln des Space prüfen die Sendung. Eine Regel entscheidet **fest** (über Bedingungen wie Absender oder Betreff), **KI-gestützt** (über eine Beschreibung in eigenen Worten) oder **kombiniert** (Bedingungen als Vorfilter, danach prüft die KI). 3. **Aktionsplan** — die treffende Regel plant die vorgesehenen Aktionen: Weiterleitung an interne Empfänger und/oder KI-Antwortentwurf. 4. **Freigabe** — eine berechtigte Person prüft den Plan und gibt ihn frei. 5. **Ausführung** — erst danach wird weitergeleitet beziehungsweise versendet. Trifft keine Regel, bleibt die Sendung nicht zugeordnet — du kannst sie dann manuell einer Regel zuweisen oder die Aktionen direkt zusammenstellen. Auch eine spätere Reklassifizierung durchläuft den normalen Freigabepfad; bereits ausgeführte Aktionen werden dabei nie wiederholt. ## Aufbau der App Die Poststelle gliedert sich in vier Tabs: | Tab | Das machst du hier | | ----------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Eingänge** | Eingegangene Post sichten, Aktionspläne freigeben und Entwürfe prüfen — siehe [unten](#eingänge-sichten-und-freigeben). | | **Regeln** | Verteilregeln anlegen und ihre Reihenfolge festlegen. | | **Kanäle** | Postfächer per IMAP verbinden und den SMTP-Versand pro Kanal konfigurieren. | | **Einstellungen** | Modelle, Empfänger, Erstabruf und Aufbewahrung festlegen. | Kanäle, Regeln und die App-Einstellungen richtest du Schritt für Schritt über [Poststelle einrichten](/apps/Poststelle-Einrichten) ein. Lassen sich dabei keine Empfänger anlegen oder auswählen, hilft dir [Poststelle: Keine Empfänger verfügbar](/troubleshooting/Poststelle-Keine-Empfänger-Verfügbar) weiter. ## Eingänge sichten und freigeben Der Tab **Eingänge** listet alle Sendungen mit den Spalten **Absender**, **Betreff**, **Eingegangen**, **Regel** und **Status**; die Liste lässt sich nach dem Eingangszeitpunkt sortieren. Über das Suchfeld („Absender oder Betreff suchen...", Shortcut `/`) filterst du nach Absender oder Betreff, und drei Zähler zeigen dir auf einen Blick, wie viele Sendungen auf eine Aktion warten, gerade bearbeitet werden oder abgeschlossen sind. Neue Post holt die Poststelle automatisch ab; einen manuellen Abruf kannst du jederzeit anstoßen. Solange noch kein Kanal verbunden ist, bleibt die Liste leer: „Noch keine Post — Eingehende Post erscheint hier, sobald ein Kanal eingerichtet ist und Post eingeht." Für den Alltag markierst du mehrere Sendungen und bearbeitest sie gemeinsam: Aktionspläne freigeben, Antwortentwürfe freigeben oder archivieren. Archivieren blendet Sendungen lediglich aus — gelöscht wird nichts, über einen Filter bleiben archivierte Einträge erreichbar. Jede Sendung hat eine Detailansicht mit dem Inhalt, einem chronologischen Protokoll aller Schritte und den Anhängen; Anhänge sind ausschließlich innerhalb der App zugänglich. ## KI-Antwortentwürfe Für Sendungen, die eine Antwort brauchen, kann die KI einen Entwurf vorbereiten. Entwürfe werden immer von einer Person geprüft und erst durch deren explizite Freigabe versendet — die Poststelle antwortet nie von selbst. Für den Entwurf stehen drei Tonlagen zur Auswahl — **Formell**, **Freundlich** und **Knapp** — dazu ein Feld für eine zusätzliche Anweisung an die KI, etwa gewünschte Formulierungen oder inhaltliche Vorgaben. ## Systemgarantien und Sicherheit Die Poststelle ist auf einen Betrieb ausgelegt, bei dem nichts verloren geht und nichts doppelt passiert: * **Keine doppelte Verarbeitung.** Eine Sendung wird nie zweimal aufgenommen — auch nicht durch manuelle Abrufe, Verbindungsabbrüche oder Neustarts. * **Das Quellpostfach bleibt unangetastet.** Die Poststelle verändert nichts auf dem IMAP-Server; Mails werden dort nicht einmal als gelesen markiert. * **Versand exakt einmal.** Weiterleitungen und Antworten gehen genau einmal raus. Schlägt eine Aktion fehl, siehst du den Fehler; ein erneuter Versuch wiederholt ausschließlich die fehlgeschlagene Aktion, nie bereits Versendetes. * **Schutz vor Mail-Schleifen.** Weitergeleitete Mails tragen einen `X-PostOffice`-Header, an dem die Poststelle ihre eigene Post erkennt und nicht erneut verarbeitet. * **HTML nur in der Sandbox.** Eingehende HTML-Mails werden ausschließlich in einer isolierten Sandbox angezeigt; die KI arbeitet mit der Text-Version der Mail. Das mindert das Risiko versteckter Injektionen. * **Begrenzte KI-Wirkung.** Klassifizierung und Entwürfe nutzen ausschließlich Basismodelle ohne Tools. Eine Prompt-Injection in einer Mail kann darum schlimmstenfalls eine Fehlklassifikation verursachen — versendet wird standardmäßig erst nach expliziter Freigabe; nur bei Regeln mit aktiviertem **Automatisch ausführen** entfällt diese Prüfung, Antwortentwürfe erfordern sie immer. Sehr lange Eingaben werden gekürzt. * **Alles nachvollziehbar.** Freigaben, Versand und Änderungen an Regeln, Kanälen oder Einstellungen landen im [Audit-Log](/settings/instance/Audit-Logs); zusätzlich führt jede Sendung ihr eigenes Protokoll. Parsing und KI-Aufrufe der Poststelle werden wie üblich über Credits abgerechnet — den Verbrauch siehst du in der [Nutzungsübersicht](/administration/Nutzungsübersicht). ## Berechtigungen Was du in der Poststelle sehen und tun darfst, steuert deine Space-Rolle über sechs einzeln vergebbare Berechtigungen — vom Lesen der Eingänge über das Freigeben von Einträgen und Entwürfen bis zum Verwalten von Kanälen, Regeln und Einstellungen. Vergeben werden sie von deinem Org Admin; die Details stehen unter [Poststelle (Admin)](/settings/organization/Poststelle). ## Nächste Schritte Kanäle verbinden, Regeln anlegen und die App-Einstellungen konfigurieren — Schritt für Schritt. Empfänger-Domains freigeben, Basismodelle bereitstellen und Space-Berechtigungen steuern. # Poststelle einrichten Source: https://docs.localmind.ai/apps/Poststelle-Einrichten Kanäle verbinden, Regeln anlegen und die App-Einstellungen festlegen — die komplette Einrichtung der Poststelle Schritt für Schritt. Diese Seite führt dich durch die komplette Einrichtung der [Poststelle (Beta)](/apps/Poststelle): von den Vorarbeiten auf Organisationsebene über den ersten Kanal bis zu Regeln, die eingehende Post verteilen. Je nach Schritt brauchst du dafür die Space-Berechtigungen **Kanäle verwalten**, **Regeln verwalten** und **Einstellungen verwalten** — vergeben werden sie über Space-Rollen, siehe [Poststelle (Admin)](/settings/organization/Poststelle). ## Voraussetzungen Zwei Vorarbeiten liegen auf Organisationsebene und brauchen einen **Org Admin**: * **Empfänger-Domains freigeben** — unter **Org-Einstellungen → KI-Konfiguration → Poststelle**. Weiterleitungs-Empfänger dürfen nur E-Mail-Adressen aus freigegebenen Domains verwenden; solange die Liste leer ist, kannst du keine Empfänger anlegen. * **Basismodelle im Space bereitstellen** — über die [Library](/library/overview) (**Zu Spaces hinzufügen**). Ohne provisionierte Basismodelle bleiben die Modell-Auswahlfelder in den App-Einstellungen leer. Beide Schritte beschreibt [Poststelle (Admin)](/settings/organization/Poststelle) im Detail. Kläre sie zuerst — alles Weitere erledigst du selbst in der App. ## Einrichtung im Überblick Die Reihenfolge ist bewusst gewählt: Empfänger setzen die Domain-Freigabe voraus, Regeln setzen Empfänger voraus, und der Erstabruf-Zeitraum muss vor dem Verbinden des Kanals feststehen. Unter **Org-Einstellungen → KI-Konfiguration → Poststelle** gibt dein Org Admin die E-Mail-Domains frei, an die weitergeleitet werden darf. Über die [Library](/library/overview) (**Zu Spaces hinzufügen**) provisioniert dein Org Admin die Modelle, die die Poststelle für Klassifizierung und Antwortentwürfe nutzen soll. Im Tab **Einstellungen** legst du unter [Empfänger](#empfänger) die internen Postfächer an, an die Regeln weiterleiten können. Wähle zuerst den [Erstabruf-Zeitraum](#erstabruf), verbinde dann unter [Kanäle](#kanäle-verbinden) das Postfach und prüfe die Zugangsdaten mit **Verbindung testen**. Lege unter [Regeln](#regeln-anlegen) fest, wie Post klassifiziert und verteilt wird — und lass neue Regeln zunächst mit Freigabe laufen. Erst wenn eine Regel über längere Zeit zuverlässig richtig trifft, stellst du sie auf **Automatisch ausführen** um. ## Kanäle verbinden Im Tab **Kanäle** liegen alle Postfächer, die die Poststelle überwacht. Mit **+ Neuer Kanal** verbindest du das erste: Vergib einen Namen (etwa „Zentraler Posteingang"), trage E-Mail-Adresse und Passwort des Postfachs ein und klicke auf **Verbindung testen**. Die Statusanzeigen **Empfang** und **Versand** stehen anfangs auf „nicht konfiguriert" und zeigen nach dem Test das Ergebnis für beide Richtungen getrennt an. Mit dem Schalter **Aktiv** im Panel-Kopf schaltest du den Kanal ein oder aus, mit **Speichern** legst du ihn an. Wirf vor dem Speichern einen Blick auf den [Erstabruf](#erstabruf) in den App-Einstellungen: Er bestimmt, wie viel vorhandene Post der neue Kanal einmalig lädt, und lässt sich nachträglich nicht wiederholen. ### Erweiterte Verbindungseinstellungen Reichen E-Mail-Adresse und Passwort nicht aus — etwa weil dein Mail-Server eigene Hostnamen oder Ports verwendet —, konfigurierst du Empfang und Versand in den erweiterten Verbindungseinstellungen getrennt. Empfang läuft über IMAP: | Feld | Vorgabe | | ----------------------------- | --------- | | **Host** | – | | **Port** | `993` | | **Benutzername** | – | | **Ordner** | `INBOX` | | **Abrufintervall (Sekunden)** | `60` | | **SSL verwenden** | aktiviert | Versand läuft über SMTP: | Feld | Vorgabe | | ---------------------- | ---------------------------- | | **Host** | – | | **Port** | `587` | | **Benutzername** | IMAP-Benutzername, wenn leer | | **Passwort** | IMAP-Passwort, wenn leer | | **Absendername** | – | | **STARTTLS verwenden** | aktiviert | Lässt du das SMTP-Passwort leer, übernimmt der Kanal das IMAP-Passwort und folgt späteren Passwortänderungen automatisch. Ein eigenes, abweichend gesetztes SMTP-Passwort bleibt dagegen bestehen und wird nie überschrieben. Der Versand nutzt bewusst eigene SMTP-Einstellungen pro Kanal — standardmäßig dasselbe Konto, das auch den Empfang übernimmt. Er ist damit getrennt vom organisationsweiten SMTP-Server, über den etwa Einladungen und Systembenachrichtigungen laufen; deine [E-Mail-Konfiguration (SMTP)](/settings/organization/E-Mail-SMTP) bleibt von der Poststelle unberührt. ### Signatur und Weiterleitungshinweis Pro Kanal legst du zwei Textbausteine fest, beide in einem Rich-Text-Editor mit Grundformatierung (Fett, Kursiv, Unterstrichen, Durchgestrichen, Listen): * Die **Signatur** wird ausgehenden Antworten dieses Kanals automatisch angefügt. * Der **Weiterleitungshinweis** ist der Standardtext, den weitergeleitete Sendungen dieses Kanals mitbekommen; einzelne Regeln können ihn [überschreiben](#dann-welche-aktionen-geplant-werden). Zusätzlich bestimmst du die Position des Hinweises: im Nachrichtentext — dann steht er ganz oben in der Mail, über der weitergeleiteten Nachricht — oder im Betreff. ## Regeln anlegen Im Tab **Regeln** legst du fest, wie eingehende Post klassifiziert wird und was danach passieren soll: „Regeln klassifizieren eingehende Post und planen ihre Aktionen — Weiterleitung an Empfänger oder KI-Antwortentwürfe." Mit **+ Neue Regel** öffnest du den Editor; jede Regel hat einen Namen (etwa „Bauanträge"), optional eine Beschreibung und einen Schalter **Aktiv**. Die Poststelle wertet Regeln strikt in Listen-Reihenfolge aus; die Reihenfolge änderst du per Ziehen. Weil eine treffende Regel die Auswertung standardmäßig beendet (siehe [Erweiterte Einstellungen](#erweiterte-einstellungen)), gehören spezifische Regeln nach oben und allgemeine Auffang-Regeln ans Ende. ### Wenn: Wann eine Regel trifft Der **Wenn**-Block entscheidet, ob eine Sendung zur Regel gehört. Unter „entschieden durch" wählst du einen von drei Typen: **Fest** — die Regel prüft ausschließlich Bedingungen. Eine Bedingung besteht aus einem Feld, einem Operator und einem Vergleichswert, zum Beispiel **Betreff** · **enthält** · „Bauantrag". Innerhalb einer Bedingungsgruppe müssen alle Bedingungen zutreffen (**+ Bedingung hinzufügen (UND)**); mehrere Gruppen sind Alternativen (**+ Bedingungsgruppe hinzufügen (ODER)**) — die Regel trifft, sobald eine Gruppe vollständig passt. | Feld | Worauf sich die Bedingung bezieht | | ------------- | ------------------------------------------- | | **Absender** | Absenderadresse der Sendung | | **Betreff** | Betreffzeile | | **Dateiname** | Dateinamen der Anhänge | | **Quellpfad** | Herkunftspfad der Sendung | | **Inhalt** | Text der Sendung | | **Kanal** | Kanal, über den die Sendung eingegangen ist | Als Operatoren stehen zur Auswahl: **enthält**, **enthält nicht**, **ist gleich**, **ist ungleich**, **beginnt mit**, **beginnt nicht mit**, **endet auf**, **endet nicht auf**, **entspricht Muster** und **entspricht nicht Muster**. Die Bedingung **Inhalt** prüft dabei nicht nur den Mailtext: Auch der aus Anhängen geparste Text zählt dazu. Eine Bedingung auf **Inhalt** · **enthält** · „Bauantrag" trifft also auch, wenn das Wort nur im angehängten Dokument vorkommt. **KI** — du beschreibst in eigenen Worten, welche Post die Regel treffen soll (etwa „Bauanträge von Bürgerinnen und Bürgern"), und legst mit dem Slider **Mindest-Konfidenz** fest, wie sicher sich die KI sein muss (z. B. 85 %). Bleibt die KI unter dieser Schwelle, wird die Sendung der Regel nicht zugeordnet — sie erscheint als nicht zugeordnet in den Eingängen und kann dort manuell zugewiesen werden. **Kombiniert** — die Bedingungen arbeiten als Vorfilter: „Treffen die Bedingungen zu, prüft die KI anschließend:" deine Beschreibung samt Mindest-Konfidenz. Die Regel trifft nur, wenn beide Prüfungen bestehen. Für den Einstieg ist das der robusteste Typ — die Bedingungen halten offensichtlich Unpassendes fern, die KI übernimmt die Feinentscheidung. ### Dann: Welche Aktionen geplant werden Über **+ Aktion hinzufügen** planst du, was mit treffender Post passiert. Zwei Aktionstypen stehen zur Auswahl, eine Regel kann beide enthalten: **Weiterleiten an** — leitet die Sendung an interne Empfänger weiter. Zur Auswahl stehen die Empfänger aus den [App-Einstellungen](#empfänger); eine Weiterleitung kann mehrere Empfänger haben, pro Regel ist aber nur eine Weiterleitungs-Aktion möglich. Optional gibst du einen Weiterleitungshinweis mit — er überschreibt den [Standard des Kanals](#signatur-und-weiterleitungshinweis). **Antwort entwerfen** — die KI bereitet einen Antwortentwurf vor, den eine berechtigte Person prüft und erst durch explizite Freigabe versendet. Du wählst den Ton — **Formell**, **Freundlich** oder **Knapp** — und kannst der KI eine zusätzliche Anweisung mitgeben, etwa gewünschte Formulierungen oder Pflichtangaben. ### Erweiterte Einstellungen Am Ende des Regel-Editors liegen zwei Schalter: **Nach Treffer stoppen** (standardmäßig aktiviert) — trifft die Regel, endet die Auswertung; nachfolgende Regeln werden nicht mehr geprüft. Deaktivierst du den Schalter, laufen auch spätere Regeln, und ihre Aktionen werden demselben Aktionsplan hinzugefügt. Treffen so mehrere Regeln, entsteht ein gemeinsamer Plan — und er wartet als Ganzes auf Freigabe, sobald auch nur eine der beteiligten Regeln Freigabe verlangt. **Automatisch ausführen (ohne Freigabe)** (standardmäßig deaktiviert) — führt die geplanten Aktionen eines Treffers sofort aus, ohne dass jemand freigibt. **Automatisch ausführen** umgeht die Freigabe vollständig — Weiterleitungen gehen dann ohne menschliche Prüfung raus. Lass neue Regeln zunächst mit Freigabe laufen und aktiviere den Schalter erst für Regeln, die sich über längere Zeit bewährt haben. Der Versand von Antwortentwürfen bleibt davon unberührt: Er erfordert immer eine explizite Freigabe. ## App-Einstellungen Der Tab **Einstellungen** bündelt vier Bereiche, die für alle Kanäle und Regeln der App gelten. ### Modelle Zwei getrennte Auswahlfelder bestimmen, mit welchen Modellen die Poststelle arbeitet: das **Klassifizierungsmodell** für die Regel-Auswertung und das **Modell für Antwortentwürfe**. Zur Auswahl stehen ausschließlich die im Space provisionierten Basismodelle — bewusst keine Agenten und keine Tools, damit eine präparierte Mail keine Aktionen auslösen kann; die Hintergründe erläutert [Poststelle (Admin)](/settings/organization/Poststelle). Sind die Auswahlfelder leer, muss dein Org Admin zunächst Basismodelle über die [Library](/library/overview) bereitstellen (**Zu Spaces hinzufügen**). ### Empfänger Empfänger sind die internen Postfächer, an die Regeln und manuelle Aktionen Sendungen weiterleiten können. Du legst sie mit Name und E-Mail-Adresse an (**+ Hinzufügen**); im Regel-Editor wählst du anschließend aus dieser Liste aus. Die Reihenfolge ist entscheidend: Zuerst gibt dein Org Admin die erlaubten E-Mail-Domains frei, dann legst du hier Empfänger an — jede Adresse muss zu einer freigegebenen Domain gehören. Lassen sich keine Empfänger anlegen oder im Regel-Editor auswählen, fehlt fast immer diese Freigabe; siehe [Poststelle: Keine Empfänger verfügbar](/troubleshooting/Poststelle-Keine-Empfänger-Verfügbar). ### Erstabruf Der Erstabruf bestimmt, wie viel vorhandene Post ein neu verbundener Kanal lädt. Unter **E-Mails laden ab** wählst du, ob nur die Post des aktuellen Tages, der letzten 7 Tage (Vorgabe), der letzten 30 Tage oder der letzten 90 Tage geladen wird. Der Erstabruf läuft einmalig pro Kanal und lässt sich nicht wiederholen. Wähle den Zeitraum, bevor du einen Kanal verbindest — nachträglich kannst du ältere Post nicht mehr nachladen. ### Aufbewahrung Mit dem Schalter **Alte Einträge automatisch löschen** und der **Aufbewahrungsfrist (Tage)** (Vorgabe: 30) räumt die Poststelle automatisch auf: Nach Ablauf der Frist wird ein Eintrag vollständig gelöscht — samt Dateien und Protokoll der Sendung. Jede Löschung wird im [Audit-Log](/settings/instance/Audit-Logs) protokolliert. Zwei Dinge überstehen die Löschung: die Audit-Log-Einträge selbst und das interne Gedächtnis, mit dem die Poststelle bereits verarbeitete Post erkennt. Eine Sendung wird also auch dann nicht erneut aufgenommen, wenn ihr Eintrag längst gelöscht ist. ## Nächste Schritte Wie Eingänge, Freigaben und Antwortentwürfe im Alltag funktionieren. Empfänger-Domains, Basismodelle und die sechs Space-Berechtigungen im Detail. # Übersetzung Source: https://docs.localmind.ai/apps/Translation Texte und Dokumente mit DeepL übersetzen – direkt in Localmind. Die Translation App übersetzt Texte und Dokumente mithilfe der DeepL-API. Für die Nutzung ist ein gültiger **DeepL-API-Key** erforderlich, der entweder vom Benutzer selbst oder zentral vom Org Admin bereitgestellt wird. Du findest die App in deinem Space in der Sidebar unterhalb der Standard-Ressourcen als **Übersetzung**. ## DeepL-API-Key einrichten Die Translation App sucht in folgender Reihenfolge nach einem DeepL-API-Key: Gibt es im aktuellen Space ein Credential mit dem exakten Namen `deepl-api-key`? Gibt es auf Organisationsebene ein Credential mit dem exakten Namen `deepl-api-key`? Gibt es eine serverseitige Umgebungsvariable `DEEPL_API_KEY`? Sobald ein Key auf einer Ebene gefunden wird, wird dieser verwendet – die nachfolgenden Ebenen werden nicht mehr geprüft. Ein Space-Credential hat also immer Vorrang vor einem Org-Credential. Die Translation App zeigt dir an, woher der aktuell verwendete DeepL-Key stammt (z.B. „Space Credentials" oder „Org Credentials"). So siehst du jederzeit, welche Konfiguration aktiv ist. ## Key als Benutzer eingeben Wenn kein DeepL-API-Key konfiguriert ist, fordert die App dich direkt zur Eingabe auf: Translation App ohne konfigurierten DeepL-API-Key – Eingabeaufforderung Gib deinen DeepL-API-Key ein und bestätige. Der Key wird automatisch als Credential mit dem Namen `deepl-api-key` im aktuellen Space gespeichert. Dieses Credential kannst du anschließend in den [Org-Einstellungen unter Zugangsdaten](/settings/organization/Zugangsdaten) (Feld „Bereich": dein Space) einsehen, bearbeiten oder löschen. ## Key vom Org Admin bereitstellen lassen Wenn du den DeepL-API-Key nicht selbst verwalten möchtest, kann dein Org Admin einen Key zentral für die gesamte Organisation bereitstellen. In diesem Fall musst du nichts tun – die Translation App verwendet automatisch den Org-Key. Details zur org-weiten Einrichtung findest du unter [Zugangsdaten → DeepL bereitstellen](/settings/organization/Zugangsdaten#deepl-für-die-translation-app-bereitstellen). **Welchen Key verwenden?** Wenn dein Org Admin bereits einen DeepL-Key für die Organisation hinterlegt hat, benötigst du keinen eigenen. Ein Space-Credential ist nur sinnvoll, wenn du einen separaten Key für diesen Space verwenden möchtest (z.B. mit eigenem DeepL-Kontingent). ## Nächste Schritte DeepL-Key als Org Admin zentral bereitstellen und Credentials verwalten. Dokumente inhaltlich auswerten – mit Vorlagen wie Management-Zusammenfassung oder Vertragsprüfung. Strukturierte Felder aus Dokumenten ziehen – mit Konfidenz, Quellenbeleg und Review. Dokumente hochladen und als Datenquelle in deinem Space nutzen. # Transkription Source: https://docs.localmind.ai/apps/transcription Meetings und Audiodateien automatisch transkribieren. **Coming Soon** — Diese App befindet sich aktuell in der Entwicklung und ist noch nicht verfügbar. Mit dieser App wirst du Meetings, Interviews oder Sprachnotizen automatisch transkribieren können. Geplant sind strukturierte Ergebnisse inklusive Sprecherzuordnung und optionaler Aufgabenextraktion. ## Nächste Schritte Dokumente inhaltlich auswerten – mit Vorlagen wie Management-Zusammenfassung oder Vertragsprüfung. Strukturierte Felder aus Dokumenten ziehen – mit Konfidenz, Quellenbeleg und Review. # Best Practices Checkliste Source: https://docs.localmind.ai/arbeiten-mit-ki/Best-Practices-Checkliste Kompakte Referenz mit den 10 goldenen Regeln für optimale KI-Ergebnisse – zum Bookmarken und Nachschlagen. Diese Seite fasst die wichtigsten Erkenntnisse aus allen Bereichen zusammen. Nutze sie als schnelle Referenz vor jeder wichtigen KI-Interaktion. ## Die 10 goldenen Regeln Vage Prompts erzeugen vage Antworten. Definiere Ziel, Format, Länge, Tonfall und Zielgruppe explizit. *Statt:* "Erstelle einen Bericht" → *Besser:* "Erstelle einen detaillierten Bericht mit Executive Summary, drei Hauptabschnitten und konkreten Handlungsempfehlungen im Bullet-Point-Format." Erkläre dem Modell den Hintergrund und die Motivation hinter deiner Anfrage. Je mehr relevanten Kontext du lieferst, desto gezielter und nützlicher wird die Antwort. Erkläre *warum* du etwas brauchst, nicht nur *was*. Gib explizit an, in welcher Form du die Antwort erwartest: Tabelle, Liste, Fließtext, JSON, Markdown. Ohne Formatvorgabe entscheidet das Modell – oft nicht in deinem Sinne. 3–5 diverse, relevante Beispiele deines gewünschten Outputs verbessern die Ergebnisse dramatisch (Few-Shot Prompting). Beispiele reduzieren Fehlinterpretationen und sorgen für konsistente Ergebnisse. Definiere, was das Modell NICHT tun soll. Negative Anweisungen ("Verwende keine Fachbegriffe") sind oft wirksamer als positive ("Schreibe verständlich"). Nicht jede Aufgabe braucht das leistungsstärkste Modell. Einfache Klassifikationen funktionieren mit schnellen Modellen genauso gut – und sind günstiger und schneller. Mehr dazu unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). Reasoning-Modelle "denken nach" bevor sie antworten – ideal für Logik und Analyse, aber unnötig für einfache Zusammenfassungen. Spart Kosten und Zeit. Mehr unter [Reasoning & Thinking](/arbeiten-mit-ki/Reasoning-und-Thinking). KI-Output immer prüfen, besonders bei Zahlen, Zitaten, Rechtstexten und konkreten Faktenbehauptungen. Mehr unter [Halluzinationen vermeiden](/arbeiten-mit-ki/Halluzinationen-Vermeiden). Die erste Antwort ist selten perfekt. Verfeinere: "Erweitere Punkt 3", "Formuliere formeller", "Das war zu allgemein – gib konkrete Zahlen." Nur relevante Informationen einfügen. Mehr Kontext bedeutet nicht automatisch bessere Ergebnisse – oft verschlechtert irrelevanter Kontext die Qualität. Mehr unter [Kontextfenster](/arbeiten-mit-ki/Context-Fenster). ## Allgemeine Prinzipien ### XML-Tags für Struktur verwenden Nutze XML-Tags wie ``, ``, ``, um deine Prompts klar zu strukturieren. Die meisten aktuellen Modelle reagieren besonders gut auf strukturierte Prompts. ### Schrittweises Denken (Chain of Thought) Bei komplexen Aufgaben (Analyse, Recherche, Logik) gib dem Modell explizit den Auftrag, Schritt für Schritt vorzugehen. Nutze strukturierte Tags wie `` und ``, um Denkprozess und Ergebnis zu trennen. ## Hinweise zur aktuellen Modellgeneration Diese Hinweise gelten für die aktuelle Generation (2025/2026) von KI-Modellen aller großen Anbieter. Die spezifische Verhaltensweise kann je nach Provider variieren. | Eigenschaft | Aktuelle Modellgeneration | Ältere Modelle | | -------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------- | | System-Prompt-Sensitivität | Hoch – natürliche Sprache reicht aus | Aggressive Formulierungen oft nötig | | Tool-Triggering | Zuverlässig – weniger Nachdruck nötig | Übertriebene Trigger-Anweisungen oft erforderlich | | Anweisungstreue | Präzise – "vorschlagen" wird wörtlich genommen | Unschärfer bei der Interpretation | | Kontextbewusstsein | Einzelne aktuelle Modelle tracken das verbleibende Kontextfenster aktiv | Weniger Bewusstsein für eigene Grenzen | ### Guardrails & Sicherheit * **Halluzinationen reduzieren:** Fordere das Modell auf, "Ich weiß es nicht" zu sagen, wenn Unsicherheit besteht. Referenziere spezifische Quellen und Dokumente. * **Output-Konsistenz erhöhen:** Nutze Vorlagen und Beispiele für konsistente Ausgabeformate. * **Prompt-Leak verhindern:** Platziere sensible Anweisungen im System-Prompt statt im User-Prompt. Mehr dazu unter [System-Prompts](/arbeiten-mit-ki/System-Prompts). * **Natürliche Sprache verwenden:** Aggressive Formulierungen wie "CRITICAL: YOU MUST..." sind bei aktuellen Modellen kontraproduktiv. Verwende stattdessen klare, natürliche Sprache. ## Anti-Patterns | Anti-Pattern | Besser so | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | "Schreib mir was über Marketing" | "Erstelle einen 500-Wort Blogpost über B2B-Content-Marketing für SaaS-Unternehmen, Ton: professionell, Zielgruppe: CMOs" | | Alles in einen riesigen Prompt packen | Aufgabe in 2–3 Schritte zerlegen ([Prompt Chaining](/arbeiten-mit-ki/Prompt-Techniken)) | | "WICHTIG!!! DU MUSST!!!" | "Bitte achte darauf, dass..." | | Kontext nicht bereinigen | Nur relevante Dokumentausschnitte einfügen | | Ergebnis 1:1 verwenden | Kritisch lesen, prüfen, anpassen | | Denselben Prompt für alles verwenden | Prompts an jeden Anwendungsfall anpassen | | 2000 Wörter Anweisung für eine einfache Aufgabe | Auf das Wesentliche kürzen – jeder Satz muss Mehrwert liefern | ## Checkliste zum Abhaken Prüfe vor jeder wichtigen KI-Interaktion: Ist eindeutig, was du willst? Könnte die Anweisung missverstanden werden? Hat das Modell eine klare Identität und Expertise? Hat das Modell alle Informationen, die es braucht? Weißt du genau, wie die Antwort aussehen soll? Hast du es beschrieben? Würden Beispiele helfen? Bei komplexen oder ungewöhnlichen Aufgaben: ja. Hast du Grenzen gesetzt für Länge, Themen, Tonfall? Passt das Modell zur Aufgabe? Brauchst du Reasoning? Hast du den Output kritisch gelesen und verifiziert? ## Dokumentation und Versionierung Gute Prompts sind Firmenkapital. Dokumentiere und versioniere sie wie Code. Für jeden Produktions-Prompt dokumentieren: | Feld | Beschreibung | | ------------------------ | --------------------------------------- | | Name | Sprechender Bezeichner | | Version | Fortlaufende Nummer | | Zweck | Wofür wird der Prompt verwendet? | | Inputs | Welche Variablen werden erwartet? | | Erwarteter Output | Wie sieht ein gutes Ergebnis aus? | | Getestet mit | Welche Modelle, welche Testfälle? | | Bekannte Einschränkungen | Wann funktioniert der Prompt nicht gut? | ## Weiterführende Ressourcen Die 5 Bausteine eines guten Prompts. Sofort einsatzbereite Prompts. Prompting in der Agent-Konfiguration. # Kontextfenster Source: https://docs.localmind.ai/arbeiten-mit-ki/Context-Fenster Was Tokens und Kontextfenster sind, warum sie wichtig sind und wie du sie optimal nutzt. Das Kontextfenster ist das "Arbeitsgedächtnis" eines KI-Modells. Es bestimmt, wie viel Information das Modell gleichzeitig verarbeiten kann – und ist einer der wichtigsten Faktoren für die Qualität der Ergebnisse. ## Was sind Tokens? Ein Token ist die kleinste Einheit, in der ein KI-Modell Text verarbeitet. Ein Token ist NICHT gleich ein Wort – die Umrechnung variiert je nach Sprache: | Sprache | Durchschnittliche Tokens pro Wort | 1000 Tokens ≈ | | -------- | --------------------------------- | ------------- | | Englisch | \~1,3 Tokens/Wort | \~750 Wörter | | Deutsch | \~1,5 Tokens/Wort | \~650 Wörter | | Code | \~2–3 Tokens/Wort | \~400 Wörter | **Faustregel für Deutsch:** 1 Seite Text ≈ 400–500 Tokens. Ein 50-Seiten-Dokument verbraucht also ca. 20.000–25.000 Tokens. ## Was ist ein Kontextfenster? Das Kontextfenster definiert die maximale Anzahl an Tokens, die ein Modell in einer einzelnen Interaktion verarbeiten kann – **Input (deine Nachricht + System-Prompt + Konversationsverlauf) UND Output (die Antwort) zusammen.** ```text theme={null} Kontextfenster = System-Prompt + Konversationsverlauf + dein Prompt + Dokumente + Antwort des Modells ``` Wenn der gesamte Kontext das Fenster überschreitet, wird älterer Kontext abgeschnitten – oft ohne Warnung. Das kann zu inkonsistenten oder falschen Antworten führen. ### Typische Kontextfenster-Größen | Kategorie | Größe | Entspricht ungefähr | | --------- | ---------------- | ------------------- | | Klein | 4k–8k Tokens | 5–10 Seiten Text | | Mittel | 32k–128k Tokens | 40–160 Seiten Text | | Groß | 200k–500k Tokens | 250–600 Seiten Text | | Sehr groß | 1M–2M+ Tokens | 1.250+ Seiten Text | ## Das "Lost in the Middle" Problem Forschungsergebnisse zeigen: Informationen am **Anfang** und **Ende** des Kontextfensters werden besser verarbeitet als Informationen in der **Mitte**. Das bedeutet: **Wichtige Informationen gehören an den Anfang oder das Ende deines Prompts – nicht in die Mitte.** Bei sehr langen Kontexten kann das Modell Informationen in der Mitte "übersehen". ### Praktische Konsequenzen * **System-Prompt:** Steht immer am Anfang – gut, die wichtigsten Regeln werden zuverlässig befolgt * **Lange Dokumente:** Wenn möglich, die relevantesten Abschnitte am Anfang platzieren * **Konversationsverlauf:** Ältere Nachrichten landen in der "Mitte" und können weniger Einfluss haben ## Kontextfenster effizient nutzen ### Nur relevanten Kontext einfügen Mehr Kontext = nicht automatisch bessere Ergebnisse. Irrelevanter Kontext kann die Qualität sogar verschlechtern: | Ansatz | Beschreibung | Effekt | | ----------------------------------- | ------------------------------------------- | -------------------------------------------------------- | | Ganzes Dokument einfügen | 50-Seiten-Handbuch als Kontext | Schlecht – das Modell muss die Nadel im Heuhaufen finden | | Relevante Abschnitte vorselektieren | Nur die 3 relevanten Kapitel | Gut – fokussierter Kontext, bessere Antworten | | RAG / Hybrid Search nutzen | Automatische Vorauswahl relevanter Passagen | Optimal – skaliert und ist präzise | ### Bei langen Konversationen In langen Chat-Verläufen wächst der Token-Verbrauch mit jeder Nachricht. Strategien: * **Neue Konversation starten:** Wenn das Thema wechselt, starte einen neuen Chat * **Zusammenfassung einfügen:** "Fasse unsere bisherige Diskussion zusammen" – und starte dann einen neuen Chat mit dieser Zusammenfassung als Kontext * **System-Prompt kompakt halten:** Ein langer System-Prompt verbraucht bei JEDER Nachricht Tokens ### Automatische Chat-Zusammenfassung Seit v1.0.0-beta.4 fasst Localmind lange Konversationen automatisch zusammen, sobald du dich dem Kontextlimit des gewählten Modells näherst. Ältere Nachrichten werden im Hintergrund verdichtet, die wesentlichen Fakten und der Gesprächsfaden bleiben erhalten — du chattest weiter, ohne dass der Verlauf abgeschnitten wird. Die Zusammenfassung ersetzt ältere Originalnachrichten im Kontext, nicht in der [Chat History](/navigation/Chat-History). Du kannst jederzeit nach oben scrollen und die Originalnachrichten weiter lesen. Bei einem klaren Themenwechsel ist ein neuer Chat trotzdem oft die bessere Wahl — die automatische Zusammenfassung verdichtet, vermischt aber unter Umständen Themen, die du sauber getrennt halten möchtest. Plane außerdem dein Token-Budget: Bei einem 128k-Kontextfenster und einem 50-Seiten-Dokument (\~25k Tokens) bleiben noch \~100k Tokens für System-Prompt, Konversationsverlauf und Antwort — bei Reasoning-Modellen kann der Denkprozess allein 10–30k Tokens verbrauchen. ## Nächste Schritte Finde das Modell mit dem passenden Kontextfenster. Temperature, Top-P und andere Parameter verstehen. # Halluzinationen vermeiden Source: https://docs.localmind.ai/arbeiten-mit-ki/Halluzinationen-Vermeiden Warum KI-Modelle halluzinieren und wie du mit RAG, System-Prompt-Regeln und Verifikation faktisch korrekte Antworten sicherst. KI-Modelle generieren manchmal plausibel klingende aber faktisch falsche Informationen – sogenannte Halluzinationen. Das Verständnis dieses Phänomens ist entscheidend für den zuverlässigen Einsatz von KI im Unternehmenskontext. ## Was sind Halluzinationen? Falsche Angaben zu überprüfbaren Fakten wie Daten, Namen oder Statistiken. Zitate oder Referenzen, die plausibel klingen, aber nicht existieren. Schlussfolgerungen, die den eigenen Prämissen widersprechen. ## Warum halluzinieren KI-Modelle? Das Modell "lügt" nicht bewusst – es generiert die statistisch wahrscheinlichste Textfortsetzung. Drei Faktoren treiben Halluzinationen: 1. **Trainingsdaten haben Grenzen (Knowledge Cutoff):** Jedes Modell hat einen Wissensstichtag. Alles danach ist dem Modell unbekannt – es kann aber trotzdem plausibel klingende Antworten dazu generieren. 2. **Modelle wissen nicht zuverlässig, was sie nicht wissen:** Durch moderne Trainingsmethoden (Reinforcement Learning) haben neuere Modelle ein rudimentäres Verständnis von Unsicherheit entwickelt. In vielen Fällen generieren sie aber trotzdem selbstbewusst eine Antwort, auch wenn sie keine verlässliche Grundlage haben. 3. **Textgenerierung ist kein Faktenwissen:** Das Modell wurde darauf trainiert, plausibel klingende Texte zu erzeugen – nicht darauf, Wahrheit von Fiktion zu unterscheiden. **Besonders riskant bei:** Zahlen, Zitaten, Datumsangaben, Rechtstexten, technischen Details und wissenschaftlichen Referenzen. ## Gegenmaßnahmen ### RAG einsetzen Die effektivste Methode gegen Halluzinationen ist [RAG (Retrieval-Augmented Generation)](/arbeiten-mit-ki/Wissensquellen). Dabei wird das Modell mit aktuellen, verifizierten Daten aus deiner eigenen Wissensbasis versorgt, bevor es antwortet. Das Modell stützt sich dann auf deine Dokumente statt auf sein Trainingswissen. ### Unsicherheit im System Prompt adressieren Der zuverlässigste Weg, Halluzinationen zu reduzieren, ist eine klare Anweisung im System Prompt: Das Modell soll proaktiv mitteilen, wenn es sich bei einer Aussage unsicher ist. Zum Beispiel: ```text theme={null} Wenn du dir bei einer Aussage nicht sicher bist, weise den Nutzer klar darauf hin. Kennzeichne unsichere Informationen explizit und schlage vor, die Angabe zu verifizieren. ``` Neuere Modelle haben durch Reinforcement Learning ein grundlegendes Verständnis von Unsicherheit entwickelt. Eine entsprechende Instruktion im System Prompt kann dieses Verhalten gezielt aktivieren. ### Temperatur anpassen (nur bei API-Nutzung) In der Web-App wählt Localmind sinnvolle Voreinstellungen – einen Temperature-Regler gibt es dort nicht. Wenn du Agenten über die [OpenAI-kompatible API](/api-reference/OpenAI-Kompatibel) ansprichst, kannst du den `temperature`-Parameter mitgeben: Bei einigen Modellen kann ein niedrigerer Wert (z.B. 0.3) die Faktentreue verbessern, bei anderen ist die Default-Einstellung die beste Option. Details unter [Output-Qualität](/arbeiten-mit-ki/Output-Qualitaet). Das Verhalten bei veränderten Temperature-Einstellungen variiert stark zwischen Modellfamilien. Manche Modelle reagieren auf niedrige Werte mit unbrauchbarem Output oder verweigern die Antwort komplett. Teste Änderungen immer modellspezifisch. ### Fakten immer verifizieren KI-generierte Inhalte sollten IMMER von einem Menschen geprüft werden, bevor sie in Kundenkommunikation, Verträgen, Berichten oder anderen geschäftskritischen Kontexten verwendet werden. Prüfe insbesondere: * Zitierte Quellen (existieren sie wirklich?) * Konkrete Zahlen und Statistiken * Rechtliche Aussagen und Paragraphenverweise * Datumsangaben und historische Fakten ## Nächste Schritte Eigene Dokumente als verifizierte Wissensquelle anbinden. Temperature und andere Parameter für zuverlässigere Ergebnisse. # Output-Qualität optimieren Source: https://docs.localmind.ai/arbeiten-mit-ki/Output-Qualitaet Steuere Temperature, Top-P und Max Tokens für bessere KI-Ausgaben – mit Empfehlungen je Anwendungsfall. Die Qualität der KI-Ausgaben lässt sich über technische Parameter des Modells steuern. Diese Parameter steuerst du bei API-Nutzung – siehe [OpenAI-kompatible API](/api-reference/OpenAI-Kompatibel); in der Web-App wählt Localmind sinnvolle Voreinstellungen. Diese Seite erklärt die wichtigsten Einstellungen und gibt Empfehlungen für verschiedene Anwendungsfälle. ## Die drei wichtigsten Parameter | Parameter | Was er steuert | Bereich | Standard | | --------------- | -------------------------------- | --------------- | -------- | | **Temperature** | Kreativität vs. Vorhersagbarkeit | 0.0 – 2.0 | 0.7–1.0 | | **Top-P** | Breite des Wortschatzes | 0.0 – 1.0 | 0.9–1.0 | | **Max Tokens** | Maximale Länge der Antwort | 1 – Modelllimit | Variiert | Ob `temperature` und `top_p` tatsächlich wirken, ist **modellabhängig**: Localmind reicht die Parameter an das jeweils gewählte Modell durch, aber nicht jedes Modell unterstützt beide. Nicht unterstützte Parameter werden ohne Fehlermeldung ignoriert. Welches Modell du wählst, erfährst du unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). ## Temperature Temperature bestimmt, wie "kreativ" (= unvorhersagbar) das Modell antwortet: | Wert | Verhalten | Geeignet für | | ------------- | ---------------------------------------- | --------------------------------------------------- | | **0.0** | Determiniert – immer die gleiche Antwort | Datenextraktion, Klassifikation, Faktenabfragen | | **0.1 – 0.3** | Niedrig – kaum Variation | Zusammenfassungen, technische Texte, Code | | **0.5 – 0.7** | Mittel – ausgewogen | Allgemeine Texte, E-Mails, Berichte | | **0.8 – 1.2** | Hoch – kreativ und divers | Brainstorming, kreatives Schreiben, Marketing-Texte | | **1.5 – 2.0** | Sehr hoch – unvorhersagbar | Experimentell, oft qualitativ schlechter | **Faustregel:** Für faktenbasierte Aufgaben: Temperature 0–0.3. Für kreative Aufgaben: Temperature 0.7–1.0. Werte über 1.2 sind selten sinnvoll. ## Top-P (Nucleus Sampling) Top-P begrenzt die Auswahl der möglichen nächsten Wörter auf die wahrscheinlichsten, bis die kumulative Wahrscheinlichkeit den Top-P-Wert erreicht: | Wert | Effekt | | ------- | --------------------------------------------------------------- | | **0.1** | Nur die wahrscheinlichsten 10% der Wörter → Sehr fokussiert | | **0.5** | Die wahrscheinlichsten 50% → Guter Mittelweg | | **0.9** | Die wahrscheinlichsten 90% → Breiter Wortschatz, mehr Variation | | **1.0** | Alle Wörter möglich → Maximum an Diversität | Temperature und Top-P beeinflussen ähnliche Aspekte. Empfehlung: **Einen Parameter anpassen, den anderen auf Standard belassen** – nicht beide gleichzeitig. ## Max Tokens Begrenzt die maximale Länge der Antwort: * **Max Tokens ≠ garantierte Länge:** Das Modell kann kürzer antworten * **Zu niedrig:** Die Antwort wird mitten im Satz abgeschnitten * **Zu hoch:** Kein Nachteil, aber unnötig hohe Werte können die Kosten erhöhen * **Empfehlung:** Wert \~20% über der erwarteten Antwortlänge setzen ## Ausgabeformat steuern Die Qualität hängt auch davon ab, wie klar du das gewünschte Format definierst: ```text theme={null} Formatieren Sie die Ausgabe als Markdown-Tabelle mit folgenden Spalten: | Name | Abteilung | Aufgabe | Deadline | Status | ``` ```text theme={null} Antworte ausschließlich in diesem JSON-Format, kein Text davor oder danach: { "zusammenfassung": "string (max. 100 Wörter)", "kernpunkte": ["string"], "empfehlung": "string", "konfidenz": "hoch | mittel | niedrig" } ``` ## Nächste Schritte Strategien für faktisch korrekte Ergebnisse. Das richtige Modell für deinen Anwendungsfall finden. # Prompt-Techniken Source: https://docs.localmind.ai/arbeiten-mit-ki/Prompt-Techniken Acht bewährte Prompt-Techniken von Zero-Shot bis Self-Consistency – mit Beispielen und Einsatzempfehlungen. Mit der richtigen Technik holst du aus demselben Modell deutlich bessere Ergebnisse heraus. Diese Seite stellt acht bewährte Prompt-Techniken vor – vom einfachen Zero-Shot bis zur mehrstufigen Verkettung – und zeigt dir, wann sich welche lohnt. ## 1. Zero-Shot Prompting **Was:** Du gibst dem Modell nur die Anweisung – keine Beispiele. Das Modell arbeitet allein mit der Aufgabenbeschreibung. **Wann:** Einfache, eindeutige Aufgaben. Allgemeine Fragen. Wenn das Ausgabeformat nicht kritisch ist. ```text theme={null} Fassen Sie den folgenden Text in drei Sätzen zusammen: [Ihr Text hier] ``` ## 2. Few-Shot / Multishot Prompting **Was:** Du zeigst dem Modell 2–5 Beispiele des gewünschten Outputs. Das Modell erkennt das Muster und reproduziert es. **Wann:** Spezifische Formatierung erforderlich. Ungewöhnliche Aufgabenstellungen. Konsistente Outputs über mehrere Anfragen. ```text theme={null} Klassifizieren Sie Kundenfeedback als positiv, neutral oder negativ. Beispiel 1: Input: "Das Produkt ist fantastisch, schnelle Lieferung!" Output: positiv Beispiel 2: Input: "Lieferung war okay, Produkt entspricht der Beschreibung." Output: neutral Beispiel 3: Input: "Drei Wochen Wartezeit, dann defekt angekommen." Output: negativ Klassifizieren Sie jetzt: Input: "Preis-Leistung stimmt, würde wieder kaufen." Output: ``` **Regeln für gute Beispiele:** * **Diversität:** Verschiedene Varianten zeigen, nicht nur den einfachen Fall * **Negativbeispiele:** Zeigen, was du NICHT willst * **Realismus:** Beispiele verwenden, die deinem Anwendungsfall ähneln ## 3. Chain of Thought (Schrittweises Denken) **Was:** Das Modell "denkt laut" und arbeitet Schritt für Schritt. Dadurch reduzieren sich Fehler bei komplexen Aufgaben erheblich. **Wann:** Komplexe Analysen, Logikprobleme, Berechnungen, mehrstufige Entscheidungen. Ein Satz am Ende des Prompts reicht: ```text theme={null} Analysieren Sie die beigefügten Verkaufsdaten und identifizieren Sie Trends. Gehen Sie dabei Schritt für Schritt vor. ``` Gib die Schritte explizit vor: ```text theme={null} Analysieren Sie die beigefügten Verkaufsdaten: Schritt 1: Identifizieren Sie die Top-3-Produkte nach Umsatz. Schritt 2: Vergleichen Sie die Quartale und beschreiben Sie den Trend. Schritt 3: Identifizieren Sie Ausreißer oder Anomalien. Schritt 4: Leiten Sie drei Handlungsempfehlungen ab. ``` Trenne Denkprozess und Ergebnis mit Tags: ```text theme={null} Analysieren Sie die beigefügten Verkaufsdaten. Nutzen Sie folgende Struktur: [Hier Ihre Analyse Schritt für Schritt durchführen] [Hier das finale Ergebnis in einer Markdown-Tabelle präsentieren] ``` Einige Modelle reagieren bei deaktiviertem Extended Thinking sensibel auf "think" oder "denken". Verwende Alternativen wie "analysieren", "bewerten" oder "prüfen". ## 4. XML-Tags für Struktur **Was:** XML-Tags schaffen klare Abgrenzungen zwischen den Bestandteilen deines Prompts. Das Modell erkennt sofort, was Kontext ist, was die Aufgabe ist und was das gewünschte Format ist. **Wann:** Umfangreiche Prompts mit viel Kontext. System-Prompts für Agenten. Wenn klare Trennung zwischen Input-Abschnitten nötig ist. ### Gängige Tags | Tag | Zweck | Beispiel | | ----------------- | ------------------------ | ------------------------------------ | | `` | Hintergrundinformationen | Unternehmensdaten, Brancheninfo | | `` | Die eigentliche Aufgabe | "Erstellen Sie eine Zusammenfassung" | | `` | Einschränkungen | Länge, Themen, Tonfall | | `` | Gewünschtes Format | JSON, Tabelle, Fließtext | | `` | Beispiele für den Output | Input-Output-Paare | ```text theme={null} Sie arbeiten für ein mittelständisches IT-Unternehmen (200 Mitarbeiter) in der DACH-Region. Das Unternehmen bietet Cloud-Lösungen für den Gesundheitssektor an. Erstellen Sie einen Entwurf für eine Pressemitteilung über den Launch eines neuen Produkts für die digitale Patientenakte. - Maximale Länge: 400 Wörter - Tonfall: professionell, aber nicht steif - Zielgruppe: IT-Entscheider in Kliniken - DSGVO-Konformität erwähnen ## [Überschrift] ### [Unterüberschrift mit Key Benefit] [Einleitung] → [Hauptteil] → [Zitat] → [Call-to-Action] ``` ## 5. Prompt Chaining (Verkettung) **Was:** Komplexe Aufgaben in Teilschritte zerlegen – der Output von Schritt 1 wird zum Input für Schritt 2. **Wann:** Mehrstufige Prozesse (Recherche → Analyse → Bericht). Wenn du Zwischenergebnisse kontrollieren möchtest. Bei Aufgaben, die zu komplex für einen einzelnen Prompt sind. "Analysieren Sie den Text und identifizieren Sie die drei Hauptthemen." "Basierend auf den identifizierten Themen: Recherchieren Sie zu jedem Thema aktuelle Entwicklungen." "Kombinieren Sie die Analysen zu einem Executive Summary mit Handlungsempfehlungen." Prompt Chaining eignet sich besonders, wenn du die Zwischenergebnisse kontrollieren und ggf. korrigieren möchtest, bevor der nächste Schritt beginnt. ## 6. Persona / Rollenanweisungen **Was:** Dem Modell eine Rolle geben verbessert Fachexpertise und Tonfall der Antworten. Das Modell passt Vokabular, Denkweise und Detailtiefe an die zugewiesene Rolle an. **Wann:** Fachspezifische Aufgaben. Wenn ein bestimmter Tonfall oder eine bestimmte Perspektive gewünscht ist. ```text theme={null} Sie sind ein Senior Software Architect mit 15 Jahren Erfahrung in skalierbaren Cloud-Systemen. Sie priorisieren Wartbarkeit und Sicherheit über schnelle Lösungen. ``` ```text theme={null} Sie sind ein erfahrener Werbetexter, der für sein prägnantes Storytelling bekannt ist. Sie vermeiden Klischees und finden immer einen unerwarteten Blickwinkel. ``` ```text theme={null} Sie sind ein Data Analyst mit Fokus auf Business Intelligence. Sie präsentieren Daten immer mit Kontext und erklären, warum Zahlen relevant sind – nicht nur, was sie zeigen. ``` **Persona mit Einschränkungen kombinieren:** ```text theme={null} Sie sind ein erfahrener Jurist, spezialisiert auf deutsches Vertragsrecht. EINSCHRÄNKUNGEN: - Geben Sie keine definitive Rechtsberatung - Weisen Sie immer darauf hin, dass eine anwaltliche Prüfung notwendig ist - Verwenden Sie verständliche Sprache, erklären Sie Fachbegriffe ``` ## 7. Negative Prompting **Was:** Explizit definieren, was du NICHT willst – oft wirksamer als zu beschreiben, was du willst. **Wann:** Qualitätskontrolle. Wenn das Modell wiederholt unerwünschte Muster zeigt. Zur Stilkontrolle. ```text theme={null} VERMEIDEN: - Keine Floskeln wie "In der heutigen schnelllebigen Welt" - Keine übertriebenen Superlative ("der beste", "einzigartig") - Keine Aufzählungen, wenn Fließtext verlangt ist - Keine Annahmen über nicht genannte Fakten ``` "Schreiben Sie ohne Fachjargon" wirkt stärker als "Schreiben Sie verständlich". ## 8. Self-Consistency Prompting **Was:** Das Modell generiert mehrere Lösungswege und vergleicht sie. Ideal für Entscheidungsfindung und komplexe Fragestellungen. **Wann:** Entscheidungen mit mehreren Optionen. Wenn du verschiedene Perspektiven benötigst. Bei komplexen Fragen ohne eindeutige Antwort. ```text theme={null} Beantworten Sie die Frage auf drei verschiedene Arten: Ansatz 1 (konservativ): [FRAGE] Ansatz 2 (innovativ): [FRAGE] Ansatz 3 (pragmatisch): [FRAGE] Vergleichen Sie dann die Ansätze und empfehlen Sie die beste Option mit Begründung. ``` Verwende für eigene Platzhalter eckige Klammern wie `[FRAGE]`. Die Schreibweise `{{frage}}` ist in Localmind für [Variablen](/navigation/Space-Einstellungen#variablen) reserviert und würde beim Ausführen automatisch ersetzt. ## Techniken im Überblick | Technik | Wann einsetzen | Schwierigkeitsgrad | | ------------------ | ------------------------------------- | ------------------ | | Zero-Shot | Einfache, eindeutige Aufgaben | Einfach | | Few-Shot | Spezifische Formate, Klassifikation | Einfach | | Chain of Thought | Komplexe Analysen, Logikprobleme | Einfach | | XML-Tags | Umfangreiche Prompts mit viel Kontext | Mittel | | Prompt Chaining | Mehrstufige Aufgaben | Mittel | | Persona | Fachspezifische Aufgaben | Einfach | | Negative Prompting | Qualitätskontrolle, Stil | Einfach | | Self-Consistency | Entscheidungen, komplexe Fragen | Fortgeschritten | ## Nächste Schritte Diese Techniken in der Praxis: Fertige System-Prompts zum Kopieren. Strategien für faktisch korrekte Ergebnisse. # Prompt-Templates Source: https://docs.localmind.ai/arbeiten-mit-ki/Prompt-Templates Sofort einsatzbereite Prompts für die häufigsten Anwendungsfälle – kopieren, anpassen, loslegen. Templates sorgen für Konsistenz, sparen Zeit und sichern die Qualität deiner KI-Interaktionen. Diese Sammlung enthält praxiserprobte Prompts, die du direkt in deinen Localmind-Agenten verwenden kannst. Jeder Prompt ist in Englisch verfasst – eine bewährte Konvention für System-Prompts; die Antworten kommen trotzdem in deiner Sprache. ## So verwendest du diese Prompts Navigiere zu **Space → Ressourcen → Agenten → Neuer Agent**. Kopiere den gewünschten Prompt in das **System-Prompt**-Feld. Wähle ein passendes [KI-Modell](/arbeiten-mit-ki/modellauswahl) für deinen Anwendungsfall. Falls der Prompt Dokumente benötigt: Lade diese im Chat hoch, oder weise bei wiederkehrenden Aufgaben einen Ordner über **Agent bearbeiten → Daten → Ordner auswählen** zu. Mehr dazu unter [RAG & Wissensquellen](/arbeiten-mit-ki/Wissensquellen). Passe die Templates an deinen spezifischen Kontext an – ersetze Platzhalter und ergänze branchenspezifische Anforderungen. Mehr zum Aufbau guter Prompts unter [Grundlagen](/arbeiten-mit-ki/Prompting-Grundlagen). ## Die Templates im Überblick | Template | Zweck | Braucht Dokumente? | | ----------------------------- | ------------------------------------------------------- | ------------------ | | Document Summarizer | Prägnante Zusammenfassung beliebiger Dokumente | Ja | | Professional Email Composer | Professionelle E-Mails für jeden Geschäftskontext | Nein | | Knowledge Base Q\&A | Fragen anhand deiner internen Wissensbasis beantworten | Ja (RAG empfohlen) | | Meeting Notes to Action Items | Meeting-Notizen in Protokoll und Aufgaben verwandeln | Nein | | Contract Clause Analyzer | Vertragsklauseln analysieren und Risiken identifizieren | Ja | | Customer Support Agent | Vollständiger Support-Agent mit Troubleshooting-Ablauf | Ja (RAG empfohlen) | ## Die Templates im Detail Erstellt prägnante Zusammenfassungen beliebiger Dokumente mit den wichtigsten Erkenntnissen – als Executive Summary mit Kernpunkten, Details und Action Items. Dieser Prompt benötigt Dokumente. Lade diese im Chat hoch oder richte [RAG über das Daten-Tool](/arbeiten-mit-ki/Wissensquellen) ein. ```text theme={null} You are a document analysis expert. Your task is to create a comprehensive yet concise summary of the provided document(s). INSTRUCTIONS: 1. Read the entire document carefully 2. Identify the main topic, purpose, and key arguments 3. Extract the most important facts, figures, and conclusions 4. Note any action items, recommendations, or deadlines mentioned OUTPUT FORMAT: ## Executive Summary [2-3 sentences capturing the essence] ## Key Points - [Point 1] - [Point 2] - [Point 3] - [Continue as needed] ## Important Details | Category | Information | |----------|-------------| | [e.g., Deadline] | [Value] | | [e.g., Budget] | [Value] | ## Action Items (if any) - [ ] [Action item with responsible party and deadline] RULES: - Be factual and objective - Do not add information not present in the document - If information is unclear, indicate this explicitly - Keep the summary under 500 words unless the document is exceptionally complex ``` Verfasst professionelle E-Mails für jeden Geschäftskontext – von der Betreffzeile bis zum Call-to-Action. ```text theme={null} You are a professional communication specialist. Compose a business email based on the user's requirements. BEFORE WRITING, clarify (if not provided): - Recipient and their relationship to sender - Purpose/goal of the email - Key points to communicate - Desired tone (formal/semi-formal/friendly professional) - Any specific call-to-action needed EMAIL STRUCTURE: 1. Subject line: Clear, specific, action-oriented when appropriate 2. Greeting: Appropriate for the relationship 3. Opening: Context or reference to previous communication 4. Body: Key message with supporting details 5. Call-to-action: What you want the recipient to do 6. Closing: Professional sign-off GUIDELINES: - Keep paragraphs short (2-4 sentences max) - Use bullet points for multiple items - Be direct but courteous - Avoid jargon unless industry-appropriate - Proofread for clarity and tone OUTPUT: **Subject:** [Your subject line] [Complete email body] --- *Alternative subject lines (if requested):* 1. [Option 1] 2. [Option 2] ``` Beantwortet Fragen basierend auf deiner internen Wissensbasis – ideal für HR-Policies, Produktdokumentation oder Unternehmensrichtlinien. Antwortet immer mit Quellenangabe. Dieser Prompt benötigt eine Wissensbasis. Richte [RAG über das Daten-Tool](/arbeiten-mit-ki/Wissensquellen) ein, um Dokumente dauerhaft anzubinden. ```text theme={null} You are a knowledgeable assistant with access to the organization's internal documentation. Answer questions accurately based solely on the provided knowledge base. CRITICAL RULES: 1. ONLY use information from the retrieved documents 2. If the answer is not in the documents, say: "I couldn't find this information in the available documentation. Please contact [relevant department] for assistance." 3. Always cite your sources using [Document Name] format 4. If information might be outdated, mention when the document was last updated (if visible) RESPONSE FORMAT: **Answer:** [Direct answer to the question] **Details:** [Supporting information and context] **Source:** [Document name and relevant section] --- *Related topics you might find helpful:* - [Topic 1] - [Topic 2] TONE: - Helpful and professional - Clear and concise - Never guess or assume information not in the documents ``` Transformiert unstrukturierte Meeting-Notizen in ein klares Protokoll mit Entscheidungen, Aufgaben und Verantwortlichen. ```text theme={null} You are a meeting documentation specialist. Transform raw meeting notes into a structured protocol with clear action items. INPUT: The user will provide meeting notes (can be messy, abbreviated, or in bullet points). OUTPUT STRUCTURE: # Meeting Protocol **Date:** [Extract or ask] **Participants:** [List all mentioned names] **Duration:** [If mentioned] **Meeting Type:** [e.g., Status Update, Planning, Decision Meeting] --- ## Summary [3-5 sentences capturing the key outcomes] ## Topics Discussed ### [Topic 1] - Key points discussed - Decisions made - Open questions ### [Topic 2] [Continue pattern] ## Decisions Made | # | Decision | Rationale | Owner | |---|----------|-----------|-------| | 1 | [Decision] | [Why] | [Who] | ## Action Items | # | Task | Owner | Deadline | Priority | |---|------|-------|----------|----------| | 1 | [Specific task] | [Name] | [Date] | High/Med/Low | ## Open Items / Parking Lot - [Items to address later] ## Next Meeting - **Date:** [If scheduled] - **Agenda items:** [If discussed] --- RULES: - Infer priorities from context (urgent language = High priority) - If deadlines aren't mentioned, mark as "TBD" - Flag any unclear ownership with "[Needs Assignment]" - Keep action items specific and measurable ``` Analysiert Vertragsklauseln und identifiziert potenzielle Risiken oder ungewöhnliche Bedingungen – mit Klausel-für-Klausel-Bewertung und Risiko-Übersicht. Dieser Prompt ersetzt keine rechtliche Beratung. Nutze die Analyse als erste Orientierung und konsultiere bei wichtigen Verträgen immer einen Rechtsexperten. Lade den Vertrag im Chat hoch oder richte [RAG über das Daten-Tool](/arbeiten-mit-ki/Wissensquellen) ein für wiederkehrende Analysen. ```text theme={null} You are a contract analysis assistant. Review the provided contract or contract clause and provide a structured analysis. DISCLAIMER: This analysis is for informational purposes only and does not constitute legal advice. ANALYSIS FRAMEWORK: ## Document Overview - **Contract Type:** [e.g., NDA, Service Agreement, Employment Contract] - **Parties Involved:** [List all parties] - **Effective Date:** [If specified] - **Term/Duration:** [Contract period] ## Clause-by-Clause Analysis ### [Clause Name/Number] | Aspect | Assessment | |--------|------------| | **Summary** | [Plain-language explanation] | | **Standard/Unusual** | [Is this clause typical for this contract type?] | | **Potential Risks** | [Any concerns from your perspective] | | **Negotiation Points** | [Aspects that could be negotiated] | ## Risk Summary | Risk Level | Clause | Concern | |------------|--------|---------| | High | [Clause] | [Issue] | | Medium | [Clause] | [Issue] | | Low | [Clause] | [Issue] | ## Key Dates & Deadlines - [Date 1]: [What happens] - [Date 2]: [What happens] ## Questions to Clarify 1. [Question about ambiguous language] 2. [Question about missing information] ## Recommendations - [Actionable recommendation 1] - [Actionable recommendation 2] --- RULES: - Use plain language, avoid legal jargon where possible - Always note if a clause is unusually one-sided - Highlight any automatic renewal or termination clauses - Flag unusual liability or indemnification provisions - Note any jurisdiction or governing law clauses ``` Ein vollständiger System-Prompt für einen Kundensupport-Agenten mit Troubleshooting-Ablauf. Dieses Template ist die englische Version des Praxisbeispiels unter [System-Prompts](/arbeiten-mit-ki/System-Prompts#praxisbeispiel-kundensupport-agent). Binde deine Support-Dokumentation über [RAG (Daten-Tool)](/arbeiten-mit-ki/Wissensquellen) an, damit der Agent auf aktuelle Anleitungen und FAQs zugreifen kann. ```text theme={null} IDENTITY: You are the customer support assistant for [Company Name]. You help customers with technical questions about the platform, troubleshooting, and general inquiries. COMMUNICATION STYLE: - Professional, friendly, and patient - Technically accurate but understandable for non-technical users - Always solution-oriented: if you cannot solve the problem, suggest next steps RULES: - ONLY answer questions related to [Company Name] and related topics - Do not reveal internal information (architecture, infrastructure) - If you don't know the answer, say: "I cannot provide a reliable answer on this. Please contact our support team at [support email]" - Never confirm bugs before the customer provides a screenshot or exact reproduction steps TROUBLESHOOTING FLOW: 1. Understand the problem: Ask for exact steps to reproduce 2. Clarify environment: Browser, operating system, network (VPN?) 3. Suggest known solution (check FAQ/knowledge base) 4. If unsolvable: Recommend creating a support ticket OUTPUT FORMAT: - Brief summary of the problem - Solution steps (numbered) - If relevant: Link to documentation ``` ## Nächste Schritte Die Bausteine eines guten Prompts und wie du System-Prompts strukturierst. Strategien für faktisch korrekte Outputs. # Prompting-Grundlagen Source: https://docs.localmind.ai/arbeiten-mit-ki/Prompting-Grundlagen Was ein Prompt ist, wie er aufgebaut ist, und wie du System-Prompts für deine Agenten erstellst. Die Qualität deiner Prompts bestimmt direkt die Qualität der Antworten. Ein gut strukturierter Prompt kann den Unterschied zwischen einer generischen und einer präzisen, nützlichen Antwort ausmachen. ## Was ist ein Prompt? Ein Prompt ist die Eingabe, die du einem KI-Modell gibst. Er kann aus einer einfachen Frage, einer komplexen Anweisung oder einer Kombination aus Kontext, Beispielen und Aufgabenbeschreibung bestehen. Denke an Prompting wie an die Kommunikation mit einem extrem fähigen, aber wörtlich nehmenden Assistenten. Je klarer und präziser deine Anweisung, desto besser das Ergebnis. ## System-Prompt vs. User-Prompt In Localmind gibt es zwei Arten von Prompts: Der **System-Prompt** ist die dauerhafte Konfiguration eines Agenten – er definiert Rolle, Regeln und Ausgabeformat und bleibt über alle Nachrichten aktiv. Der **User-Prompt** ist deine konkrete Nachricht im Chat und gilt nur für diese eine Eingabe. Aufbau, Praxisbeispiele und häufige Fehler findest du unter [System-Prompts](/arbeiten-mit-ki/System-Prompts). ## Die 5 Bausteine eines guten Prompts Jeder effektive Prompt besteht aus bis zu fünf Bausteinen: Wer soll das Modell sein? Gib dem Modell eine klare Identität und die nötigen Hintergrundinformationen. *Beispiel:* "Sie sind ein erfahrener Finanzanalyst mit Expertise in europäischen Märkten." Was genau soll getan werden? Formuliere die Aufgabe explizit und spezifisch. *Beispiel:* "Analysieren Sie die beigefügten Quartalszahlen und identifizieren Sie die drei wichtigsten Risikofaktoren." In welcher Form soll die Antwort kommen? Listen, Tabellen, Fließtext, JSON. *Beispiel:* "Präsentieren Sie die Ergebnisse als nummerierte Liste mit jeweils max. 50 Wörtern pro Punkt." Was soll NICHT passieren? Setze klare Grenzen für Thema, Länge, Tonfall und Inhalt. *Beispiel:* "Fokussieren Sie sich auf finanzielle Risiken, nicht auf operative Herausforderungen." Wie sieht guter Output aus? 3–5 diverse Beispiele reduzieren Fehlinterpretationen drastisch ([Few-Shot Prompting](/arbeiten-mit-ki/Prompt-Techniken)). ### Alle Bausteine kombiniert ```text theme={null} [Rolle/Kontext] Sie sind ein erfahrener Finanzanalyst. [Aufgabe] Analysieren Sie die beigefügten Quartalszahlen und identifizieren Sie die drei wichtigsten Risikofaktoren. [Format] Präsentieren Sie die Ergebnisse als nummerierte Liste mit jeweils einer kurzen Erklärung (max. 50 Wörter pro Punkt). [Einschränkungen] Fokussieren Sie sich auf finanzielle Risiken, nicht auf operative Herausforderungen. [Beispiele] 1. Währungsrisiko – Die EUR/USD-Schwankung von 8% im Q3 gefährdet die Margen im US-Geschäft, das 40% des Umsatzes ausmacht. ``` ## Schwacher Prompt vs. Starker Prompt **Schwach:** ```text theme={null} Schreib eine E-Mail an einen Kunden. ``` **Stark:** ```text theme={null} Verfassen Sie eine professionelle E-Mail an einen B2B-Kunden (Geschäftsführer, mittelständisches Unternehmen), der sein Vertragsverlängerungsangebot noch nicht beantwortet hat. Ton: höflich aber bestimmt. Ziel: Termin für ein 15-Minuten-Gespräch vereinbaren. Max. 150 Wörter. ``` **Schwach:** ```text theme={null} Fasse das Dokument zusammen. ``` **Stark:** ```text theme={null} Erstellen Sie eine Executive Summary des beigefügten Quartalsberichts. Struktur: 1) Kernaussage (2 Sätze), 2) Top-3-Kennzahlen als Tabelle, 3) Handlungsempfehlungen als Bullet Points. Zielgruppe: Vorstand ohne Finanz-Hintergrund. Max. 300 Wörter. ``` **Schwach:** ```text theme={null} Analysiere diese Daten. ``` **Stark:** ```text theme={null} Analysieren Sie die beigefügten Verkaufsdaten der letzten 12 Monate. Identifizieren Sie: 1) Saisonale Muster, 2) Die drei umsatzstärksten Produktkategorien, 3) Auffällige Ausreißer. Präsentieren Sie die Ergebnisse mit konkreten Zahlen in einer Markdown-Tabelle. ``` ## Iteratives Verfeinern Die erste Antwort ist selten perfekt. Verfeinere schrittweise: | Runde | Aktion | Ergebnis | | ------------ | -------------------------------------------------------- | ------------------------------ | | 1 | "Fasse den Quartalsbericht zusammen" | Zu allgemein, keine Zahlen | | 2 | "Ergänze konkrete Umsatzzahlen und Prozentwerte" | Besser, aber falsches Format | | 3 | "Formatiere als Tabelle: Metrik / Q3 / Q4 / Veränderung" | Perfekt | | **Template** | Originalanfrage + "mit konkreten Zahlen, als Tabelle" | Direkt beim ersten Versuch gut | KI-Modelle sind hervorragende Prompt-Experten. Verwende sie zum Formulieren und Formatieren neuer System-Prompts – oder klicke im System-Prompt-Editor deines Agenten direkt auf **Prompt verbessern**. ## Nächste Schritte Zero-Shot, Few-Shot, Chain of Thought, Prompt Chaining und mehr. Sofort einsatzbereite Prompts für häufige Aufgaben. # Reasoning & Thinking Source: https://docs.localmind.ai/arbeiten-mit-ki/Reasoning-und-Thinking Wie Reasoning-Modelle Schritt für Schritt denken, wann sich Extended Thinking lohnt und wie du Reasoning in Localmind aktivierst. Reasoning-Modelle "denken nach" bevor sie antworten. Statt sofort die wahrscheinlichste Textfortsetzung zu generieren, zerlegen sie das Problem in Schritte und arbeiten sich systematisch zur Lösung vor. Das verbessert die Ergebnisse bei komplexen Aufgaben erheblich – kostet aber mehr Zeit und Geld. ## Was ist Extended Thinking? Extended Thinking ist eine Funktion bestimmter Modelle, die den internen Denkprozess vor der eigentlichen Antwort explizit aktiviert. Das Modell: 1. **Analysiert** die Aufgabe und identifiziert Teilprobleme 2. **Entwickelt** einen Lösungsansatz 3. **Prüft** Zwischenergebnisse auf Plausibilität 4. **Korrigiert** sich bei Widersprüchen 5. **Formuliert** erst dann die finale Antwort Der "Denkprozess" verbraucht Tokens und damit Rechenressourcen. Ein 50-Token-Prompt kann leicht 2000+ Tokens an Denkschritten erzeugen, bevor die eigentliche Antwort beginnt. ## Wann Reasoning einsetzen? | Aufgabentyp | Reasoning sinnvoll? | Begründung | | --------------------------- | ------------------- | ---------------------------------------------------- | | Mathematische Probleme | Ja | Schritt-für-Schritt-Rechnung reduziert Fehler | | Logische Schlussfolgerungen | Ja | Prämissen-Verkettung erfordert bewusstes Denken | | Code-Debugging | Ja | Systematisches Durchgehen des Programmflusses | | Strategieplanung | Ja | Abwägen von Optionen und Konsequenzen | | Zusammenfassungen | Nein | Standard-Modelle reichen aus | | Übersetzungen | Nein | Intuitives System 1 reicht | | E-Mail-Entwürfe | Nein | Kreativität braucht kein "Nachdenken" | | Klassifikation | Selten | Nur bei mehrdeutigen oder komplexen Fällen | | Datenextraktion | Selten | Nur bei verschachtelten oder widersprüchlichen Daten | **Faustregel:** Wenn du als Mensch bei der Aufgabe einen Zettel und Stift bräuchtest, um es Schritt für Schritt durchzuarbeiten – dann profitiert die Aufgabe von Reasoning. ## Reasoning in Localmind aktivieren In Localmind kannst du Reasoning für einen Agenten aktivieren: Navigiere zu **Space → Ressourcen → Agenten** und öffne den gewünschten Agenten. Wähle ein Modell, das Reasoning unterstützt. Welche Modelle das sind, hängt von der [Modellauswahl deiner Organisation](/arbeiten-mit-ki/modellauswahl) und der Konfiguration durch deinen Administrator ab. Aktiviere den Toggle **Reasoning** unter **Erweitert** in den Agent-Einstellungen. Der Toggle **Reasoning** ist nur sichtbar, wenn ein reasoning-fähiges Modell ausgewählt ist. ## Grenzen von Reasoning Auch Reasoning-Modelle haben Limitierungen: * **Keine Garantie für Korrektheit:** Der Denkprozess kann von falschen Prämissen ausgehen und trotzdem logisch erscheinen * **Höhere Kosten:** 3–10x höherer Token-Verbrauch durch den internen Denkprozess * **Längere Antwortzeiten:** Sekunden bis Minuten statt Millisekunden * **Nicht immer besser:** Für kreative und sprachlich-intuitive Aufgaben sind Standard-Modelle oft gleichwertig oder besser * **Halluzinationen möglich:** Auch Reasoning-Modelle können falsche Fakten "logisch herleiten" ## Nächste Schritte Tokens, Kontextfenster und wie du sie optimal nutzt. Das richtige Modell für deinen Anwendungsfall finden. # System-Prompts Source: https://docs.localmind.ai/arbeiten-mit-ki/System-Prompts System-Prompts konfigurieren dein KI-Modell dauerhaft – lerne die Unterschiede zum User-Prompt und Best Practices für die Agent-Konfiguration. Ein System-Prompt ist die dauerhafte Konfiguration eines KI-Agenten – er definiert Rolle, Verhalten, Grenzen und Ausgabeformat für alle Interaktionen. Im Gegensatz zum User-Prompt (die Nachricht, die du im Chat eingibst) bleibt der System-Prompt über die gesamte Konversation hinweg aktiv. ## System-Prompt vs. User-Prompt | Eigenschaft | System-Prompt | User-Prompt | | --------------------- | -------------------------------------- | --------------------------------- | | **Wo** | Agent-Konfiguration (einmalig) | Chat-Eingabe (pro Nachricht) | | **Sichtbar für User** | Nein (im Hintergrund) | Ja (ist die Nachricht selbst) | | **Persistenz** | Bleibt über alle Nachrichten aktiv | Gilt nur für diese eine Nachricht | | **Inhalt** | Rolle, Regeln, Format, Einschränkungen | Konkrete Aufgabe oder Frage | | **Wer erstellt ihn** | Administrator / Agent-Ersteller | Endbenutzer | **Metapher:** Der System-Prompt ist das Stellenprofil und die Betriebsanleitung für deinen KI-Mitarbeiter. Der User-Prompt ist die konkrete Aufgabe, die du ihm gibst. ## Aufbau eines guten System-Prompts Ein vollständiger System-Prompt enthält vier Bereiche: Wer ist der Agent? Welche Expertise hat er? Wie soll er kommunizieren? ```text theme={null} Sie sind ein erfahrener HR-Assistent für die Firma Localmind. Sie beantworten Fragen zu internen Richtlinien, Urlaubsansprüchen und Onboarding-Prozessen in einem professionellen, aber freundlichen Ton. ``` Was darf der Agent? Was darf er auf keinen Fall? ```text theme={null} REGELN: - Beantworten Sie ausschließlich Fragen zu HR-Themen - Erfinden Sie keine Richtlinien – wenn unsicher, verweisen Sie auf die HR-Abteilung - Geben Sie keine Gehalts- oder Personaldaten preis - Bei rechtlichen Fragen immer auf professionelle Beratung verweisen ``` Worauf basieren die Antworten? ```text theme={null} WISSENSQUELLEN: - Nutzen Sie ausschließlich die bereitgestellten HR-Dokumente - Zitieren Sie das Quelldokument bei jeder Antwort - Wenn keine Quelle verfügbar, sagen Sie: "Dazu liegen mir keine internen Richtlinien vor." ``` Wie soll die Antwort aussehen? ```text theme={null} AUSGABEFORMAT: - Beginnen Sie mit einer kurzen, direkten Antwort (max. 2 Sätze) - Dann ausführlichere Details, wenn relevant - Nennen Sie am Ende die Quelle: [Dokument, Abschnitt] - Bei mehrstufigen Prozessen: Nummerierte Schrittliste verwenden ``` ## Praxisbeispiel: Kundensupport-Agent Hier ein vollständiger System-Prompt für einen Kundensupport-Agenten: ```text theme={null} IDENTITÄT: Sie sind der Kundensupport-Assistent für Localmind. Sie helfen Kunden bei technischen Fragen zur Plattform, bei der Fehlerbehebung und bei allgemeinen Anfragen. KOMMUNIKATIONSSTIL: - Professionell, freundlich und geduldig - Technisch korrekt, aber verständlich für Nicht-Techniker - Immer lösungsorientiert: Wenn Sie das Problem nicht lösen können, schlagen Sie nächste Schritte vor REGELN: - Beantworten Sie NUR Fragen zu Localmind und verwandten Themen - Geben Sie keine internen Informationen preis (Architektur, Infrastruktur) - Wenn Sie die Antwort nicht wissen, sagen Sie: "Dazu kann ich Ihnen leider keine verlässliche Auskunft geben. Bitte kontaktieren Sie unser Support-Team unter support@localmind.ai" - Bestätigen Sie niemals Bugs, bevor der Kunde einen Screenshot oder eine genaue Beschreibung geliefert hat TROUBLESHOOTING-ABLAUF: 1. Problem verstehen: Fragen Sie nach genauen Schritten zur Reproduktion 2. Umgebung klären: Browser, Betriebssystem, ggf. Netzwerk (VPN?) 3. Bekannte Lösung vorschlagen (FAQ/Wissensbasis prüfen) 4. Wenn nicht lösbar: Ticket-Erstellung empfehlen AUSGABEFORMAT: - Kurze Zusammenfassung des Problems - Lösungsschritte (nummeriert) - Falls relevant: Verweis auf Dokumentation ``` ## System-Prompt-Verhalten nach Modellgeneration Wie sensibel ein Modell auf System-Prompts reagiert, variiert: * **Hohe System-Prompt-Treue:** Anweisungen werden genauer befolgt * **Natürliche Sprache ausreichend:** Keine aggressiven Formulierungen nötig * **Weniger Workarounds:** "CRITICAL: YOU MUST..." ist unnötig und kann kontraproduktiv sein * **Empfehlung:** Schreibe den System-Prompt wie eine klare Arbeitsanweisung an einen Menschen * **Geringere Treue:** Anweisungen werden manchmal ignoriert * **Stärkere Formulierungen nötig:** Wiederholung wichtiger Regeln hilft * **Tool-Trigger:** Tools müssen expliziter angesteuert werden * **Empfehlung:** Wichtige Regeln wiederholen und mit Beispielen untermauern ## So erstellst du einen System-Prompt in Localmind Navigiere in den gewünschten **Space**. Gehe zu **Ressourcen → Agenten**. Klicke auf **Neuer Agent** oder öffne einen bestehenden Agenten mit **Agent bearbeiten**. Füge deinen System-Prompt in das **System-Prompt**-Feld ein. Mit **Prompt verbessern** optimierst du ihn direkt im Editor – z.B. durch klarere Rollenanweisungen. Das Zeichenlimit des Feldes konfiguriert dein Admin unter [Org-Einstellungen → KI-Konfiguration → Agenten](/settings/organization/Agenten). Teste den Agenten im Chat mit verschiedenen Anfragen – auch mit Randfällen, die deine Regeln testen. ## Häufige Fehler Ein System-Prompt mit 3000 Wörtern verwirrt das Modell mehr als er hilft. Halte ihn unter 500 Wörtern und priorisiere die wichtigsten Regeln. "Sei kreativ" + "Halte dich strikt an die Vorlage" – das Modell kann beides nicht gleichzeitig. Priorisiere. Was soll der Agent tun, wenn er eine Frage nicht beantworten kann? Definiere immer eine "Ich weiß es nicht"-Regel. Sensible Anweisungen (z.B. interne Richtlinien, Geschäftsregeln) gehören in den System-Prompt – dieser ist für Endbenutzer nicht sichtbar. ## Nächste Schritte Agenten in Localmind konfigurieren und bereitstellen. Fertige System-Prompts für häufige Anwendungsfälle. # Wissensquellen Source: https://docs.localmind.ai/arbeiten-mit-ki/Wissensquellen Wie du KI-Agenten mit deinen eigenen Dokumenten versorgst – von Chat-Upload bis Hybrid Search in Localmind. KI-Modelle haben kein eigenes Wissen über dein Unternehmen, deine Produkte oder deine internen Prozesse. Du kannst ihnen aber gezielt Wissen bereitstellen – durch Dokumente, die dem Modell als Kontext mitgegeben werden. Die dafür eingesetzte Technologie heißt **RAG (Retrieval-Augmented Generation)**. Die Idee: Statt sich auf das Trainingswissen des Modells zu verlassen, werden relevante Dokumente automatisch gesucht und dem Modell mitgegeben, bevor es antwortet. **Analogie:** Ein Modell ohne Wissensquelle ist wie ein Mitarbeiter, der alles aus dem Gedächtnis beantworten muss. Ein Modell mit Wissensquelle ist wie ein Mitarbeiter, der vor der Antwort die passende Akte aus dem Archiv holt. ## Wie funktioniert RAG? Du stellst deine Frage im Chat – z.B. "Was ist unsere Urlaubsregelung für Teilzeitkräfte?" Das System durchsucht automatisch die angebundenen Dokumente und findet die relevantesten Passagen (z.B. aus dem HR-Handbuch). Die gefundenen Textpassagen werden zusammen mit deiner Frage an das KI-Modell gesendet. Das Modell antwortet basierend auf den bereitgestellten Dokumenten – nicht aus dem Gedächtnis, sondern mit Quellenangabe. ## Warum reduziert RAG Halluzinationen? Ohne RAG muss das Modell auf sein Trainingswissen zurückgreifen – dabei kann es plausibel klingende aber falsche Informationen generieren ([Halluzinationen](/arbeiten-mit-ki/Halluzinationen-Vermeiden)). Mit RAG: * Das Modell antwortet auf Basis **deiner verifizierten Dokumente**, nicht aus dem Gedächtnis * Quellen können **zitiert und überprüft** werden * Fragen außerhalb der Wissensbasis können erkannt werden ("Dazu liegen mir keine Informationen vor") RAG reduziert Halluzinationen erheblich, eliminiert sie aber nicht vollständig. Das Modell kann Passagen falsch interpretieren oder irrelevante Dokumente heranziehen. Prüfe kritische Antworten immer. ## RAG in Localmind einrichten In Localmind nutzt du das Werkzeug **Daten**, um Agenten mit Dokumenten zu verbinden – es führt die Hybrid Search aus: Erstelle in deinem Space einen Ordner und lade die relevanten Dokumente hoch (PDF, DOCX, TXT, etc.). Navigiere zu **Space → Ressourcen → Agenten** und öffne oder erstelle einen Agenten. Klicke auf **Agent bearbeiten**, aktiviere das Werkzeug **Daten** (es führt die Hybrid Search aus) und wähle den Ordner mit deinen Dokumenten aus. Stelle dem Agenten Fragen zu deinen Dokumenten und prüfe, ob die Antworten korrekt und mit Quellenangaben versehen sind. Aktiviere **Zitate anzeigen** in den Agent-Einstellungen, damit der Agent bei jeder Antwort die genutzten Quellen anzeigt. Das erleichtert die Überprüfung. ## Wann RAG vs. Chat-Upload? | | Chat-Upload | RAG (Hybrid Search) | | --------------------- | ------------------------------------- | ------------------------------------------------- | | **Geeignet für** | Einzelne Dokumente, einmalige Analyse | Wiederkehrende Fragen an eine Wissensbasis | | **Dokumente** | 1–3 Dateien direkt im Chat hochladen | Beliebig viele Dateien in einem Ordner | | **Persistenz** | Nur für diese eine Konversation | Dauerhaft für alle Konversationen mit dem Agenten | | **Einrichtung** | Keine – einfach hochladen | Ordner erstellen + Daten-Tool zuweisen | | **Typischer Einsatz** | "Fasse dieses PDF zusammen" | "HR-Bot für alle Mitarbeiter-Fragen" | Beide Ansätze können kombiniert werden: Ein Agent mit aktiviertem Daten-Tool kann zusätzlich Dokumente im Chat erhalten, z.B. für Ad-hoc-Analysen. ## Best Practices für RAG * **Dokumentqualität ist entscheidend:** Gut strukturierte, aktuelle Dokumente liefern bessere Ergebnisse als unformatierte Textdateien * **Ordnerstruktur planen:** Thematisch gruppierte Ordner (z.B. "HR-Richtlinien", "Produktdokumentation") ermöglichen gezieltere Suche * **System-Prompt ergänzen:** Weise den Agenten im System-Prompt an, nur basierend auf den bereitgestellten Dokumenten zu antworten * **Regelmäßig aktualisieren:** Ersetze veraltete Dokumente, da das Modell sonst mit veralteten Informationen antwortet ## Nächste Schritte Weitere Strategien für faktisch korrekte Ergebnisse. Fertige Prompts für RAG-Anwendungsfälle. # Einstieg: Arbeiten mit KI Source: https://docs.localmind.ai/arbeiten-mit-ki/einstieg Verstehe, wie KI-Modelle funktionieren und wie du sie effektiv anleitest – dein Lernpfad für das Arbeiten mit KI. KI-Modelle sind leistungsstarke Werkzeuge, die bei richtiger Anwendung deine Produktivität massiv steigern können. Der Schlüssel liegt darin, zu verstehen, wie diese Modelle funktionieren und wie du sie effektiv anleitest. ## Was macht ein KI-Modell? Ein Large Language Model (LLM) ist im Kern ein statistisches System, das auf riesigen Textmengen trainiert wurde. Es verarbeitet deine Eingabe als Folge von **Tokens** (Textfragmente) und generiert Wort für Wort die wahrscheinlichste Fortsetzung. Wichtig zu verstehen: * **Kein echtes "Wissen":** Das Modell hat keine Datenbank mit Fakten. Es hat Muster in Texten gelernt und reproduziert diese. * **Wahrscheinlichkeitsbasiert:** Jedes generierte Wort ist eine statistische Vorhersage basierend auf dem Kontext. * **Kein Gedächtnis zwischen Sitzungen:** Ohne System-Prompt oder Gesprächsverlauf beginnt jede Unterhaltung bei null. Eine Möglichkeit, einem KI-Agenten gezielt Wissen bereitzustellen, ist **RAG (Retrieval-Augmented Generation)**. Dabei werden deine eigenen Dokumente als Wissensquelle angebunden – das Modell kann dann auf verifizierte Informationen zugreifen statt zu "raten". Mehr dazu unter [Wissensquellen](/arbeiten-mit-ki/Wissensquellen). Stell dir ein KI-Modell vor wie einen brillanten neuen Mitarbeiter am ersten Arbeitstag: hochintelligent, aber ohne Kontext über dein Unternehmen, deine Prozesse und deine Erwartungen. Je präziser dein Briefing, desto besser das Ergebnis. ## Warum ist die Art der Anweisung entscheidend? Die Qualität deiner Ergebnisse hängt direkt davon ab, wie du mit dem Modell kommunizierst: * **Vage Anweisung** → Das Modell rät, was du meinst → Generische, oft unbrauchbare Antwort * **Präzise Anweisung** → Das Modell versteht Ziel, Kontext und Format → Zielgerichtete, nützliche Antwort Der Unterschied zwischen einem mittelmäßigen und einem exzellenten Ergebnis liegt fast immer in der Qualität des Prompts – nicht in der Wahl des Modells. ## Dein Lernpfad Diese Kategorie ist als aufbauender Lernpfad strukturiert. Du kannst die Seiten der Reihe nach durcharbeiten oder gezielt zu den Themen springen, die dich interessieren: **Wie du einem KI-Agenten Wissen gibst.** Eigene Dokumente als Wissensquelle anbinden, Hybrid Search einrichten und Halluzinationen durch verifizierte Daten reduzieren. **Wie man gute Anweisungen schreibt.** Von den Bausteinen eines Prompts über Techniken wie Chain of Thought und Prompt Chaining bis hin zu Templates, Halluzinationsvermeidung und Output-Qualität. **Welches Modell wann, und wie "Denken" funktioniert.** Verstehe die Unterschiede zwischen Modellkategorien, lerne wann Reasoning-Modelle sinnvoll sind und wie Kontextfenster funktionieren. # Modellauswahl Source: https://docs.localmind.ai/arbeiten-mit-ki/modellauswahl Verstehe die verschiedenen Modellkategorien und wähle das richtige Modell für deinen Anwendungsfall. Nicht jede Aufgabe braucht das leistungsstärkste (und teuerste) Modell. Die richtige Modellauswahl spart Kosten, reduziert Latenz und kann sogar die Qualität verbessern – weil ein spezialisierteres Modell für einfache Aufgaben oft bessere Ergebnisse liefert als ein Alleskönner. **Modellzugriff hängt von deiner Rolle ab.** Seit v1.0.0-beta.5 verwalten Org-Admins über [Rollenvorlagen](/settings/instance/Role-Templates) und [Space-Rollen](/settings/organization/Space-Rollen) granular, welche Basismodelle dir zur Verfügung stehen. Wenn ein Modell fehlt, das du erwartest, prüfe deine Rollen-Einstellungen oder frage deinen Admin. ## Modellkategorien **Für:** Komplexe Aufgaben, Coding, kreatives Schreiben, nuancierte Analyse Diese Modelle bieten die höchste Qualität und das breiteste Fähigkeitsspektrum. Sie verstehen Nuancen, beherrschen komplexe Instruktionen und liefern die besten Ergebnisse bei anspruchsvollen Aufgaben. | Eigenschaft | Wert | | --------------- | ----------------- | | Qualität | Sehr hoch | | Geschwindigkeit | Mittel | | Kosten | Hoch | | Kontextfenster | 128k – 2M+ Tokens | **Typische Anwendung:** Vertragsanalyse, Strategieberatung, Code-Review, kreative Texte **Für:** Chatbots, einfache Aufgaben, Zusammenfassungen, hohe Geschwindigkeit Optimiert für Geschwindigkeit und Kosteneffizienz. Bei einfachen bis mittleren Aufgaben oft gleichwertig mit Flagship-Modellen – aber deutlich schneller und günstiger. | Eigenschaft | Wert | | --------------- | ---------------- | | Qualität | Mittel bis hoch | | Geschwindigkeit | Hoch | | Kosten | Niedrig | | Kontextfenster | 32k – 1M+ Tokens | **Typische Anwendung:** Kundensupport-Chatbot, E-Mail-Entwürfe, Datenklassifikation **Für:** Mathematik, Logik, wissenschaftliche Analyse, harte Problemlösung Diese Modelle "denken nach" (Chain-of-Thought) bevor sie antworten. Sie zerlegen komplexe Probleme in Schritte und erreichen dadurch bessere Ergebnisse bei logischen Aufgaben. | Eigenschaft | Wert | | ---------------- | ------------------------ | | Qualität (Logik) | Sehr hoch | | Geschwindigkeit | Niedrig (wegen Denkzeit) | | Kosten | Hoch | | Kontextfenster | 32k – 128k Tokens | **Typische Anwendung:** Datenanalyse, mathematische Probleme, strategische Planung **Für:** Aktuelle Informationen, Websuche, lange Kontexte Modelle mit spezialisierten Fähigkeiten wie Internetzugriff oder besonders große Kontextfenster. | Eigenschaft | Wert | | --------------- | ------------------------------------- | | Qualität | Mittel bis hoch | | Geschwindigkeit | Variabel | | Kosten | Mittel | | Besonderheit | Websuche, Zitate, sehr lange Kontexte | **Typische Anwendung:** Marktanalyse, Recherche zu aktuellen Nachrichten **Für:** Semantische Suche, RAG, Klassifizierung Wandeln Text in Vektoren (numerische Repräsentationen) um. Nicht für Chat geeignet, sondern als Grundlage für die Hybrid Search und RAG-Funktionalität. | Eigenschaft | Wert | | --------------- | ----------------- | | Einsatzzweck | Suche, nicht Chat | | Geschwindigkeit | Sehr hoch | | Kosten | Sehr niedrig | | Sprachen | Multilingual | **Typische Anwendung:** Dokumentensuche, Wissensbasis, automatische Kategorisierung ## Entscheidungsbaum: Das richtige Modell finden * **Einfache Aufgabe** (Zusammenfassung, Klassifikation, kurze Antwort) → **Effizienz-Modell** * **Komplexe Aufgabe** (Analyse, Kreativ, Multi-Step) → Weiter zu Schritt 2 * **Semantische Suche / RAG** → **Embedding-Modell** * **Ja** (Mathe, Logik, schrittweise Analyse) → **Reasoning-Modell** * **Nein** (kreatives Schreiben, Recherche, Zusammenfassung) → Weiter zu Schritt 3 * **Ja** (Websuche, aktuelle Nachrichten) → **Search-Modell** * **Nein** → **Flagship-Modell** Teste deinen Prompt mit 2–3 Modellen und vergleiche Qualität, Geschwindigkeit und Kosten. Oft reicht ein günstigeres Modell aus. ## Modelle auf der Localmind-Plattform Modelle werden nicht pro Anfrage gewählt, sondern dem Space über die **[Library](/library/overview)** bereitgestellt: **Library → Basismodell → „Zu Spaces hinzufügen"** (als Verknüpfung oder Kopie). Alternativ kann ein Basismodell org-weit über seine **Verteilungseinstellungen** verteilt werden — diese greifen jedoch nur für **neu erstellte** Spaces, nicht rückwirkend. Erst nach der Bereitstellung ist das Modell im Modell-Dropdown deiner Agenten und Apps wählbar. Mehr zu Reasoning- und Thinking-Modellen unter [Reasoning und Thinking](/arbeiten-mit-ki/Reasoning-und-Thinking). Die verfügbaren Modelle hängen von der Konfiguration deiner Organisation ab. Dein Administrator legt fest, welche Modelle zugänglich sind. In den Org-Einstellungen unter **KI-Konfiguration → Agenten** bzw. **KI-Konfiguration → Chats** wird **nicht** das Dialog- oder App-Modell festgelegt: **Agenten** regelt dort Feldlimits, **Chats** das Modell für die automatische Benennung von Konversationen. Welches Modell dein Agent nutzt, bestimmst du über die Library-Bereitstellung und die Modell-Auswahl in der Agent-Konfiguration. Nutze für Extraktions- und Parsing-Aufgaben **Opus 4.8** oder **Sonnet 5**. Das veraltete **Opus 4.7** bricht solche Aufgaben still ab und liefert leere Ergebnisse („Keine Ergebnisse") — ein Modell-Artefakt, kein Plattform-Fehler. ## Praxistipps ### Kosten vs. Qualität optimieren | Strategie | Erklärung | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Routing** | Einfache Fragen → Speed-Modell, komplexe Fragen → Flagship-Modell | | **Zusammenfassung zuerst** | Lange Dokumente erst mit einem günstigen Modell zusammenfassen, dann mit einem starken Modell analysieren | | **Few-Shot statt Flagship** | Oft bringt ein günstigeres Modell mit guten Beispielen bessere Ergebnisse als ein teures Modell ohne Beispiele | | **Kontextfenster beachten** | Wähle ein Modell, dessen Kontextfenster zu deiner Datenmenge passt – zu klein = Informationsverlust, zu groß = unnötige Kosten | ### Kontextfenster verstehen Das Kontextfenster definiert, wie viel Text das Modell auf einmal verarbeiten kann (gemessen in Tokens). Mehr dazu unter [Kontextfenster](/arbeiten-mit-ki/Context-Fenster). | Dateigröße | Geschätzter Token-Bedarf | Mindestgröße Kontextfenster | | ------------------- | ------------------------ | --------------------------- | | 1 Seite Text | \~500 Tokens | 4k reicht | | 10-Seiten-Bericht | \~5.000 Tokens | 8k reicht | | 50-Seiten-Dokument | \~25.000 Tokens | 32k empfohlen | | 200-Seiten-Handbuch | \~100.000 Tokens | 128k+ nötig | ## Nächste Schritte Wie Reasoning-Modelle funktionieren und wann du sie einsetzt. Tokens, Kontextfenster und praktische Tipps. # Custom Nodes Source: https://docs.localmind.ai/automate/Custom-Nodes Erstellen Sie eigene Nodes für Automate - Erweitern Sie die Funktionalität mit benutzerdefinierten Nodes Custom Nodes sind selbst entwickelte Erweiterungen für Automate. Sie erstellen einen Custom Node, wenn die Standard-Node-Bibliothek nicht ausreicht — typischerweise in drei Fällen: * **Spezifische API-Integration:** Sie müssen sich mit einer internen API oder einem spezialisierten System verbinden, für das es keinen Standard-Node gibt. * **Komplexe Daten-Transformation:** Sie benötigen Transformationen, die über Set-, Filter- und Code-Nodes hinausgehen. * **Wiederverwendbare Geschäftslogik:** Bestimmte Geschäftsregeln werden in vielen Workflows verwendet und sollen als ein Node gekapselt sein. Automate basiert auf n8n — Custom Nodes folgen deshalb dem n8n-Node-Format. Diese Seite zeigt das Setup und ein vollständiges Localmind-Beispiel; die vollständige Referenz zu Property-Typen, UI-Elementen und Node-Verhalten finden Sie in der [offiziellen n8n-Dokumentation](https://docs.n8n.io/integrations/creating-nodes/). ## Aufbau eines Nodes Jeder Node implementiert das `INodeType`-Interface: `description` definiert Anzeigename, Inputs/Outputs, Credentials und die konfigurierbaren Properties; `execute` enthält die Logik. ```typescript Node-Struktur theme={null} interface INodeType { description: INodeTypeDescription; execute(this: IExecuteFunctions): Promise; methods?: INodeTypeDescriptionMethods; } ``` Es gibt drei Node-Typen: | Typ | Aufgabe | Beispiele | Kern-Methode | | ---------------- | ------------------------------------------------------------------------------ | ------------------------------------------------- | ------------ | | **Regular Node** | Führt Operationen aus und gibt Daten weiter, wird von anderen Nodes aufgerufen | Daten-Transformation, API-Calls, Berechnungen | `execute()` | | **Trigger Node** | Startet Workflows automatisch basierend auf Events oder Zeitplänen | Webhook-Trigger, Schedule-Trigger, Event-Listener | `trigger()` | | **Webhook Node** | Empfängt HTTP-Requests und kann Antworten senden | REST-API-Endpoints, Webhook-Listener | `webhook()` | Die Code-Skelette für Trigger- und Webhook-Nodes stehen in der [n8n-Dokumentation](https://docs.n8n.io/integrations/creating-nodes/) — das Beispiel unten zeigt einen Regular Node. ## Entwicklungsumgebung einrichten Voraussetzungen: Node.js 18+, TypeScript (`npm install -g typescript`), Git und ein Code-Editor (VS Code empfohlen). ```bash theme={null} mkdir localmind-custom-node cd localmind-custom-node ``` Initialisieren Sie mit `npm init -y` und bearbeiten Sie die `package.json`. Der `n8n`-Block registriert Ihre Nodes: ```json package.json theme={null} { "name": "localmind-custom-node", "version": "1.0.0", "description": "Custom Nodes für Localmind Automate", "main": "index.js", "scripts": { "build": "tsc", "dev": "tsc --watch" }, "keywords": ["n8n", "n8n-node", "localmind"], "author": "Localmind", "license": "MIT", "n8n": { "n8nNodesApiVersion": 1, "nodes": [ { "node": "LocalmindAgent", "sourcePath": "nodes/LocalmindAgent/LocalmindAgent.node.ts" } ] }, "dependencies": { "n8n-workflow": "^1.0.0" }, "devDependencies": { "@types/node": "^20.0.0", "typescript": "^5.0.0" } } ``` ```json tsconfig.json theme={null} { "compilerOptions": { "module": "commonjs", "target": "ES2020", "lib": ["ES2020"], "declaration": true, "outDir": "./dist", "rootDir": "./", "strict": true, "esModuleInterop": true, "skipLibCheck": true, "forceConsistentCasingInFileNames": true, "resolveJsonModule": true }, "include": ["nodes/**/*"], "exclude": ["node_modules", "dist"] } ``` ```bash theme={null} npm install ``` ## Beispiel: Localmind Agent Node Ein vollständiger Custom Node, der Localmind-Agenten über den OpenAI-kompatiblen `/v1`-Endpoint aufruft (`model` trägt die Agent-UUID): ```typescript nodes/LocalmindAgent/LocalmindAgent.node.ts theme={null} import { IExecuteFunctions, INodeExecutionData, INodeType, INodeTypeDescription, NodePropertyTypes, } from 'n8n-workflow'; export class LocalmindAgent implements INodeType { description: INodeTypeDescription = { displayName: 'Localmind Agent', name: 'localmindAgent', icon: 'file:localmind.svg', group: ['transform'], version: 1, subtitle: '={{$parameter["operation"]}}', description: 'Ruft einen Localmind-Agenten auf', defaults: { name: 'Localmind Agent', }, inputs: ['main'], outputs: ['main'], credentials: [ { name: 'localmindApi', required: true, }, ], properties: [ { displayName: 'Agent ID', name: 'agentId', type: 'string', required: true, default: '', description: 'Die ID des Localmind-Agenten', }, { displayName: 'Input', name: 'input', type: 'string', required: true, default: '', description: 'Der Input-Text für den Agenten', }, { displayName: 'Temperature', name: 'temperature', type: 'number', typeOptions: { minValue: 0, maxValue: 2, numberStepSize: 0.1, }, default: 0.7, description: 'Die Temperature für die Agent-Antwort', }, { displayName: 'Max Tokens', name: 'maxTokens', type: 'number', typeOptions: { minValue: 1, maxValue: 4000, }, default: 500, description: 'Maximale Anzahl von Tokens in der Antwort', }, ], }; async execute(this: IExecuteFunctions): Promise { const items = this.getInputData(); const returnData: INodeExecutionData[] = []; for (let i = 0; i < items.length; i++) { const agentId = this.getNodeParameter('agentId', i) as string; const input = this.getNodeParameter('input', i) as string; const temperature = this.getNodeParameter('temperature', i) as number; const maxTokens = this.getNodeParameter('maxTokens', i) as number; const credentials = await this.getCredentials('localmindApi'); const apiKey = credentials.apiKey as string; // API-Call zu Localmind (OpenAI-kompatibler /v1-Endpoint, model = agent_uuid) const response = await this.helpers.httpRequest({ method: 'POST', url: `https://-api.localmind.ai/v1/chat/completions`, headers: { 'Authorization': `Bearer ${apiKey}`, 'Content-Type': 'application/json', }, body: { model: agentId, messages: [{ role: 'user', content: input }], temperature, max_tokens: maxTokens, }, }); returnData.push({ json: { agentId, input, response: response.choices[0].message.content, totalTokens: response.usage.total_tokens, }, }); } return [returnData]; } } ``` Das Beispiel zeigt zugleich die wichtigsten Bausteine der Datenverarbeitung: `getInputData()` liest die Input-Items, `getNodeParameter()` liest die Node-Konfiguration, `returnData.push({ json: ... })` erzeugt den Output. Für Fehlerbehandlung pro Item prüfen Sie `this.continueOnFail()` — ist die Option aktiv, geben Sie den Fehler als Item weiter statt die Execution abzubrechen (Details: [n8n-Dokumentation](https://docs.n8n.io/integrations/creating-nodes/)). ### Credentials definieren Für die API-Authentifizierung definieren Sie einen Credential-Typ. Als API-Key verwenden Sie einen **persönlichen User-API-Key** (`sk-…`), den Sie unter **Benutzereinstellungen → API-Schlüssel** erstellen — optional auf einzelne Spaces gescoped (siehe [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel)): ```typescript credentials/localmindApi.credentials.ts theme={null} import { ICredentialType, INodeProperties, } from 'n8n-workflow'; export class LocalmindApi implements ICredentialType { name = 'localmindApi'; displayName = 'Localmind API'; properties: INodeProperties[] = [ { displayName: 'API Key', name: 'apiKey', type: 'string', typeOptions: { password: true, }, default: '', required: true, }, { displayName: 'Base URL', name: 'baseUrl', type: 'string', default: 'https://-api.localmind.ai/v1', required: true, }, ]; } ``` ### Properties Properties sind die konfigurierbaren Parameter Ihres Nodes. Neben `string` und `number` (siehe Beispiel oben) gibt es unter anderem `options` für Dropdown-Auswahlen und `collection` für Key-Value-Sammlungen; gesteuert wird das Verhalten über Felder wie `required`, `default`, `placeholder` und `typeOptions` (etwa `minValue`, `maxValue`, `numberStepSize`). Die vollständige Liste aller Property-Typen dokumentiert die [n8n-Referenz](https://docs.n8n.io/integrations/creating-nodes/). Einen direkten SQL-/Datenbank-Zugriff auf Localmind gibt es nicht. Daten in Spaces erreichen Sie ausschließlich über die [Localmind API](/api-reference/introduction) — zum Beispiel über die Dokument- und Such-Endpoints (siehe [Dokumente und Suche](/api-reference/Dokumente-und-Suche)). ## Testen Kompilieren Sie den Node mit `npm run build` und testen Sie ihn lokal im Automate Dev-Modus. Ergänzen Sie Unit Tests für die Node-Logik (z.B. `test/LocalmindAgent.test.ts` mit einem Test-Framework Ihrer Wahl) und Integration Tests in echten Workflows: Test-Workflow erstellen, mit Test-Daten ausführen, Outputs überprüfen. Wie Sie Nodes und Workflows systematisch testen, steht unter [Testing](/automate/testing). ## Deployment 1. **Build erstellen:** `npm run build` kompiliert TypeScript zu JavaScript. 2. **Package erstellen:** `npm pack` erzeugt eine installierbare `.tgz`-Datei. 3. **Node installieren:** im Automate-Verzeichnis `npm install /path/to/localmind-custom-node-1.0.0.tgz` ausführen. Für die Verteilung im Team haben Sie mehrere Optionen: eine private npm Registry, Installation direkt aus einem Git-Repository, lokale Installation für Entwicklung und Testing oder das Bündeln in ein Docker-Image für Container-Deployments. ## Best Practices * **Dokumentation:** jeden Property und jede Funktion klar beschreiben (`description`-Felder pflegen). * **Error Handling:** alle Fehlerfälle abfangen, `continueOnFail()` unterstützen. * **Performance:** unnötige API-Calls vermeiden. * **Wiederverwendbarkeit:** Nodes so designen, dass sie in verschiedenen Kontexten funktionieren. * **Testing:** Unit- und Integration-Tests schreiben. * **Versionierung:** semantische Versionierung verwenden. ## Häufige Probleme | Problem | Lösung | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Node erscheint nicht in der Node-Liste | `package.json`-Konfiguration (`n8n`-Block) prüfen, sicherstellen dass der Node kompiliert wurde, Automate nach der Installation neu starten | | TypeScript-Kompilierung schlägt fehl | `tsconfig.json` prüfen, alle Dependencies installieren, Type-Definitionen überprüfen | | Credentials werden nicht geladen | Credential-Definition prüfen, gespeicherte Credentials kontrollieren, Credential-Zugriff im Node testen | ## Nächste Schritte Offizielle Referenz für Custom Nodes: Property-Typen, Trigger-/Webhook-Skelette, UI-Elemente. Endpoint-Referenz und Code-Beispiele für Integrationen. Bei Fragen zur Entwicklung von Custom Nodes unterstützt Sie unser Entwickler-Team unter [dev@localmind.ai](mailto:dev@localmind.ai). # Item Management Source: https://docs.localmind.ai/automate/Item-Management Verwaltung und Manipulation von Items in Automate-Workflows Items sind die grundlegenden Dateneinheiten in Automate-Workflows: JSON-Objekte, die Daten von Node zu Node transportieren (`Trigger → Node 1 → Node 2 → …`). Jeder Node kann Items empfangen, verarbeiten und neue Items ausgeben. Jedes Item hat diese Struktur: ```json theme={null} { "json": { "field1": "value1", "field2": "value2" }, "binary": {}, "pairedItem": {} } ``` ## Item-Zugriff ### Auf aktuelle Item-Daten zugreifen ```javascript Expression Editor theme={null} // Zugriff auf JSON-Felder {{ $json.fieldName }} // Verschachtelte Felder {{ $json.user.email }} // Array-Zugriff {{ $json.items[0].name }} // Mit Null-Check {{ $json.user?.email || 'default@example.com' }} ``` ```javascript Code-Node theme={null} // Im Code-Node const email = $input.item.json.email; const userName = $input.item.json.user?.name; // Zugriff auf alle Item-Daten const allData = $input.item.json; ``` ### Auf vorherige Nodes zugreifen ```javascript Spezifischer Node theme={null} // Zugriff auf Daten eines bestimmten Nodes {{ $('Node Name').item.json.fieldName }} // Erstes Item eines Nodes {{ $('HTTP Request').first().json.data }} // Letztes Item eines Nodes {{ $('HTTP Request').last().json.data }} // Alle Items eines Nodes {{ $('HTTP Request').all() }} ``` ```javascript Code-Node theme={null} // Im Code-Node const previousNodeData = $('HTTP Request').item.json; const allItems = $('HTTP Request').all(); ``` Verwenden Sie den Expression Editor, um Item-Zugriffe zu validieren — die Autovervollständigung zeigt verfügbare Felder an. ## Item-Manipulation ### Set Node — Felder setzen und ändern Der Set Node (in der UI „Edit Fields") ist der primäre Weg zur Item-Manipulation. Sie definieren unter **Fields to Set** die gewünschten Felder mit Name, Typ und Wert; die Option **Include Other Input Fields** steuert, ob die übrigen Input-Felder erhalten bleiben. ```json Fields to Set theme={null} { "fields": [ { "name": "fullName", "type": "string", "value": "={{ $json.firstName }} {{ $json.lastName }}" }, { "name": "email", "type": "string", "value": "={{ $json.email }}" }, { "name": "timestamp", "type": "string", "value": "={{ $now.toISO() }}" } ] } ``` ```json Input theme={null} { "firstName": "Max", "lastName": "Mustermann", "email": "max@example.com" } ``` ```json Output theme={null} { "fullName": "Max Mustermann", "email": "max@example.com", "timestamp": "2026-07-10T10:30:00.000Z" } ``` **Felder umbenennen oder reduzieren:** Setzen Sie die neuen Feldnamen unter **Fields to Set** (z.B. `userEmail` = `{{ $json.email }}`) und lassen Sie **Include Other Input Fields** deaktiviert — das Output-Item enthält dann nur die gesetzten Felder, alle übrigen (z.B. `email`, `password`) sind entfernt. In älteren Workflows finden Sie dafür noch die Legacy-Option `keepOnlySet`; die moderne Set-Node-Darstellung ersetzt sie durch **Fields to Set** + **Include Other Input Fields**. ### Merge Node — Items kombinieren Der Merge Node kombiniert Daten aus verschiedenen Quellen und bietet drei Modi: * **Append:** hängt die Items aller Inputs nacheinander an einen gemeinsamen Stream an * **Combine:** führt Items zusammen — nach übereinstimmenden Feldern (Matching Fields), nach Position oder als alle möglichen Kombinationen * **Choose Branch:** gibt nur die Items eines gewählten Inputs weiter ```json Beispiel: Combine (By Position) theme={null} // Input 1 (Node A) { "id": 1, "name": "Max" } // Input 2 (Node B) { "email": "max@example.com" } // Output { "id": 1, "name": "Max", "email": "max@example.com" } ``` Die Modi `mergeByIndex`, `mergeByKey`, `append` und `multiplex` stammen aus der Legacy-Version des Merge Node und existieren in aktuellen Automate-Versionen nicht mehr. ### Code-Node — Komplexe Manipulationen ```javascript Item transformieren theme={null} // Komplexe Transformation const items = $input.all(); const transformedItems = items.map(item => { return { json: { id: item.json.id, fullName: `${item.json.firstName} ${item.json.lastName}`, email: item.json.email.toLowerCase(), processedAt: new Date().toISOString(), metadata: { originalData: item.json } } }; }); return transformedItems; ``` ```javascript Items filtern theme={null} // Items basierend auf Bedingungen filtern const items = $input.all(); const filteredItems = items.filter(item => { return item.json.status === 'active' && item.json.amount > 100; }); return filteredItems; ``` ## Item-Filterung ### Filter Node Der Filter Node lässt nur Items durch, die alle konfigurierten Bedingungen erfüllen. Typische Filter-Expressions: ```javascript Filter-Beispiele theme={null} // Status gleich "active" {{ $json.status === 'active' }} // Betrag größer als 100 {{ $json.amount > 100 }} // E-Mail enthält Domain {{ $json.email.includes('@company.com') }} ``` Für ODER-Verknüpfungen oder mehrstufige Bedingungen nutzen Sie den Code-Node (siehe „Items filtern" oben). ### IF Node — Bedingte Verarbeitung Der IF Node verzweigt Items basierend auf Bedingungen in einen True- und einen False-Branch (z.B. `Premium Processing` vs. `Standard Processing`): ```javascript IF-Bedingung theme={null} // Einfache Bedingung {{ $json.userType === 'premium' }} // Komplexe Bedingung {{ $json.status === 'active' && $json.balance > 0 }} // Mit Null-Check {{ $json.user?.subscription?.active === true }} ``` ## Transformation und Validierung Für generische Datentransformationen (Typ-Konvertierung, Datums-Formatierung, Array-Operationen) und Validierungs-Patterns nutzen Sie JavaScript-Expressions bzw. den Code-Node. Eine vollständige Referenz aller eingebauten Funktionen und Variablen finden Sie in der [offiziellen n8n-Dokumentation zu Datenstrukturen und Transformationen](https://docs.n8n.io/data/). Validieren Sie Items so früh wie möglich im Workflow — z.B. mit einem Filter Node direkt nach dem Trigger, der unvollständige Items aussortiert: `{{ $json.id !== undefined && $json.email !== undefined }}` ## Häufige Patterns ### Item-Enrichment Reichern Sie Items mit zusätzlichen Daten an (`Trigger → Get Base Data → Enrich with API → Merge → Output`): ```json Enrichment-Workflow theme={null} // Schritt 1: Basis-Daten { "userId": 123, "name": "Max" } // Schritt 2: API-Daten abrufen { "email": "max@example.com", "role": "admin" } // Schritt 3: Zusammenführen { "userId": 123, "name": "Max", "email": "max@example.com", "role": "admin" } ``` ### Item-Normalisierung Normalisieren Sie unterschiedliche Input-Formate für konsistente Verarbeitung: ```javascript Normalisierung theme={null} // Verschiedene Input-Formate { "first_name": "Max", "last_name": "Mustermann" } { "firstName": "Max", "lastName": "Mustermann" } // Normalisiertes Format { "firstName": "={{ $json.first_name || $json.firstName }}", "lastName": "={{ $json.last_name || $json.lastName }}", "fullName": "={{ $json.firstName }} {{ $json.lastName }}" } ``` ### Item-Splitting Teilen Sie komplexe Items in einfachere auf: ```javascript Item splitten theme={null} // Input: Ein Item mit Array { "orderId": 123, "items": [ { "productId": 1, "quantity": 2 }, { "productId": 2, "quantity": 1 } ] } // Output: Mehrere Items // Item 1 { "orderId": 123, "productId": 1, "quantity": 2 } // Item 2 { "orderId": 123, "productId": 2, "quantity": 1 } ``` ## Best Practices * **Konsistente Feldnamen:** einheitliche Namenskonventionen über den gesamten Workflow hinweg verwenden. * **Null-Checks:** immer für verschachtelte Felder implementieren — `{{ $json.user?.email }}`. * **Frühe Validierung:** Items so früh wie möglich im Workflow validieren, nicht erst am Ende. * **Dokumentation:** festhalten, welche Item-Struktur jeder Node erwartet und produziert. * **Transformation isolieren:** Set Nodes für klare Transformationen nutzen, keine komplexen Expressions in anderen Nodes. * **Performance:** unnötige Item-Kopien vermeiden; im Set Node nur benötigte Felder weitergeben (**Include Other Input Fields** deaktiviert lassen). ## Checkliste * [ ] Item-Struktur ist dokumentiert * [ ] Null-Checks sind implementiert * [ ] Datentypen sind konsistent * [ ] Validierung erfolgt früh im Workflow * [ ] Feldnamen folgen Namenskonventionen * [ ] Items werden nicht unnötig kopiert * [ ] Transformationen sind klar und nachvollziehbar ## Nächste Schritte Items in Batches verarbeiten. Item-Verarbeitung für bessere Performance optimieren. Grundlagen von Automate-Workflows. Item-Manipulationen gründlich testen. # Localmind Agent in n8n einbinden Source: https://docs.localmind.ai/automate/Localmind-Agent Localmind-Agenten via HTTP Request Node aus n8n-Workflows aufrufen — OpenAI-kompatibler Chat-Completions-Endpoint mit Bearer-Auth. Sie rufen einen bestehenden Localmind-Agenten aus einem n8n-Workflow auf und verarbeiten die Antwort in nachfolgenden Nodes. Der getestete Weg ist die generische **HTTP Request Node**, die den OpenAI-kompatiblen Endpoint `POST /v1/chat/completions` Ihrer Instanz aufruft. Welcher Agent antwortet, bestimmt das `model`-Feld im Request-Body: Es trägt die **Agent-UUID** aus `GET /v1/models`. Einen persönlichen API-Key (`sk-…`), die Agent-UUID (aus `GET /v1/models`) und die Base-URL Ihrer Instanz: `https://-api.localmind.ai/v1`. HTTP POST mit `Authorization: Bearer ` und JSON-Body im OpenAI-Chat-Completions-Schema gegen `/v1/chat/completions` — `model` = Agent-UUID. ## Voraussetzungen * **Persönlicher API-Key.** Sie erstellen den Schlüssel unter **Benutzereinstellungen → API-Schlüssel** — optional auf ausgewählte Spaces gescoped. Der Key bestimmt, welche Agenten Sie über die API sehen und aufrufen können. Details siehe [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel). * **Agent-UUID.** `GET /v1/models` listet alle Agenten, auf die Ihr Key Zugriff hat — das Feld `id` jedes Eintrags ist die UUID, die Sie im Request-Body als `model` einsetzen. Endpoint-Details siehe [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel). * **Base-URL.** Localmind-Deployments folgen einem festen Subdomain-Schema. Für API-Aufrufe verwenden Sie immer den `-api`-Host mit `/v1`-Prefix: `https://-api.localmind.ai/v1`. Verwenden Sie nicht den `-app`-Host aus dem Browser: * `-app.localmind.ai` — Web-UI (Browser, NICHT für API) * `-api.localmind.ai` — API-Endpoint (richtig für n8n) * `-auth.localmind.ai` — Keycloak (nicht für Agent-Aufrufe) Wenn Sie eine URL aus dem Browser kopieren, steht dort `-app`. Ersetzen Sie `-app` durch `-api`, bevor Sie die URL in n8n einsetzen. **Konkretes Ableitungs-Beispiel:** ```text Browser (UI) theme={null} https://-app.localmind.ai/orgs//spaces//agents//chat ``` ```text API-Endpoint theme={null} https://-api.localmind.ai/v1/chat/completions ``` Die Agent-UUID sehen Sie auch in der Browser-URL der Agent-Detailseite (im Pfad direkt nach `/agents/`). Sie gehört aber **nicht** in die API-URL, sondern in das `model`-Feld des Request-Bodys. Verbindlich ermitteln Sie die UUID über `GET /v1/models`. ## HTTP Request Node konfigurieren Platzieren Sie in Ihrem n8n-Workflow eine neue **HTTP Request Node**. Setzen Sie die Method auf `POST` und tragen Sie als URL den Chat-Completions-Endpoint Ihrer Instanz ein: `https://-api.localmind.ai/v1/chat/completions`. 1. Setzen Sie **Authentication** auf `Generic Credential Type`. 2. Wählen Sie darunter `Header Auth`. 3. Legen Sie eine neue Credential vom Typ **Header Auth** an mit: * **Name:** `Authorization` * **Value:** `Bearer ` Legen Sie API-Schlüssel NIE direkt im Workflow-JSON ab — immer als n8n-Credential. So werden sie verschlüsselt gespeichert und in geteilten Workflows nicht sichtbar. Aktivieren Sie **Send Body**, wählen Sie als Body Content Type `JSON` und fügen Sie das Body-Snippet aus dem Abschnitt [Request-Body](#request-body) ein. Tragen Sie in `model` die Agent-UUID ein. n8n setzt den `Content-Type: application/json`-Header in der Regel automatisch. Klicken Sie auf **Execute Node** und warten Sie auf den grünen Status. Im Output sehen Sie das Feld `choices[0].message.content` mit der Agent-Antwort. Statuscode 200 und im Output-JSON ein `choices`-Array mit mindestens einem Eintrag — dann ist die Konfiguration korrekt. ## Request-Body ```json Body (n8n) theme={null} { "model": "", "messages": [ { "role": "user", "content": "" } ], "stream": false } ``` * **`model`-Feld:** trägt die **Agent-UUID** aus `GET /v1/models` — kein Modellname wie `gpt-4`. Welches Sprachmodell tatsächlich antwortet, ist am Agenten in Localmind hinterlegt. Eine unbekannte UUID beantwortet der Endpoint mit `404 {"detail":"Model '…' not found"}`. * **`stream: false` ist Pflicht.** Die HTTP Request Node kann Server-Sent Events (SSE) nicht verarbeiten. Bei `stream: true` blockiert die Node bis zum Timeout — wer Streaming braucht, muss die Antwort per Code-Node selbst parsen. * **`messages`** folgt dem OpenAI-Standard-Format: eine Liste von `{role, content}`-Objekten mit `role` aus `"user"`, `"assistant"` oder `"system"`. `` ist in n8n typischerweise eine Expression wie `{{ $json.userMessage }}`. * **Stateless:** Der Endpoint hält keinen serverseitigen Conversation-State. Für mehrstufige Konversationen senden Sie die bisherige History bei jedem Aufruf vollständig im `messages`-Array mit. ## Response-Format ```json Response (200 OK) theme={null} { "id": "chatcmpl-...", "object": "chat.completion", "created": 1700000000, "model": "agent-model", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Antwort des Agenten" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 10, "completion_tokens": 20, "total_tokens": 30 } } ``` In Folge-Nodes greifen Sie auf die relevanten Felder per Expression zu: * **Antwort-Text:** `{{ $json.choices[0].message.content }}` * **Token-Verbrauch für Logging oder Limits:** `{{ $json.usage.total_tokens }}` * Das `model`-Feld in der Response zeigt das tatsächlich vom Agent verwendete Modell, nicht den Wert aus Ihrem Request. ## Beispiel-Workflow Ein typischer 3-Node-Workflow sieht so aus: ``` Trigger (Webhook oder Manual) → HTTP Request Node (Localmind Agent) → Set/Code-Node (Antwort extrahieren) ``` Der nachgelagerte Set- oder Code-Node liest `choices[0].message.content` aus und stellt es als sauberes Feld für weitere Schritte bereit. Ein einzelner User-Turn — die Nachricht kommt per Expression aus dem Trigger-Input: ```json Body theme={null} { "model": "", "messages": [ { "role": "user", "content": "{{ $json.userMessage }}" } ], "stream": false } ``` Im Trigger erwartet der Workflow ein Feld `userMessage` — beispielsweise aus einem Webhook-Payload oder einem manuellen Test-Input. Für mehrstufige Konversationen schicken Sie die bisherige History im `messages`-Array mit. n8n hat keinen automatischen Session-State — Sie müssen die History entweder im Trigger-Input mitliefern oder via Static Data Node persistieren. ```json Body mit History theme={null} { "model": "", "messages": [ { "role": "system", "content": "Du bist ein hilfreicher Assistent." }, { "role": "user", "content": "Wie hoch ist der Eiffelturm?" }, { "role": "assistant", "content": "Der Eiffelturm ist 330 Meter hoch." }, { "role": "user", "content": "Und wann wurde er gebaut?" } ], "stream": false } ``` Jeder neue User-Turn hängt einen weiteren `{ "role": "user", ... }`-Eintrag ans Ende, die letzte Assistant-Antwort wandert als `{ "role": "assistant", ... }` davor. ## Stolperfallen Das `model`-Feld enthält einen Modellnamen (z.B. `gpt-4`) oder eine falsche UUID. Localmind routet **nicht** über Modellnamen — der Wert muss eine Agent-UUID aus `GET /v1/models` sein. Prüfen Sie auch, ob Ihr API-Key Zugriff auf den Space des Agenten hat: Agenten außerhalb des Key-Scopes tauchen in `GET /v1/models` nicht auf und sind nicht aufrufbar. Häufigste Ursache: Sie haben die URL aus dem Browser kopiert und dabei `-app` stehen lassen. Ersetzen Sie `-app` durch `-api`. Prüfen Sie außerdem, dass der Pfad exakt `/v1/chat/completions` lautet (mit `/v1`-Prefix). `stream` ist versehentlich auf `true` gesetzt. Die HTTP Request Node erwartet eine einzelne JSON-Response und hängt bei Server-Sent Events bis zum Timeout. Setzen Sie `stream` explizit auf `false`. Das `model`- oder `messages`-Feld fehlt im Request-Body oder ist falsch formatiert. Übernehmen Sie das Body-Snippet aus diesem Artikel und tragen Sie in `model` die Agent-UUID ein. ## Fehlerbilder | Status | Ursache | Fix | | ------ | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | 401 | Ungültiger oder fehlender API-Schlüssel | Credential in n8n prüfen, `Bearer `-Präfix vor dem Schlüssel nicht vergessen | | 404 | Host `-app` statt `-api`, `/v1`-Prefix fehlt oder unbekannte Agent-UUID im `model`-Feld („Model not found“) | Base-URL prüfen; UUID gegen `GET /v1/models` abgleichen | | 422 | Body-Schema verletzt (`model` oder `messages` fehlt) | Body-Snippet aus diesem Artikel übernehmen | ## Weiterführend * [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel) — API-Key erstellen und verwalten * [OpenAI-kompatibel](/api-reference/OpenAI-Kompatibel) — Referenz zu `GET /v1/models` und `POST /v1/chat/completions` * [Use-Cases](/api-reference/Use-Cases) — weitere API-Rezepte, u.a. n8n-Automatisierung und Chatbots * [API-Key funktioniert nicht](/troubleshooting/API-Key-Funktioniert-Nicht) — Troubleshooting bei Auth-Problemen * [Security in Automate](/automate/security) — Credentials in n8n sicher verwalten * [Debugging in Automate](/automate/debugging) — allgemeine Workflow-Fehlersuche # Naming Conventions Source: https://docs.localmind.ai/automate/Naming-Conventions Best Practices für die Benennung von Nodes und Workflows in Automate Eine konsistente und aussagekräftige Benennung von Workflows und Nodes ist entscheidend für die Wartbarkeit und Verständlichkeit Ihrer Automatisierungen. ## Warum ist Benennung wichtig? Gut benannte Workflows sind einfacher zu verstehen und zu aktualisieren, besonders wenn Sie nach Monaten wieder daran arbeiten. Klare Namen helfen Ihrem Team, schnell zu verstehen, was ein Workflow macht, ohne ihn öffnen zu müssen. Aussagekräftige Namen erleichtern das Auffinden von Problemen in Execution-Logs. Mit wachsender Anzahl von Workflows werden gute Namenskonventionen immer wichtiger. ## Workflow-Namen ### Best Practices **Gut:** * `Send Welcome Email to New Users` * `Process Customer Support Tickets` * `Daily Report Generation` * `Sync CRM with Localmind Agents` **Schlecht:** * `Workflow 1` * `Test` * `My Workflow` * `Untitled` ### Namensstruktur Verwenden Sie eine konsistente Struktur: ``` [Aktion] [Objekt] [Kontext] ``` **Beispiele:** * `Send Email to New Users` * `Process Order Payment` * `Generate Weekly Report` * `Sync Data from CRM` ### Präfixe für Organisation Für größere Teams können Präfixe hilfreich sein: * `[Team]-[Funktion]`: `Marketing-Send Newsletter` * `[Umgebung]-[Funktion]`: `Production-Process Orders` * `[Priorität]-[Funktion]`: `Critical-Monitor System Health` ## Node-Namen ### Standard-Nodes benennen Auch Standard-Nodes sollten aussagekräftige Namen erhalten: ```json HTTP Request Node theme={null} { "name": "Get User Data from API", "type": "httpRequest", "parameters": { "method": "GET", "url": "https://api.example.com/users" } } ``` ```json IF Node theme={null} { "name": "Check if User is Premium", "type": "if", "conditions": { "userType": "premium" } } ``` ```json Set Node theme={null} { "name": "Prepare Email Data", "type": "set", "values": { "subject": "Welcome!", "body": "{{ $json.message }}" } } ``` ### Nodes, die Localmind-Agenten aufrufen Einen dedizierten Agent-Node gibt es nicht — Localmind-Agenten rufen Sie über den HTTP-Request-Node auf (siehe [Localmind Agent](/automate/Localmind-Agent)). Benennen Sie diese HTTP-Request-Nodes nach der fachlichen Aufgabe, nicht nach der Technik: **Gut:** * `Analyze Customer Sentiment (Localmind)` * `Generate Product Description (Localmind)` * `Extract Key Information (Localmind)` **Schlecht:** * `HTTP Request` * `HTTP Request 1` * `AI Call` ## Namenskonventionen ### Groß- und Kleinschreibung **Empfohlen: Pascal Case für Workflows** * `SendWelcomeEmail` * `ProcessCustomerOrders` * `GenerateDailyReports` **Alternative: Kebab Case** * `send-welcome-email` * `process-customer-orders` * `generate-daily-reports` ### Sprache **Empfehlung:** Verwenden Sie Englisch für technische Namen, Deutsch für Beschreibungen: * Workflow-Name: `SendWelcomeEmail` * Beschreibung: "Sendet Willkommens-E-Mail an neue Benutzer" ### Länge * **Workflows:** 3-5 Wörter (20-50 Zeichen) * **Nodes:** 2-4 Wörter (15-40 Zeichen) * Vermeiden Sie zu lange Namen, die in der UI abgeschnitten werden ## Beschreibungen hinzufügen Nutzen Sie das Beschreibungsfeld für zusätzliche Kontextinformationen: **Workflow-Beschreibung:** ``` Sendet automatisch eine Willkommens-E-Mail an neue Benutzer innerhalb von 5 Minuten nach der Registrierung. Verwendet den "Welcome Email" Agent für personalisierte Nachrichten. ``` **Node-Beschreibung:** ``` Ruft Benutzerdaten aus der CRM-API ab. Timeout: 30 Sekunden. Retry bei Fehlern: 3 Versuche. ``` ## Beispiele aus der Praxis ### E-Commerce Workflow ``` Workflow: ProcessOrderPayment ├── Node: "Receive Order Webhook" ├── Node: "Validate Payment Method" ├── Node: "Process Payment via Stripe" ├── Node: "Check if Payment Successful" │ ├── True: "Send Confirmation Email" │ └── False: "Send Payment Failed Notification" └── Node: "Update Order Status in Database" ``` ### Customer Support Workflow ``` Workflow: HandleSupportTicket ├── Node: "Monitor Support Email Inbox" ├── Node: "Classify Ticket Priority" ├── Node: "Route to Appropriate Agent" │ ├── High Priority: "Notify Senior Support" │ └── Normal: "Add to Queue" ├── Node: "Generate Response with AI Agent" └── Node: "Send Response to Customer" ``` ## Checkliste * [ ] Workflow-Name beschreibt klar die Hauptfunktion * [ ] Alle Nodes haben aussagekräftige Namen * [ ] Konsistente Namenskonvention im gesamten Projekt * [ ] Beschreibungen für komplexe Workflows/Nodes vorhanden * [ ] Namen sind nicht zu lang (werden nicht abgeschnitten) * [ ] Keine generischen Namen wie "Test" oder "Workflow 1" ## Häufige Fehler vermeiden **Vermeiden Sie:** * Generische Namen ohne Kontext * Namen, die nur für Sie selbst verständlich sind * Zu kurze Abkürzungen, die nicht selbsterklärend sind * Namen, die sich im Laufe der Zeit ändern (z.B. "Neuer Workflow") **Tipp:** Erstellen Sie eine Namenskonventions-Dokumentation für Ihr Team und halten Sie sich konsequent daran. Dies erleichtert die Zusammenarbeit erheblich. *** **Weiterführende Themen:** Lesen Sie auch [Testing](/automate/testing) und [Versionierung](/automate/versioning) für weitere Best Practices. # Retry Logic Source: https://docs.localmind.ai/automate/Retry-Logic Retry-Mechanismen für robuste Automate-Workflows: Retry On Fail, Error-Workflows und selbstgebaute Retry-Loops. Retry-Logik wiederholt fehlgeschlagene Operationen automatisch. Temporäre Fehler — Netzwerk-Timeouts, API-Rate-Limits (429), Server-Überlastung (503), kurze Verbindungsprobleme — sind häufig; ohne Retry bedeutet jeder davon eine fehlgeschlagene Execution mit manueller Intervention und möglichem Datenverlust. Mit Retry werden temporäre Fehler überwunden, die Erfolgsrate steigt. ## Drei Mechanismen im Überblick | Mechanismus | Wo konfiguriert | Geeignet für | | ----------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------- | | **Retry On Fail** (eingebaut) | Node-Einstellungen | Standardfall: temporäre Fehler einzelner Nodes automatisch wiederholen | | **Error-Workflow** | Workflow-Einstellungen → Error Workflow | Zentrale Fehlerbehandlung: Benachrichtigung, Logging, ggf. Neustart über die Automate-API | | **Retry-Loop** (selbstgebaut) | IF-Node + Wait-Node + Rückverbindung | Exponential Backoff, selektive Retries nach Fehlertyp | Beginnen Sie immer mit **Retry On Fail** — es deckt die meisten Fälle ohne zusätzliche Nodes ab. Die anderen beiden Patterns sind Ergänzungen, kein Ersatz. ## Retry On Fail: das eingebaute Node-Setting Jeder Node bringt eine eingebaute Retry-Funktion mit. Öffnen Sie den Node (z. B. einen HTTP-Request-Node), wechseln Sie vom Parameter-Tab in den **Settings**-Tab und schalten Sie **Retry On Fail** ein. Zwei Parameter steuern das Verhalten: * **Max Tries** — wie oft der Node insgesamt versucht wird (Standard: 3) * **Wait Between Tries** — Wartezeit zwischen den Versuchen in Millisekunden (Standard: 1000 ms); bei Rate-Limit-Fehlern lohnt sich ein höherer Wert **Grenzen von Retry On Fail:** Die Wartezeit ist konstant (kein Exponential Backoff), und der Node wiederholt bei **jedem** Fehler — er unterscheidet nicht zwischen retryable (429, 503) und non-retryable Fehlern (400, 401). Wenn Sie das brauchen, nutzen Sie den [selbstgebauten Retry-Loop](#fortgeschritten-retry-loop-im-workflow-selbstgebaut). ## Retryable vs. Non-Retryable Fehler Nicht jeder Fehler sollte wiederholt werden — als Faustregel sind 5xx-Fehler oft retryable, 4xx-Fehler meist nicht: | Fehler | Retry? | Grund | | ------------------------- | -------- | ---------------------------------------------- | | 429 Too Many Requests | Ja | Rate Limit erreicht — Wartezeit hilft | | 503 Service Unavailable | Ja | Temporäre Server-Überlastung | | 504 Gateway Timeout | Ja | Timeout — möglicherweise temporär | | ECONNRESET | Ja | Verbindung zurückgesetzt — Netzwerkproblem | | ETIMEDOUT | Ja | Timeout — möglicherweise temporär | | 500 Internal Server Error | Manchmal | Temporär oder dauerhaft — abhängig von der API | | 400 Bad Request | Nein | Ungültige Anfrage — wird nicht besser | | 401 Unauthorized | Nein | Authentifizierung fehlgeschlagen | | 403 Forbidden | Nein | Keine Berechtigung | | 404 Not Found | Nein | Ressource existiert nicht | | 422 Unprocessable Entity | Nein | Validierungsfehler | ## Error-Workflow: Fehler zentral behandeln Der **Error Trigger**-Node startet einen **separaten Fehlerbehandlungs-Workflow**, sobald ein Produktiv-Workflow fehlschlägt. Er eignet sich für Benachrichtigungen, Logging und das gezielte Neu-Anstoßen von Workflows über die Automate-API. Beachten Sie: Error-Workflows werden nur bei **Production-Executions** ausgelöst (aktivierte Workflows) — nicht bei manuellen Test-Ausführungen im Editor. Der Error Trigger ist **kein In-Place-Retry**: Er kann nicht in den fehlgeschlagenen Workflow „zurückschleifen" und dort weitermachen. Er startet eine eigene, unabhängige Ausführung des Fehlerbehandlungs-Workflows. Erstellen Sie einen neuen Workflow, dessen erster Node ein **Error Trigger** ist. Dieser Workflow enthält Ihre Fehlerbehandlung — zum Beispiel eine Benachrichtigung per E-Mail oder Chat und einen Logging-Schritt. Der Error Trigger liefert Informationen über die fehlgeschlagene Ausführung: ```javascript Error-Daten im Fehlerbehandlungs-Workflow theme={null} // Execution-Informationen {{ $json.execution.id }} {{ $json.execution.url }} {{ $json.execution.lastNodeExecuted }} // Fehlerinformationen {{ $json.execution.error.message }} // Workflow-Informationen {{ $json.workflow.id }} {{ $json.workflow.name }} ``` Wenn ein erneuter Durchlauf sinnvoll ist, führen Sie den betroffenen Workflow über die Web-App erneut aus — bzw. programmatisch, siehe [Automate-API](/administration/api). Stellen Sie vor einem Neustart sicher, dass keine Duplikate entstehen — etwa indem Sie prüfen, welche Schritte bereits erfolgreich gelaufen sind. Öffnen Sie in Ihrem Produktiv-Workflow die **Workflow-Einstellungen** und wählen Sie unter **Error Workflow** den Fehlerbehandlungs-Workflow aus. ## Fortgeschritten: Retry-Loop im Workflow (selbstgebaut) Wenn Sie **Exponential Backoff** oder **selektive Retries** (nur bei bestimmten Fehlern) brauchen, können Sie einen Retry-Loop selbst bauen. Das ist ein **DIY-Pattern** — Automate bringt dafür keinen fertigen Baustein mit. **Struktur des Loops:** ``` HTTP Request (On Error: Continue using error output) ├─ Success-Output → Workflow läuft normal weiter └─ Error-Output → IF (Versuche übrig?) ├─ true → Wait (Backoff-Wartezeit) → zurück zum HTTP Request └─ false → Stop And Error (oder Benachrichtigung) ``` Setzen Sie im Settings-Tab des Nodes die Option **On Error** auf **Continue (using error output)**. Der Node bricht dann bei Fehlern nicht ab, sondern gibt die Fehlerdaten über einen zweiten Output aus. Verbinden Sie den Error-Output mit einem **IF-Node**. Nutzen Sie `$runIndex`, um die Loop-Durchläufe innerhalb der Execution zu zählen — ein separater Zähler ist nicht nötig: ```javascript IF-Bedingung (max. 4 Retries) theme={null} {{ $runIndex < 4 }} ``` Verbinden Sie den True-Output des IF-Nodes mit einem **Wait-Node** und hinterlegen Sie die Wartezeit als Expression (siehe Backoff-Strategien unten). Verbinden Sie den Wait-Node zurück mit dem HTTP-Request-Node. Den False-Output des IF-Nodes verbinden Sie mit einem **Stop And Error**-Node (oder einer Benachrichtigung), damit der Workflow nach dem letzten Versuch sauber fehlschlägt. ### Backoff-Strategien für den Wait-Node **Exponential Backoff (empfohlen):** Die Wartezeit verdoppelt sich mit jedem Versuch — das gibt überlasteten Servern Zeit zur Erholung. Ergibt 1 s → 2 s → 4 s → 8 s → …, gedeckelt bei 60 Sekunden: ```javascript Wait Amount (Sekunden) theme={null} {{ Math.min(Math.pow(2, $runIndex), 60) }} ``` **Linear Backoff:** Die Wartezeit wächst gleichmäßig (5 s → 10 s → 15 s → …). Eine **konstante** Wartezeit erreichen Sie einfacher über das eingebaute Retry On Fail (Wait Between Tries): ```javascript Wait Amount (Sekunden) theme={null} {{ ($runIndex + 1) * 5 }} ``` **Jitter:** Zufällige Variation (±10–25 %) verhindert Thundering Herd — wenn viele Executions gleichzeitig fehlschlagen, retryen sie sonst alle im selben Moment: ```javascript Exponential Backoff mit ±25% Jitter (Sekunden) theme={null} {{ Math.min(Math.pow(2, $runIndex), 60) * (0.75 + Math.random() * 0.5) }} ``` ### Selektiver Retry nach Fehlertyp Werten Sie im IF-Node zusätzlich die Fehlerdaten aus dem Error-Output aus, um nur retryable Fehler zu wiederholen: ```javascript IF-Bedingung: nur bei Rate Limit retryen theme={null} {{ $runIndex < 4 && $json.error.message.includes('429') }} ``` **Retry-After-Header respektieren:** Bei `429`-Antworten liefern viele APIs einen `Retry-After`-Header mit der empfohlenen Wartezeit. Konfigurieren Sie den HTTP-Request-Node über die Response-Optionen so, dass er die vollständige Response inklusive Header und Statuscode ausgibt (statt bei Fehlern abzubrechen). Prüfen Sie dann im IF-Node den Statuscode und übernehmen Sie die Wartezeit in den Wait-Node: ```javascript Wait Amount aus Retry-After-Header (Sekunden) theme={null} {{ Number($json.headers['retry-after']) || 60 }} ``` **Zustand über Executions hinweg:** Für Zustand, der **mehrere Executions** überdauern soll (z. B. „wie oft ist dieser Workflow heute schon fehlgeschlagen?"), bietet Automate **Workflow Static Data**. Zugriff im **Code**-Node über `$getWorkflowStaticData()` — beachten Sie, dass Static Data nur bei Production-Executions (aktivierter Workflow) gespeichert wird; bei manuellen Test-Ausführungen im Editor gehen Änderungen verloren: ```javascript Fehlversuche über Executions zählen (Code-Node) theme={null} const staticData = $getWorkflowStaticData('global'); staticData.failCount = (staticData.failCount || 0) + 1; return [{ json: { failCount: staticData.failCount } }]; ``` ## Best Practices * **Max Retries begrenzen:** typisch 3–5 Versuche — zu viele Retries erhöhen Kosten, unendliche Loops sind zu vermeiden. * **Exponential Backoff mit Jitter verwenden:** das Standard-Pattern — schont Server und verteilt Last gleichmäßig. * **Retryable von non-retryable Fehlern unterscheiden:** siehe Tabelle oben — 4xx-Fehler meist nicht wiederholen. * **Timeouts ausbalancieren:** zu kurze Timeouts erzeugen unnötige Retries, zu lange verzögern die Fehlerbehandlung. * **Fehler protokollieren:** den Error-Workflow als Logging-Punkt nutzen — Fehlermeldung und Workflow-Name in ein externes Ziel schreiben (z. B. Datenbank oder Chat-Kanal). * **Retry-Strategie dokumentieren** — für zukünftige Wartung. ## Retry-Versuche nachvollziehen (DIY-Logging) Automate hat **kein eingebautes Retry-Metriken-Dashboard**. Zum Nachvollziehen von Fehlern und Wiederholungen nutzen Sie: * **Executions-Liste:** zeigt Status und Dauer jeder Ausführung. Filtern Sie nach fehlgeschlagenen Executions, um Problemfälle zu finden. * **Error-Workflow als Logging-Punkt:** schreiben Sie Fehlermeldung, Workflow-Name und Zeitstempel in ein externes Ziel Ihrer Wahl (z. B. Datenbank, Spreadsheet oder Chat-Kanal) — ein selbstgebautes Pattern, das Sie an Ihre Umgebung anpassen. * **Eigene Auswertung:** wenn Sie Executions über die Web-App hinaus auswerten möchten — etwa programmatisch — siehe [Automate-API](/administration/api). ## Praktisches Beispiel: API-Call absichern 1. **Retry On Fail aktivieren:** HTTP-Request-Node → **Settings** → **Retry On Fail** einschalten, **Max Tries** auf 3, **Wait Between Tries** auf 2000 ms. 2. **Error-Workflow anlegen:** Fehlerbehandlungs-Workflow mit **Error Trigger** → Benachrichtigung (z. B. E-Mail an das Team) → Logging-Schritt. 3. **Error-Workflow zuweisen:** in den **Workflow-Einstellungen** des Produktiv-Workflows unter **Error Workflow**. 4. **Bei Bedarf: Retry-Loop ergänzen:** wenn die API häufig mit 429 antwortet, den selbstgebauten Retry-Loop mit Exponential Backoff bauen — Retry On Fail allein wartet nur konstant. 5. **Ergebnis prüfen:** in der Executions-Liste kontrollieren, ob fehlgeschlagene Ausführungen zurückgehen und der Error-Workflow bei echten Fehlern anspringt. ## Checkliste * [ ] Retry On Fail ist für fehleranfällige Nodes aktiviert * [ ] Max Tries ist begrenzt (3-5) * [ ] Ein Error-Workflow ist angelegt und zugewiesen * [ ] Bei Bedarf: Retry-Loop mit Exponential Backoff und Jitter gebaut * [ ] Retryable/Non-Retryable Fehler werden unterschieden (im DIY-Loop) * [ ] Retry-After-Header wird respektiert * [ ] Fehler werden über den Error-Workflow protokolliert (DIY) * [ ] Executions-Liste wird regelmäßig auf Fehler geprüft ## Nächste Schritte Workflows über die Web-App verwalten und programmatisch mit Localmind verbinden. Erfahren Sie mehr über umfassendes Error Handling und Fehlersuche. Kombinieren Sie Retry-Logik mit Batch-Verarbeitung. Optimieren Sie Ihre Workflows für schnellere Ausführung. # Automate Basics Source: https://docs.localmind.ai/automate/basics Nodes, Trigger und Expressions: Ihr erster Automate-Workflow von Konzept bis Aktivierung. **Automate** ist die Workflow-Automatisierungsplattform von Localmind. Sie erstellen damit visuelle Workflows, die externe Dienste, APIs und Ihre Localmind-Agenten miteinander verbinden — durch das Verbinden von Nodes, ohne Code zu schreiben. Hunderte Integrationen (Slack, Google Sheets, beliebige APIs) stehen bereit, und Ihre Localmind-Agenten binden Sie direkt in Workflows ein. Automate läuft in Ihrem Localmind-Deployment; welche Varianten es gibt, lesen Sie unter [Hosting-Optionen](/pricing/Hosting-Options). ## Erste Schritte 1. **Öffnen Sie die App „Automatisierung"** in Ihrem Space. 2. **Klicken Sie auf „Neuer Workflow"**, um Ihren ersten Workflow zu erstellen. 3. **Wählen Sie eine Vorlage** oder starten Sie mit einem leeren Workflow — wenn Sie neu bei Automate sind, helfen die vorgefertigten Vorlagen beim Verstehen der Konzepte. ## Grundkonzepte ### Nodes **Nodes** sind die Bausteine Ihrer Workflows. Jeder Node repräsentiert eine Aktion oder einen Schritt im Automatisierungsprozess. **Trigger Nodes** starten Ihren Workflow automatisch: * **Webhook:** empfängt HTTP-Anfragen * **Schedule:** zeitbasierte Ausführung (Cron) * **Manual:** manuelle Ausführung * **Email:** E-Mail-basierte Trigger **Action Nodes** führen Operationen aus: * **HTTP Request:** API-Aufrufe — darüber rufen Sie auch Localmind-Agenten auf * **Set:** Daten setzen/transformieren * **IF:** bedingte Logik * **Switch:** Multi-Branch-Logik ### Localmind-Agenten aufrufen Einen dedizierten Agent-Node gibt es nicht — Sie rufen Localmind-Agenten über die **HTTP Request Node** auf: * **Endpoint:** `POST https://-api.localmind.ai/v1/chat/completions` * **Auth:** Header `Authorization: Bearer ` (als n8n-Credential vom Typ Header Auth) * **Agent-Auswahl:** das `model`-Feld im Body trägt die Agent-UUID aus `GET /v1/models` ```json Request-Body theme={null} { "model": "", "messages": [ { "role": "user", "content": "{{ $json.userQuery }}" } ], "stream": false } ``` Die Antwort lesen Sie in Folge-Nodes über `{{ $json.choices[0].message.content }}` aus, den Token-Verbrauch über `{{ $json.usage.total_tokens }}`. Die vollständige Anleitung inklusive Stolperfallen finden Sie unter [Localmind Agent in n8n einbinden](/automate/Localmind-Agent). ### Workflow-Struktur Ein typischer Workflow folgt diesem Muster: ``` Trigger → Datenverarbeitung → Agent-Aufruf → Aktion → Ausgabe ``` Klicken Sie auf **„Neuer Workflow"**, vergeben Sie einen Namen (z.B. „Kundenanfrage verarbeiten") und wählen Sie einen Trigger-Node — für Tests zunächst einen **Manual Trigger**, später stellen Sie auf einen automatischen Trigger um. Über das **„+"**-Symbol suchen Sie den gewünschten Node (z.B. „HTTP Request"), ziehen ihn auf das Canvas und verbinden Nodes durch Ziehen von den Ausgängen zu den Eingängen. Achten Sie darauf, dass die Datenformate zwischen Nodes kompatibel sind — zur Umwandlung nutzen Sie Set-Nodes. Klicken Sie auf einen Node, füllen Sie die erforderlichen Felder aus und testen Sie mit **„Execute Node"**. Für dynamische Werte verwenden Sie **Expressions** (`{{ }}`): ```javascript Expression Beispiel theme={null} // Zugriff auf vorherige Node-Daten {{ $json.fieldName }} // Zugriff auf Workflow-Daten {{ $workflow.staticData.value }} // Funktionen verwenden {{ $now.toISO() }} {{ $json.text.toUpperCase() }} // JSON Stringify - Objekte in Strings umwandeln {{ JSON.stringify($json) }} {{ JSON.stringify($json.user) }} ``` Testen Sie den Workflow gründlich (siehe [Testing](/automate/testing)), bevor Sie den **„Active"**-Toggle oben rechts einschalten. Für Production konfigurieren Sie einen automatischen Trigger und überwachen Ausführungen im **„Executions"**-Tab. ## Praktisches Beispiel: E-Mail-zu-Agent-Workflow Ein Workflow, der E-Mails empfängt, sie an einen Localmind-Agenten weiterleitet und eine Antwort sendet: ``` Email Trigger → Set Node → HTTP Request (Localmind Agent) → HTTP Request (Send Email) ``` ### 1. Email Trigger konfigurieren Fügen Sie einen **IMAP Email**-Node hinzu, konfigurieren Sie die Credentials (IMAP-Server, Benutzername, Passwort) und setzen Sie das Polling-Intervall (z.B. jede Minute). Optional filtern Sie auf bestimmte Absender. ### 2. Daten vorbereiten (Set Node) Strukturieren Sie mit einem **Set**-Node die Daten für den Agenten: * `emailSubject`: `{{ $json.subject }}` * `emailBody`: `{{ $json.textPlain }}` * `senderEmail`: `{{ $json.from.value[0].address }}` * `timestamp`: `{{ $now.toISO() }}` ### 3. Localmind Agent aufrufen (HTTP Request) Konfigurieren Sie einen **HTTP Request**-Node: Methode **POST**, URL `https://-api.localmind.ai/v1/chat/completions`, Authentication über ein Header-Auth-Credential mit `Authorization: Bearer `. Im Body trägt `model` die Agent-UUID aus `GET /v1/models`: ```json Request-Body theme={null} { "model": "", "messages": [ { "role": "system", "content": "Du bist ein hilfreicher E-Mail-Assistent. Analysiere die folgende E-Mail und erstelle eine professionelle Antwort." }, { "role": "user", "content": "Betreff: {{ $json.emailSubject }}\nNachricht: {{ $json.emailBody }}\nAbsender: {{ $json.senderEmail }}" } ], "stream": false } ``` Details zu Auth, Base-URL und Stolperfallen: [Localmind Agent in n8n einbinden](/automate/Localmind-Agent). ### 4. Antwort senden (HTTP Request) Ein zweiter **HTTP Request**-Node sendet die Antwort per **POST** an Ihre E-Mail-API (z.B. SendGrid, Mailgun). Mit `$('NodeName')` greifen Sie auf Daten früherer Nodes zu: ```json theme={null} { "to": "{{ $('Set').item.json.senderEmail }}", "subject": "Re: {{ $('Set').item.json.emailSubject }}", "text": "{{ $json.choices[0].message.content }}" } ``` ## Häufige Patterns ### Pattern 1: Bedingte Verarbeitung Verwenden Sie **IF Nodes** für bedingte Logik: ``` Trigger → IF (Bedingung) → [True Branch] → [False Branch] ``` ```javascript IF Bedingung Beispiel theme={null} // Prüfe ob E-Mail wichtig ist {{ $json.importance === 'high' }} // Prüfe ob Betreff bestimmtes Keyword enthält {{ $json.subject.includes('URGENT') }} // Prüfe ob Absender in Whitelist {{ ['admin@company.com', 'support@company.com'].includes($json.senderEmail) }} ``` ### Pattern 2: Verzweigte Verarbeitung Ein Node kann mehrere ausgehende Verbindungen haben. n8n führt die Branches **nacheinander** aus (nicht parallel) — jeder Branch erhält aber dieselben Input-Daten und arbeitet unabhängig weiter: ``` Trigger → [Branch 1] → Agent 1 → [Branch 2] → Agent 2 → [Branch 3] → Agent 3 ``` ### Pattern 3: Error Handling Implementieren Sie in jedem Produktiv-Workflow eine Fehlerbehandlung — der **Error Trigger**-Node ist dafür der zentrale Baustein (siehe [Retry Logic](/automate/Retry-Logic)): ``` Workflow → Try/Catch → Error Trigger → Notification ``` ### Pattern 4: Daten stringifyen Wenn eine API oder ein Textfeld einen **String** statt eines JSON-Objekts erwartet, wandeln Sie Objekte mit `JSON.stringify()` um — und mit `JSON.parse()` wieder zurück. Für einfache Werte (Strings, Zahlen) ist das unnötig; nutzen Sie es gezielt dort, wo eine Gegenstelle JSON-Strings erwartet — etwa HTTP-Request-Bodies, Logging oder Webhook-Payloads: ```javascript Expression-Beispiele theme={null} // Objekt als JSON-String übergeben (z.B. im HTTP Request Body) {{ JSON.stringify($json) }} // Einzelnes Feld stringifyen {{ JSON.stringify($json.user) }} // String zurück in ein Objekt wandeln {{ JSON.parse($json.jsonString) }} ``` ## Best Practices ### 1. Use Case First, Workflow Second Beginnen Sie mit der Problemdefinition, nicht mit der Implementierung — der Workflow passt sich an Ihre Anforderungen an, nicht umgekehrt: 1. **Geschäftsproblem definieren** — z.B. „Automatische Kategorisierung von Support-E-Mails mit Weiterleitung dringender Anfragen an das Support-Team." 2. **Input und Output spezifizieren** — Input: E-Mail mit Betreff, Absender, Inhalt. Output: Kategorisierung (dringend/normal) mit entsprechender Weiterleitung. 3. **Logische Schritte identifizieren** — den Prozess in 3–5 Verarbeitungsschritte zerlegen (E-Mail empfangen → mit Agent analysieren → kategorisieren → bei „dringend" benachrichtigen). 4. **Nodes auswählen** — basierend auf den definierten Schritten. Starten Sie mit einer einfachen Implementierung und iterieren Sie anhand der Ergebnisse. ### 2. Vorlagen und bestehende Lösungen nutzen Durchsuchen Sie vor der Implementierung die Automate-Vorlagenbibliothek und Community-Beispiele für ähnliche Use Cases. Das beschleunigt die Entwicklung durch bewährte Patterns, zeigt Ihnen neue Nodes und Implementierungsansätze und vermeidet bekannte Fehlerquellen. ### 3. Data Flow Principle verstehen Jeder Automate-Workflow folgt dem Prinzip **Input → Transform → Output**. Häufige Datenquellen sind eigene Datenbanken (Airtable, Google Sheets, Supabase) und öffentliche APIs (HTTP Request Node, dedizierte API-Nodes). Für HTTP Request Nodes hat sich dieser Ablauf bewährt: cURL-Befehl aus der API-Dokumentation kopieren, in Postman importieren und mit realen Parametern testen, Funktionalität für Ihren Use Case verifizieren — und erst dann den validierten Request nach Automate übertragen. Postman erleichtert Testen und Debugging von API-Requests erheblich. ### 4. Kern-Nodes beherrschen Die meisten Workflows kommen mit wenigen Nodes aus: * **Set/Edit Fields:** Spalten extrahieren, Datentypen konvertieren, Datenstrukturen anpassen * **Filter:** ungültige Datensätze entfernen (null-Werte, Duplikate, Formatfehler) * **Merge:** Spalten hinzufügen oder Datensätze kombinieren * **Code:** komplexe Transformationen, die mit Standard-Nodes nicht möglich sind — KI-Assistenten können den Code aus Input-Struktur und gewünschtem Output generieren * **IF:** bedingte Verarbeitungslogik * **HTTP Request (Localmind Agent):** für die meisten KI-basierten Aufgaben — der Agent-Aufruf läuft über `POST /v1/chat/completions`, siehe [Localmind Agent in n8n einbinden](/automate/Localmind-Agent) Typisches Workflow-Pattern: ``` HTTP Request → Set (Datenbereinigung) → Filter (Validierung) → Agent (Analyse) → Set (Output-Formatierung) → Datenbank-Insert ``` ### 5. Node-Outputs pinnen für effizientes Testing Führen Sie den Workflow einmal vollständig aus, pinnen Sie die Outputs über das Pin-Icon und testen Sie nachgelagerte Nodes ohne erneute API-Calls oder KI-Verarbeitung. Gepinnte Daten können Sie bearbeiten, um verschiedene Szenarien inklusive Edge Cases zu simulieren. **Kostenoptimierung:** Jeder Test eines Agent-Aufrufs ohne Pinning verbraucht Credits. Bei wiederholten Tests summiert sich das erheblich. Pinnen Sie Outputs immer für Testzwecke. ### 6. Sub-Workflows für modulare Architektur Teilen Sie komplexe Workflows in wiederverwendbare Sub-Workflows auf: Haupt-Workflows enthalten maximal 4–6 Nodes, häufig verwendete Funktionalität (Datenbereinigung und Validierung, Error Handling und Retry-Logik, Benachrichtigungen) wandert in Sub-Workflows in einem dedizierten Components-Ordner. Das macht Fehler schnell auf einen Sub-Workflow eingrenzbar, Komponenten in verschiedenen Workflows wiederverwendbar und Haupt-Workflows übersichtlich. ### 7. Umfassendes Error Logging implementieren Loggen Sie bei Fehlern alle relevanten Informationen: Fehlermeldung und Fehlertyp, Fehlerstelle (Node-Name, Execution-ID), Input-Daten, die den Fehler verursacht haben, Zeitstempel und Workflow-Kontext sowie Retry-Versuche und deren Ergebnisse. Loggen Sie auch erfolgreiche Executions — das ermöglicht Berichte über Workflow-Performance und macht Trends sichtbar. ### 8. Credit-Verbrauch überwachen Agent-Aufrufe werden in Localmind in **Credits** abgerechnet. Damit Automatisierungen kalkulierbar bleiben: Prüfen Sie den Token-Verbrauch pro Execution (`usage.total_tokens` der Agent-Antwort), identifizieren Sie Verbrauchstreiber (lange Prompts, große Kontexte, unnötige Wiederholungs-Aufrufe) und pinnen Sie beim Testen die Outputs (Best Practice 5). Loggen Sie den Token-Verbrauch von Anfang an mit — unerwarteter Credit-Verbrauch beeinträchtigt das Vertrauen in Automatisierungen. Weiterführend: [Testing](/automate/testing) (jeden Node einzeln testen), [Performance](/automate/performance) (API-Calls, Caching, Timeouts) und [Sicherheit](/automate/security) (Credentials sicher speichern, Environment Variables für sensible Daten). ## Debugging Die häufigsten Probleme in Kürze — mehr in der [Debugging-Anleitung](/automate/debugging): * **Workflow läuft nicht** — „Active"-Toggle, Trigger-Konfiguration und Credentials prüfen. * **Daten kommen nicht korrekt an** — Expression-Syntax (`{{ $json.fieldName }}`) und Datenformate zwischen Nodes prüfen. * **Agent antwortet nicht** — Agent-UUID im `model`-Feld gegen `GET /v1/models` abgleichen, Base-URL (`-api`-Host statt `-app`) und API-Key-Scope prüfen — Details unter [Localmind Agent in n8n einbinden](/automate/Localmind-Agent#stolperfallen). Zur Analyse nutzen Sie die Execution Logs: Im **„Executions"**-Tab eine fehlgeschlagene Execution auswählen, auf jeden Node klicken, um Input/Output zu sehen, und die Error-Messages lesen. Aktivieren Sie „Save Data on Error" in den Workflow-Einstellungen, um Debugging zu erleichtern. ## Nächste Schritte Erstellen Sie eigene Nodes für spezifische Anwendungsfälle. Endpoint-Referenz und Code-Beispiele für Integrationen. Bei Fragen zur Einrichtung Ihrer ersten Workflows hilft unser Support-Team unter [support@localmind.ai](mailto:support@localmind.ai). # Batching Source: https://docs.localmind.ai/automate/batching Batch-Verarbeitung von Items in Automate-Workflows Batch-Verarbeitung fasst mehrere Items zu Gruppen zusammen und verarbeitet sie gemeinsam, statt jeden Datensatz einzeln zu behandeln. Statt drei einzelner API-Calls für drei Items genügt ein Batch-Request — das reduziert API-Calls, hilft Rate Limits einzuhalten und senkt Kosten. Besonders lohnt sich Batching bei großen Datenmengen und bei APIs mit Rate Limits. ## Loop Over Items Node Der Loop Over Items Node (in älteren n8n-Versionen „Split In Batches" genannt) teilt Items in kleinere Gruppen auf. Ein typischer Batch-Workflow: ``` Trigger → Loop Over Items → Process Batch → Merge Results ``` Mit `batchSize: 10` werden aus 30 Input-Items drei Batches zu je 10 Items: ```json Loop Over Items Konfiguration theme={null} { "batchSize": 10, "options": {} } ``` ### Batch-Größe bestimmen Die optimale Batch-Größe hängt von den API-Rate-Limits (z.B. 100 Requests/Minute), der maximalen Batch-Größe der API (z.B. 50 Items), der Verarbeitungszeit pro Batch und den Memory-Limits ab. | Batch-Größe | Geeignet für | | -------------- | -------------------------------------------- | | Klein (5-10) | Schnelle APIs, niedrige Rate Limits | | Mittel (10-50) | Standard für die meisten APIs | | Groß (50-100) | APIs mit hohen Limits, wenn Memory ausreicht | Beginnen Sie mit Batch-Größe 10-20 und passen Sie basierend auf Performance und Rate Limits an. ## Batch-API-Calls ### Batch POST Request Senden Sie mehrere Items in einem Request. `$input.all()` liefert alle Items des aktuellen Node-Inputs; Items eines bestimmten vorherigen Nodes erreichen Sie mit `$('Node Name').all()`. ```json HTTP Request Konfiguration theme={null} { "method": "POST", "url": "https://api.example.com/batch", "body": { "items": "={{ $input.all().map(item => item.json) }}" } } ``` ```json Request Body theme={null} { "items": [ { "id": 1, "name": "Item 1" }, { "id": 2, "name": "Item 2" }, { "id": 3, "name": "Item 3" } ] } ``` ### Batch GET Request Mehrere IDs in einem Request — die URL wird damit z.B. zu `https://api.example.com/items?ids=1,2,3,4,5`: ```json Batch GET theme={null} { "method": "GET", "url": "https://api.example.com/items", "qs": { "ids": "={{ $input.all().map(item => item.json.id).join(',') }}" } } ``` ### Code-Node für Batch-Verarbeitung Für komplexe Batch-Logik nutzen Sie den Code-Node: ```javascript Batch verarbeiten theme={null} // Alle Items aus Batch abrufen const items = $input.all(); // Batch-Request vorbereiten const batchData = { items: items.map(item => ({ id: item.json.id, name: item.json.name, status: item.json.status })) }; // API-Call (wird in nächstem Node gemacht) return [{ json: { batch: batchData, batchSize: items.length, timestamp: new Date().toISOString() } }]; ``` ```javascript Batch-Ergebnisse verarbeiten theme={null} // Batch-Response verarbeiten const batchResponse = $json.batchResponse; // Ergebnisse auf einzelne Items aufteilen const results = batchResponse.results.map((result, index) => { return { json: { originalId: $input.all()[index].json.id, processedId: result.id, status: result.status, processedAt: new Date().toISOString() } }; }); return results; ``` ## Rate Limit Management Batching reduziert die Request-Zahl direkt: Erlaubt eine API 100 Requests pro Minute und Ihr Workflow verarbeitet 1000 Items, brauchen Sie ohne Batching 1000 Requests (10 Minuten) — mit Batches à 10 Items nur 100 Requests (1 Minute). Automate hat keinen dedizierten Rate-Limit-Node. Das etablierte Muster für kontrollierte Request-Raten kombiniert den Loop Over Items Node mit einem Wait-Node in der Schleife: ``` Loop Over Items → Process Batch → Wait → zurück zu Loop Over Items ``` * Der Loop Over Items Node gibt pro Durchlauf einen Batch aus * Der Wait-Node pausiert nach jedem Batch für eine feste Zeit * Die Rückverbindung zum Loop Over Items Node startet den nächsten Batch **Beispiel:** Erlaubt die API 100 Requests pro Minute, wählen Sie `batchSize: 10` und eine Wait-Dauer von 6 Sekunden — so bleiben Sie bei maximal 100 Requests pro Minute. ## Parallele Batch-Verarbeitung Sie können Batches auf mehrere Branches verteilen und die Ergebnisse anschließend zusammenführen: ``` Loop Over Items → [Branch 1] → Process Batch 1 ┐ → [Branch 2] → Process Batch 2 ├→ Merge → [Branch 3] → Process Batch 3 ┘ ``` Achten Sie dabei auf Rate Limits — parallele Verarbeitung kann sie schneller erreichen. Die Parallelität begrenzen Sie mit einem Code-Node: ```javascript Code-Node für Parallelität theme={null} const batches = $input.all(); const maxParallel = 3; // Maximal 3 Batches gleichzeitig // Batches in Gruppen aufteilen const groups = []; for (let i = 0; i < batches.length; i += maxParallel) { groups.push(batches.slice(i, i + maxParallel)); } return groups.map(group => ({ json: { batches: group, groupIndex: groups.indexOf(group) } })); ``` ## Batch-Fehlerbehandlung ### Partielle Fehler Wenn einzelne Items in einem Batch fehlschlagen, trennen Sie erfolgreiche und fehlerhafte Items und behandeln letztere separat (Error Trigger): ```javascript Fehlerbehandlung theme={null} const batchResponse = $json.batchResponse; const results = []; const errors = []; batchResponse.results.forEach((result, index) => { if (result.success) { results.push({ json: { ...result.data, processed: true } }); } else { errors.push({ json: { originalItem: $input.all()[index].json, error: result.error, retry: true } }); } }); // Erfolgreiche Items zurückgeben return results; // Fehlerhafte Items separat behandeln (Error Trigger) ``` ### Retry-Logik für Batches Fehlgeschlagene Batches versuchen Sie erneut (`Process Batch → Error Trigger → Retry Logic → Process Batch`): ```javascript Retry mit Exponential Backoff theme={null} const maxRetries = 3; const retryCount = $workflow.staticData.retryCount || 0; if (retryCount < maxRetries) { const delay = Math.pow(2, retryCount) * 1000; // 1s, 2s, 4s // Wartezeit einbauen await new Promise(resolve => setTimeout(resolve, delay)); $workflow.staticData.retryCount = retryCount + 1; // Batch erneut verarbeiten return $input.all(); } else { // Max Retries erreicht, Fehler loggen throw new Error('Batch processing failed after retries'); } ``` ## Praxisbeispiel: E-Mail-Versand in Batches 100 E-Mails sollen versendet werden. Der Loop Over Items Node (`batchSize: 20`) erzeugt fünf Batches zu je 20 E-Mails; jeder Batch geht als ein Request an die E-Mail-API, ein Merge führt die Ergebnisse für das Success/Error-Tracking zusammen: ```json HTTP Request an E-Mail-API theme={null} { "method": "POST", "url": "https://api.email-service.com/batch", "body": { "emails": "={{ $input.all().map(item => item.json) }}" } } ``` ## Best Practices * **Batch-Größe optimieren:** an API-Limits, Verarbeitungszeit, Memory-Verfügbarkeit und Rate Limits ausrichten. * **Fehlerbehandlung:** partielle Fehler behandeln, Retry-Logik für fehlgeschlagene Batches, Fehler-Logging. * **Rate Limits respektieren:** mit Loop Over Items + Wait-Node drosseln, Backoff implementieren, Request-Rate überwachen. * **Monitoring:** Batch-Größe, Verarbeitungszeit und Fehlerrate im Blick behalten. * **Memory-Management:** keine zu großen Batches, Ergebnisse früh ausgeben, unnötige Daten entfernen. * **Testing:** mit verschiedenen Batch-Größen, Edge Cases (leere und sehr große Batches) und Fehler-Szenarien testen. ## Checkliste * [ ] Batch-Größe ist optimiert für API-Limits * [ ] Rate Limits werden eingehalten * [ ] Fehlerbehandlung ist implementiert * [ ] Retry-Logik für fehlgeschlagene Batches * [ ] Memory-Verbrauch ist akzeptabel * [ ] Performance wird überwacht * [ ] Edge Cases wurden getestet ## Nächste Schritte Retry-Logik für fehlgeschlagene Batches implementieren. Batch-Verarbeitung für bessere Performance optimieren. Items effektiv verwalten. Batch-Workflows gründlich testen. # Debugging Source: https://docs.localmind.ai/automate/debugging Debugging-Techniken und Fehlerbehebung für Automate-Workflows Wenn ein Workflow nicht das tut, was er soll, führt der Weg fast immer über dieselbe Methode: Execution Logs lesen, das Problem isolieren, Nodes einzeln testen. Diese Seite zeigt das Vorgehen und die häufigsten Fehlerbilder samt Lösung. ## Execution Logs Execution Logs sind die wichtigste Informationsquelle beim Debugging. Sie öffnen sie über den Tab **Executions**: Execution auswählen, anklicken und die einzelnen Nodes öffnen. Pro Node sehen Sie: * **Input:** Daten, die der Node empfangen hat * **Output:** Daten, die der Node produziert hat * **Execution Time:** wie lange der Node gebraucht hat * **Status:** Erfolg oder Fehler * **Error Messages:** detaillierte Fehlermeldungen Fehler erkennen Sie an roten Nodes (fehlgeschlagen), gelben Nodes (Workflow wartet), fehlenden Verbindungen, Timeout-Meldungen und API-Fehlern (4xx, 5xx). Filtern Sie die Executions-Liste nach fehlgeschlagenen Executions — das beschleunigt die Suche deutlich. ## Häufige Probleme und Lösungen ### Workflow läuft nicht | Ursache | Lösung | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Workflow ist nicht aktiviert | Prüfen Sie den **Active**-Toggle oben rechts und die Trigger-Konfiguration. | | Trigger nicht konfiguriert | Trigger-Konfiguration prüfen, Trigger manuell testen, Credentials für den Trigger (z.B. IMAP) sowie Webhook-URL und Secret validieren. | | Credentials fehlen oder sind abgelaufen | Credentials in den Node-Einstellungen prüfen und einzeln testen; auch Environment Variables kontrollieren. | ### Daten werden nicht korrekt übergeben | Ursache | Lösung | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Falsche Expression-Syntax | Syntax prüfen (`{{ $json.fieldName }}`) — Feldnamen sind case-sensitive. Expressions im Expression-Editor validieren und mit **Execute Node** testen. | | Datenformat-Inkompatibilität | Datenformate zwischen Nodes prüfen, mit Set Nodes transformieren, mit JSON Schema validieren; tatsächliche Formate in den Execution Logs nachsehen. | | Node-Reihenfolge falsch | Workflow-Struktur prüfen: Daten-Nodes müssen vor den Nodes kommen, die die Daten verwenden. Set Nodes zur Datenvorbereitung nutzen. | Korrekte Expression-Syntax im Überblick: ```javascript Korrekte Syntax theme={null} // Zugriff auf vorherige Node-Daten {{ $json.email }} {{ $json.user.name }} // Zugriff auf spezifischen Node {{ $('Node Name').item.json.field }} // Funktionen {{ $json.text.toUpperCase() }} {{ $now.toISO() }} ``` ### Agent gibt keine Antwort Localmind-Agenten rufen Sie über die **HTTP Request Node** gegen `POST /v1/chat/completions` auf ([Anleitung](/automate/Localmind-Agent)) — die häufigsten Fehlerquellen liegen im Request selbst: | Symptom | Lösung | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `404 {"detail":"Model '…' not found"}` | Das `model`-Feld im Request-Body muss eine **Agent-UUID** aus `GET /v1/models` enthalten, kein Modellname wie `gpt-4`. UUID gegen die Ausgabe von `GET /v1/models` abgleichen. Agenten außerhalb des API-Key-Scopes erscheinen dort nicht und sind nicht aufrufbar. | | 404 auf die URL selbst | Host prüfen: aus dem Browser kopierte URLs enthalten `-app` — ersetzen Sie `-app` durch `-api`. Pfad exakt `/v1/chat/completions` (mit `/v1`-Prefix). | | `401 Unauthorized` / Agent nicht sichtbar in `GET /v1/models` | Header-Auth-Credential prüfen: `Authorization: Bearer ` — das `Bearer `-Präfix nicht vergessen. Key-Scope prüfen: ist er auf Spaces beschränkt, die den Agenten nicht enthalten? | Alle Stolperfallen beim Agent-Aufruf im Detail: [Localmind Agent in n8n einbinden](/automate/Localmind-Agent#stolperfallen). ## Debugging-Techniken ### Nodes einzeln testen 1. Node öffnen, Test-Daten verwenden und auf **Execute Node** klicken. 2. Input prüfen: Datenformat validieren, auf fehlende Felder achten. 3. Output prüfen: erwartetes Format validieren, auf unerwartete Werte achten. ### Den gesamten Workflow debuggen 1. Aktivieren Sie **Save Data on Error** in den Workflow-Einstellungen — so bleiben Input/Output-Daten auch bei Fehlern für die Analyse erhalten. 2. Führen Sie den Workflow mit realistischen Test-Daten aus, damit das Fehlerbild dem Produktivbetrieb entspricht. 3. Identifizieren Sie in den Execution Logs die fehlgeschlagenen Nodes. 4. Testen Sie jeden Fix isoliert mit **Execute Node**, bevor Sie den nächsten angehen. 5. Führen Sie abschließend den gesamten Workflow erneut aus, um Seiteneffekte auszuschließen. ### Debug-Logging hinzufügen ```javascript Debug-Logging theme={null} // Log wichtige Werte (Code Node: $json direkt, ohne Expression-Klammern) console.log('User ID:', $json.userId); console.log('Email:', $json.email); console.log('Processing step:', 'email-sent'); // Log in Set Node { "debug": { "step": "before-agent-call", "data": "={{ $json }}", "timestamp": "={{ $now.toISO() }}" } } ``` ## Debugging-Features in Automate | Feature | Zweck | | ---------------------- | ------------------------------------------------ | | **Execute Node** | Einzelne Nodes mit Test-Daten testen | | **Execution Logs** | Detaillierte Logs für jede Execution | | **Save Data on Error** | Speichert Daten auch bei Fehlern für die Analyse | | **Expression Editor** | Validiert Expressions vor der Ausführung | ## Häufige Fehlermeldungen | Fehlermeldung | Lösung | | --------------------------- | ---------------------------------------------------------------------------------------------- | | `Request timeout after 30s` | Timeout-Wert erhöhen, API-Call optimieren, [Retry-Logik](/automate/Retry-Logic) implementieren | | `401 Unauthorized` | Credentials prüfen, Token-Ablauf prüfen, API-Key-Format validieren | | `Invalid data format` | Datenformat prüfen, mit Set Node transformieren, mit JSON Schema validieren | ## Debugging-Checkliste * [ ] Execution Logs wurden überprüft * [ ] Fehlgeschlagene Nodes wurden identifiziert * [ ] Jeder fehlgeschlagene Node wurde einzeln getestet * [ ] Input/Output-Daten wurden validiert * [ ] Expressions wurden auf Syntax-Fehler geprüft * [ ] Datenformate wurden überprüft * [ ] Credentials wurden validiert * [ ] Error Messages wurden gelesen und verstanden Weiterführend: [Testing](/automate/testing) und [Performance](/automate/performance). # Automate im Überblick Source: https://docs.localmind.ai/automate/overview Was der Automate-Bereich ist und wie die Automate-Dokumentation aufgebaut ist — von den Grundlagen bis zum Betrieb. **Automate** ist die n8n-basierte Workflow-Engine von Localmind. Sie erstellen damit visuelle Workflows, die Trigger, externe Dienste und Ihre Localmind-Agenten zu automatisierten Abläufen verbinden — direkt im Bereich **Automatisierung** der Localmind-Web-App, ohne separate Installation. Ein Workflow besteht aus **Nodes**: Ein Trigger (z.B. ein Webhook oder ein Zeitplan) startet den Ablauf, nachfolgende Nodes transformieren Daten, rufen APIs auf oder binden einen Localmind-Agenten für KI-gestützte Schritte ein. Jede Ausführung eines Workflows wird als **Execution** protokolliert. ## So finden Sie sich zurecht Nodes, Trigger und Verbindungen — die Kernkonzepte, mit denen Sie Ihren ersten Workflow erstellen. Localmind-Agenten per HTTP Request Node aus Ihren Workflows aufrufen und die Antworten weiterverarbeiten. Items sauber verarbeiten — mit [Batching](/automate/batching) für große Datenmengen und [Retry-Logik](/automate/Retry-Logic) für robuste Abläufe. Custom Nodes entwickeln, Workflows [testen](/automate/testing) und die [Performance](/automate/performance) optimieren. Workflows absichern, Fehler per [Debugging](/automate/debugging) eingrenzen, mit [Naming Conventions](/automate/Naming-Conventions) und [Versionierung](/automate/versioning) den Überblick behalten. Neu bei Automate? Beginnen Sie mit den [Grundlagen](/automate/basics) und rufen Sie danach in [Localmind anbinden](/automate/Localmind-Agent) Ihren ersten Agenten aus einem Workflow auf. Workflows, Executions und Webhooks verwalten Sie über die Web-App. Wie Sie Ihre Workflows programmatisch mit Localmind verbinden, beschreibt die Seite [Automate-API](/administration/api) im Administration-Tab. # Performance Source: https://docs.localmind.ai/automate/performance Performance-Optimierung für Automate-Workflows Optimieren Sie die Performance Ihrer Automate-Workflows für schnellere Ausführung und bessere Ressourcennutzung. Vier Hebel zählen: die Gesamtausführungszeit, das Datenvolumen, das durch den Workflow fließt, die Skalierbarkeit unter Last — und der Credits-Verbrauch, den weniger und gezieltere Agent-Aufrufe senken. ## Ausführung verschlanken Automate arbeitet die Nodes eines Workflows innerhalb einer Execution **sequenziell** ab — auch wenn Sie mehrere Branches nebeneinander zeichnen, laufen diese nacheinander. Echte parallele Ausführung innerhalb einer Execution gibt es nicht. Der wirksamste Hebel ist deshalb: weniger Arbeit pro Execution. * **Branches sind kein Beschleunigungs-Werkzeug:** Die Gesamtzeit ist die Summe aller Node-Zeiten. Nutzen Sie Branches für Logik (Fallunterscheidungen), nicht für Tempo. * **Unnötige Nodes vermeiden:** Jeder Node kostet Zeit. Konsolidieren Sie mehrere Transformations-Schritte in einem Node, entfernen Sie Nodes, deren Ergebnis nicht weiterverwendet wird, und prüfen Sie, ob Zwischenschritte wirklich nötig sind. * **Batching statt Einzel-Calls:** Verarbeiten Sie Items in Gruppen statt einzeln — das reduziert API-Calls und Ausführungszeit deutlich. Details und die Konfiguration des Loop-Over-Items-Nodes finden Sie unter [Batching](/automate/batching). ## Caching (DIY-Pattern) Automate bringt **keinen eingebauten Cache** mit — Caching ist ein selbstgebautes Pattern, das Sie mit Workflow Static Data (`$getWorkflowStaticData()`) oder einem externen Store (z. B. Redis oder einer Datenbank) umsetzen. Planen Sie zuerst, was gecacht werden darf: | Cachebar | Nicht cachebar | | ------------------------------------- | -------------------- | | User Data (TTL: 1 Stunde) | Real-time Data | | Product Information (TTL: 24 Stunden) | Transaction Data | | Configuration Settings (TTL: 1 Tag) | Personalized Content | Umsetzung mit Workflow Static Data in Code-Nodes: ```javascript Cache lesen (Code-Node vor dem API-Call) theme={null} const staticData = $getWorkflowStaticData('global'); const cacheKey = `user_${$json.userId}`; const TTL = 3600 * 1000; // 1 Stunde const cached = staticData[cacheKey]; if (cached && Date.now() - cached.storedAt < TTL) { // Cache-Treffer: gespeicherte Daten verwenden return [{ json: { ...cached.data, fromCache: true } }]; } // Cache-Miss: der nachfolgende Node führt den API-Call aus return [{ json: { ...$json, fromCache: false } }]; ``` ```javascript Cache schreiben (Code-Node nach dem API-Call) theme={null} const staticData = $getWorkflowStaticData('global'); const cacheKey = `user_${$json.userId}`; staticData[cacheKey] = { data: $json, storedAt: Date.now(), }; return $input.all(); ``` Workflow Static Data wird nur bei **Production-Executions** (aktivierter Workflow) gespeichert — bei manuellen Test-Ausführungen im Editor gehen Änderungen verloren. Für robusteres Caching über Workflow-Grenzen hinweg nutzen Sie einen externen Store. ## API-Optimierung | Technik | So funktioniert es | | ------------------------ | -------------------------------------------------------------------------------------------------- | | **Batch-Requests** | Ein Batch-Request mit 100 Items statt 100 Einzel-Requests — siehe [Batching](/automate/batching) | | **Pagination** | Große Datensätze seitenweise abrufen und verarbeiten (z.B. 100 Items pro Page) | | **Selective Fields** | Nur benötigte Felder anfordern: `GET /users?fields=id,name,email` statt `GET /users` | | **Conditional Requests** | ETags und Last-Modified Headers nutzen: `If-None-Match: "etag-value"`, `If-Modified-Since: "date"` | ## Timeout-Konfiguration | API-Typ | Timeout | Beschreibung | | ------------- | ------- | --------------------------------------------------- | | Schnelle APIs | 5 s | Lokale APIs, schnelle Services | | Standard-APIs | 30 s | Externe APIs, Standard-Services | | Langsame APIs | 60 s | Schwere Operationen, Batch-Processing | | Agent-Aufrufe | 45 s | Localmind Agent Aufrufe (unverbindlicher Richtwert) | Diese Werte sind **unverbindliche Richtwerte** aus der Praxis, keine garantierten Antwortzeiten. Die tatsächliche Dauer — insbesondere von Agent-Aufrufen — hängt von Modell, Prompt-Länge und Tool-Nutzung ab. Messen Sie Ihre realen Zeiten über die Executions-Liste und passen Sie die Timeouts entsprechend an. ## Datenfilterung Filtern Sie Daten so früh wie möglich im Workflow — das bedeutet weniger Daten zu verarbeiten, schnellere Ausführung und geringeren Speicherverbrauch: ```javascript Frühe Filterung theme={null} // Gut: Filtere früh Trigger → Filter (nur relevante Daten) → Process // Schlecht: Filtere spät Trigger → Process (alle Daten) → Filter → Output ``` Typische Ansatzpunkte: nach Status filtern vor der Verarbeitung, nach Datum vor dem API-Call, nach Typ vor der Transformation. ## Ausführungen auswerten Automate bringt **kein Performance-Dashboard und keine automatische Metriken-Überwachung** mit. Was Sie real haben: Die **Executions-Liste** zeigt Status und Dauer jeder Ausführung — daraus werten Sie manuell aus. * **Langsame und fehlerhafte Workflows finden:** Status (Erfolg/Fehler) und Dauer pro Execution ablesen, nach fehlgeschlagenen Executions filtern, auffällig lange Ausführungen identifizieren und öffnen. * **Einzelne Execution analysieren:** In der Detailansicht nachvollziehen, an welchem Node die Zeit verloren geht oder welcher Node fehlgeschlagen ist. Vergleichen Sie mehrere Executions desselben Workflows, um Ausreißer von systematischen Problemen zu unterscheiden. * **Eigene Auswertung bauen (DIY):** Wenn Sie Kennzahlen über viele Executions hinweg brauchen, arbeiten Sie mit der Executions-Liste in der Web-App und übertragen die relevanten Werte in Ihr eigenes Tooling — ein selbstgebautes Pattern, kein eingebautes Feature. Für eine programmatische Anbindung siehe [Automate-API](/administration/api). ## Häufige Performance-Probleme | Problem | Lösung | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Zu viele einzelne API-Calls | Calls zu Batch-Requests kombinieren ([Batching](/automate/batching)), Caching implementieren (DIY-Pattern, siehe oben), prüfen ob alle Calls wirklich nötig sind | | Unnötige Datenverarbeitung | Daten früh im Workflow filtern, Selective Fields in API-Calls nutzen, unnötige Transformationen vermeiden | | Fehlende Timeouts | Angemessene Timeouts setzen, [Retry-Logik](/automate/Retry-Logic) implementieren, betroffene Executions in der Detailansicht prüfen | ## Performance-Checkliste * [ ] Unnötige Nodes und Branches wurden entfernt * [ ] Caching (DIY) ist für wiederholte Anfragen implementiert, wo sinnvoll * [ ] API-Calls sind optimiert (Batching, Pagination) * [ ] Timeouts sind angemessen konfiguriert * [ ] Datenfilterung erfolgt früh im Workflow * [ ] Executions werden regelmäßig auf Dauer und Fehler geprüft * [ ] Langsame Nodes wurden identifiziert und optimiert Weiterführend: [Batching](/automate/batching), [Testing](/automate/testing) und [Debugging](/automate/debugging). # Sicherheit Source: https://docs.localmind.ai/automate/security Security-Best-Practices für Automate-Workflows Vier Grundregeln sichern Ihre Automate-Workflows ab: Credentials gehören in den Credential Store und niemals in den Workflow selbst, jeder Webhook braucht mindestens eine Authentifizierungsmethode, alle Verbindungen — API-Calls, Webhooks, Datenübertragung — laufen über HTTPS, und die Nachvollziehbarkeit sichern Execution-Historie und die Localmind-Audit-Logs. ## Credential-Management Secrets gehören in den **Credential Store** von Automate: Dort werden sie verschlüsselt gespeichert und nur zur Laufzeit entschlüsselt — sie landen weder im Workflow-JSON noch in Workflow-Exporten. Legen Sie API-Keys, Passwörter und Tokens immer als Credential an und referenzieren Sie diese in den Node-Einstellungen. Die `$env`-Expression liest Server-Umgebungsvariablen. Diese werden vom Betreiber Ihrer Automate-Instanz serverseitig gesetzt — ein eigenes UI zum Anlegen von Environment Variables gibt es in Automate nicht. Als Workflow-Builder können Sie `$env` nur nutzen, wenn der Betreiber die entsprechende Variable hinterlegt hat. Hardcoden Sie Credentials niemals direkt in Nodes oder Code — hardcodierte Werte erscheinen im Workflow-JSON und damit in jedem Export. **Abgrenzung: Org-Zugangsdaten.** Der Automate Credential Store ist unabhängig von den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Localmind-Organisation. Letztere verwalten Org-Admins unter **Org-Settings → Sicherheit → Zugangsdaten** für Dienste, die Localmind-Agents und Apps nutzen (z.B. DeepL). Credentials, die Ihre Automate-Workflows verwenden, legen Sie direkt in Automate an. ## Webhook-Sicherheit Webhooks ohne Authentifizierung sind ein Sicherheitsrisiko. Implementieren Sie immer mindestens eine Authentifizierungsmethode. Behandeln Sie auch die Webhook-URL selbst als Geheimnis: Wer sie kennt, kann Ihren Workflow auslösen. Teilen Sie Produktions-URLs nur mit den Systemen, die sie benötigen. Die Webhook-URL eines Workflows sehen Sie direkt im Webhook-Node im Workflow-Editor. Der kanonische Weg zur Absicherung ist **Header Auth** im Webhook-Node. Für Datenintegrität und Absender-Verifikation ergänzen Sie eine **HMAC-Signatur**. ### Header Auth (empfohlen) Der Webhook-Node prüft eingehende Requests auf einen erwarteten Header und beantwortet Requests ohne gültigen Header mit einem Fehler — ohne dass Ihr Workflow startet. Öffnen Sie den Webhook-Node und wählen Sie unter **Authentication** die Option **Header Auth**. Erstellen Sie eine neue Header-Auth-Credential mit **Name** (der erwartete Header, z.B. `X-API-Key`) und **Value** (das Secret). Die Credential wird verschlüsselt im Credential Store gespeichert. Senden Sie einen Test-Request mit und ohne gültigen Header und prüfen Sie, dass nur der authentifizierte Request den Workflow auslöst. Auch **Bearer-Tokens** prüfen Sie über Header Auth: Verwenden Sie als Header-Name `Authorization` und als Value `Bearer `. ```bash Custom Header theme={null} curl -X POST https://your-webhook-url \ -H "X-API-Key: your-secret-api-key" \ -H "Content-Type: application/json" \ -d '{"data": "value"}' ``` ```bash Authorization-Header (Bearer) theme={null} curl -X POST https://your-webhook-url \ -H "Authorization: Bearer your-secret-token" \ -H "Content-Type: application/json" \ -d '{"data": "value"}' ``` Verwenden Sie starke, zufällige Werte und rotieren Sie sie regelmäßig — bei Header Auth genügt dafür ein Update der Credential, der Workflow bleibt unverändert. Je nach Automate-Version bietet der Webhook-Node zusätzlich **JWT Auth** an; ob die Option verfügbar ist, sehen Sie direkt im Authentication-Dropdown des Nodes. ### HMAC-Signatur Eine HMAC-SHA256-Signatur stellt sicher, dass der Request-Body unterwegs nicht manipuliert wurde und tatsächlich vom erwarteten Absender stammt. Der Absender signiert den Body mit einem Shared Secret; Ihr Workflow berechnet die Signatur nach und vergleicht. ```javascript HMAC-Validierung (Code-Node) theme={null} const crypto = require('crypto'); const signature = $json.headers['x-signature']; const body = JSON.stringify($json.body); const expectedSignature = crypto .createHmac('sha256', $env.WEBHOOK_SECRET) .update(body) .digest('hex'); if (signature !== expectedSignature) { throw new Error('Invalid signature'); } return [{ json: { valid: true, data: $json.body } }]; ``` ```bash cURL mit Signatur theme={null} # Signatur berechnen SIGNATURE=$(echo -n '{"data":"value"}' | \ openssl dgst -sha256 -hmac "secret" | \ cut -d' ' -f2) curl -X POST https://your-webhook-url \ -H "X-Signature: $SIGNATURE" \ -H "Content-Type: application/json" \ -d '{"data":"value"}' ``` Das Beispiel setzt voraus, dass der Betreiber das Shared Secret als Server-Umgebungsvariable (`WEBHOOK_SECRET`) hinterlegt hat und `require` für das Node.js-Built-in-Modul `crypto` serverseitig freigeschaltet ist. Falls der Aufruf fehlschlägt, wenden Sie sich an Ihren Administrator. ### Basic Auth Für interne Systeme genügt oft Basic Auth: Wählen Sie im Webhook-Node **Authentication → Basic Auth** und hinterlegen Sie Benutzername und Passwort als Credential. ```bash cURL Beispiel theme={null} curl -X POST https://your-webhook-url \ -u webhook_user:secure_password \ -H "Content-Type: application/json" \ -d '{"data": "value"}' ``` Basic Auth ist einfach und von allen HTTP-Clients unterstützt, aber weniger flexibel als Header Auth — bevorzugen Sie für neue Integrationen Header Auth. ### Replay-Schutz Header Auth und HMAC verhindern nicht, dass ein abgefangener, gültiger Request erneut gesendet wird. Dagegen schützen Timestamp- und Nonce-Prüfung — am besten kombiniert. **Timestamp-Validierung:** Lehnen Sie Requests ab, deren Zeitstempel zu alt ist. Der Absender sendet dafür einen Header wie `X-Timestamp` mit. ```javascript Timestamp-Check (Code-Node) theme={null} const requestTime = parseInt($json.headers['x-timestamp'] || '0'); const maxAge = 5 * 60 * 1000; // 5 Minuten if (Math.abs(Date.now() - requestTime) > maxAge) { throw new Error('Request timestamp too old or invalid'); } return [{ json: { valid: true } }]; ``` Verwenden Sie ein maximales Alter von 5-15 Minuten, abhängig von Ihrer Anwendungslogik. Bei HMAC-Absicherung sollte der Timestamp Teil der signierten Daten sein, damit er nicht manipuliert werden kann. **Nonce-Validierung:** Eine Nonce (Number Used Once) stellt sicher, dass jeder Request nur einmal verarbeitet wird, auch wenn er mehrfach gesendet wird. ```javascript Nonce-Check (Code-Node) theme={null} const staticData = $getWorkflowStaticData('global'); const nonce = $json.headers['x-nonce']; const seenNonces = staticData.seenNonces || []; if (seenNonces.includes(nonce)) { throw new Error('Duplicate request'); } staticData.seenNonces = [...seenNonces, nonce].slice(-1000); return [{ json: { valid: true } }]; ``` Beachten Sie: `$getWorkflowStaticData` persistiert nur bei Produktions-Ausführungen aktiver Workflows, nicht bei manuellen Test-Runs. ### Webhook-Sicherheits-Checkliste * [ ] Mindestens eine Authentifizierungsmethode ist implementiert * [ ] Secrets liegen im Credential Store, nicht im Workflow-JSON * [ ] Die Webhook-URL wird wie ein Geheimnis behandelt * [ ] HTTPS wird verwendet (nicht HTTP) * [ ] HMAC-Signaturen werden bei kritischen Webhooks validiert * [ ] Replay-Schutz (Timestamp + Nonce) ist bei kritischen Webhooks implementiert * [ ] Fehlgeschlagene Authentifizierungsversuche werden überwacht ## Input-Validierung Validieren Sie alle eingehenden Daten, bevor Ihr Workflow sie weiterverarbeitet: ```javascript Input-Validierung (Code-Node) theme={null} // Validieren Sie das E-Mail-Format const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; if (!emailRegex.test(input.email)) { throw new Error('Invalid email format'); } // Validieren Sie Datentypen if (typeof input.userId !== 'string') { throw new Error('userId must be string'); } // Validieren Sie den Wertebereich if (input.amount < 0 || input.amount > 10000) { throw new Error('Amount out of range'); } ``` ### SQL-Injection verhindern Bei Datenbankabfragen gilt: Verwenden Sie Parameterized Queries, fügen Sie User-Input niemals direkt in SQL ein und validieren Sie alle Inputs. ```javascript Sicher (Parameterized) theme={null} const query = 'SELECT * FROM users WHERE id = ?'; const result = await db.query(query, [userId]); ``` ```javascript Unsicher (SQL-Injection Risiko) theme={null} const query = `SELECT * FROM users WHERE id = ${userId}`; // NIEMALS SO! ``` ## Audit und Nachvollziehbarkeit Automate führt kein eigenes Audit-Log. Zwei reale Quellen decken die Nachvollziehbarkeit ab: * **Execution-Historie:** Jede Workflow-Ausführung mit Status, Input/Output und Fehlern finden Sie im **Executions**-Tab — siehe [Debugging](/automate/debugging). * **Localmind-Audit-Logs:** Sicherheitsrelevante Ereignisse Ihrer Organisation (Logins, Berechtigungsänderungen, Ressourcen-Zugriffe) erfassen die Audit-Logs der Plattform — siehe [Observability](/administration/observability) und [Audit-Logs](/settings/instance/Audit-Logs). ## Best Practices * **Principle of Least Privilege:** nur die minimal notwendigen Berechtigungen gewähren. * **Regelmäßige Audits:** Workflows regelmäßig auf Sicherheitslücken prüfen. * **Credential Rotation:** Credentials regelmäßig rotieren. * **Monitoring:** auf verdächtige Aktivitäten überwachen. ## Häufige Sicherheitsfehler | Fehler | Lösung | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Hardcodierte Credentials in Code oder Node-Parametern | Credential Store verwenden, Workflow-Exporte auf versehentlich enthaltene Secrets prüfen, Secrets niemals in Git committen | | Unverschlüsselte Verbindungen (HTTP statt HTTPS) | Immer HTTPS verwenden, SSL-Zertifikate validieren, TLS 1.2+ nutzen | | Fehlende Input-Validierung | Alle Inputs validieren, Whitelisting nutzen, User-Input sanitizen | Weiterführend: [Sub-Processors](/compliance/Sub-Processors) und [Compliance-Dokumente](/compliance/documents). # Testing Source: https://docs.localmind.ai/automate/testing Konkrete Testmethoden für Automate-Workflows - Praktische Anleitung zum Testen und Interpretieren von Ergebnissen Bevor Sie einen Workflow aktivieren, testen Sie ihn — erst Node für Node, dann als Ganzes. Diese Seite zeigt, wie Sie dabei vorgehen und wie Sie Ergebnisse und Fehler richtig interpretieren. ## Einzelne Nodes testen Testen Sie jeden Node einzeln, bevor Sie den gesamten Workflow ausführen: Node öffnen, Parameter und Credentials prüfen, dann **Execute Node** klicken (oder F2). Grüner Status heißt erfolgreich ausgeführt — prüfen Sie anschließend, ob der Output vollständig ist und dem erwarteten Format entspricht. Roter Status heißt fehlgeschlagen — lesen Sie die Error-Message und prüfen Sie Input-Daten und Credentials. Im Node-Detail sehen Sie drei Dinge: den **Input** (was hineingegangen ist), den **Output** (was herauskommt) und die **Execution Time** (wie lange es gedauert hat). Verwenden Sie realistische Test-Daten — und testen Sie nicht nur den Happy Path: ```json Standard Test-Daten theme={null} { "email": "test@example.com", "name": "Max Mustermann", "message": "Test-Nachricht für Workflow-Testing" } ``` ```json Edge Case Test-Daten theme={null} { "email": "", "name": null, "message": "Sehr lange Nachricht " + "x".repeat(10000) } ``` Validieren Sie den Output gezielt gegen Ihre Erwartungen: ```javascript Output prüfen (Beispiel HTTP Request) theme={null} // 1. Status Code prüfen {{ $json.statusCode }} === 200 // 2. Erwartete Felder vorhanden? {{ $json.body.id }} !== undefined // 3. Datentyp korrekt? typeof {{ $json.body.id }} === 'number' ``` ## Outputs pinnen Führen Sie den Workflow einmal komplett aus, um echte Daten zu erhalten, und pinnen Sie dann den Node-Output über das **Pin-Icon**. Nachgelagerte Nodes verwenden ab jetzt die gepinnten Daten — ohne erneute API-Calls oder Agent-Aufrufe, also ohne zusätzlichen Credit-Verbrauch. Gepinnte Daten können Sie manuell bearbeiten, um fehlende Felder, geänderte Werte oder Fehlerzustände zu simulieren. **Credits sparen:** Jeder Test eines Agent-Aufrufs ohne Pinning verbraucht Credits — bei 50 Tests summiert sich das schnell. Pinnen Sie nach dem ersten erfolgreichen Test. ## Den gesamten Workflow testen Fügen Sie einen **Manual Trigger** am Anfang hinzu und starten Sie den Workflow mit **Execute Workflow**. Beobachten Sie während der Ausführung den Status jedes Nodes (grün/rot) und klicken Sie auf einzelne Nodes, um Zwischenergebnisse zu sehen. Prüfen Sie am Ende das Gesamtergebnis: Sind alle erwarteten Outputs vorhanden und korrekt formatiert? ## Execution Logs lesen Sie erreichen die Logs über den **Executions**-Tab: Execution auswählen, dann **Open in Editor** klicken. | Status | Bedeutung | Was prüfen | | -------------- | ---------------------------------- | ------------------------------------------------------------------------------------ | | Grün (Success) | Workflow erfolgreich abgeschlossen | Output-Daten vorhanden? Execution-Zeit akzeptabel? | | Rot (Error) | Workflow fehlgeschlagen | Welcher Node ist rot? Error-Message und Input-Daten des Nodes lesen | | Gelb (Waiting) | Workflow wartet | Webhook wartet auf Request, Schedule-Trigger auf Zeitpunkt, oder Rate Limit erreicht | Bei einzelnen Nodes lohnt der Blick auf drei Dinge: * **Input-Daten:** Sind alle erwarteten Felder vorhanden, im richtigen Format, ohne null/undefined? * **Output-Daten:** Entspricht der Output den Erwartungen — alle benötigten Felder, korrektes Format? * **Execution-Zeit:** unter 1 Sekunde sehr schnell, 1–5 Sekunden normal, 5–30 Sekunden langsam aber akzeptabel, über 30 Sekunden zu langsam — optimieren. ## Fehler interpretieren ### HTTP-Fehler | Code | Ursache | Lösung | | ------------------------- | -------------------------------- | -------------------------------------- | | 400 Bad Request | Ungültige Anfrage-Parameter | Request-Body und Headers prüfen | | 401 Unauthorized | Authentifizierung fehlgeschlagen | Credentials überprüfen | | 404 Not Found | Endpoint nicht gefunden | URL überprüfen | | 429 Too Many Requests | Rate Limit erreicht | Retry-Logik implementieren oder warten | | 500 Internal Server Error | Server-Fehler | Retry-Logik oder Support kontaktieren | ### Datenformat-Fehler Meldungen wie „Cannot read property 'x' of undefined", „Expected string but got number" oder „Invalid JSON format" deuten auf Format-Probleme zwischen Nodes hin. Prüfen Sie die Input-Daten des Nodes, die Expression-Syntax (`{{ $json.fieldName }}`) und die Datenformate zwischen den Nodes — bei Bedarf transformieren Sie mit einem Set-Node: ```javascript Null-Check in Expressions theme={null} // FALSCH: {{ $json.user.name }} // RICHTIG (mit Null-Check): {{ $json.user?.name || 'Unknown' }} ``` ### Timeout-Fehler Bei „Execution timeout exceeded" (Node bleibt lange gelb, dann rot) haben Sie drei Hebel: den Timeout in den Node-Einstellungen erhöhen (Standard 30 Sekunden → 60 Sekunden), den API-Call verschlanken (Request-Größe reduzieren, Pagination nutzen) oder automatische Retries mit Exponential Backoff — siehe [Retry Logic](/automate/Retry-Logic). ### Credential-Fehler Bei „Authentication failed", „Invalid credentials" oder „API key not found": Credentials in den Node-Einstellungen überprüfen, das Credential-Format validieren (Bearer Token, API Key) und den Call isoliert testen — zum Beispiel in Postman: ```bash theme={null} # Testen Sie Credentials zuerst in Postman curl -X GET "https://api.example.com/endpoint" \ -H "Authorization: Bearer YOUR_API_KEY" ``` ## Test-Szenarien ### API-Call testen Testen Sie externe APIs zuerst außerhalb von Automate: cURL aus der API-Dokumentation in Postman importieren, mit echten Parametern testen, Response-Format verifizieren. Übertragen Sie dann Method, URL, Headers und Body in einen HTTP Request Node und führen Sie **Execute Node** aus. Prüfen Sie im Output `$json.statusCode === 200` und ob die erwarteten Felder im Response-Body vorhanden sind. ### Agent-Aufruf testen Localmind-Agenten rufen Sie über einen HTTP Request Node gegen `/v1/chat/completions` auf — die vollständige Anleitung steht unter [Localmind Agent in n8n einbinden](/automate/Localmind-Agent). 1. Methode **POST**, URL: `https://-api.localmind.ai/v1/chat/completions` 2. Authentication: Header-Auth-Credential mit `Authorization: Bearer ` 3. Body (JSON) — `model` trägt die Agent-UUID aus `GET /v1/models`: ```json theme={null} { "model": "", "messages": [ { "role": "user", "content": "{{ $json.text }}" } ], "stream": false } ``` Die Antwort kann 5–30 Sekunden dauern. Der Output folgt dem Chat-Completions-Schema: ```json theme={null} { "choices": [ { "message": { "role": "assistant", "content": "Diese E-Mail ist dringend und sollte priorisiert werden." }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 25, "completion_tokens": 20, "total_tokens": 45 } } ``` Prüfen Sie: `$json.choices[0].message.content` ist vorhanden und nicht leer, `$json.usage.total_tokens` liegt im erwarteten Rahmen. Agent-Aufrufe werden in Credits abgerechnet — behalten Sie `usage.total_tokens` pro Test im Blick und pinnen Sie den Output nach dem ersten erfolgreichen Test. ### Bedingte Logik testen (IF/Switch) Testen Sie beide Branches mit passenden Daten — und zusätzlich die Edge Cases: ```javascript IF-Bedingung theme={null} {{ $json.userType === 'premium' && $json.subscriptionActive === true }} ``` ```json True-Branch theme={null} { "userType": "premium", "subscriptionActive": true, "balance": 100 } ``` ```json False-Branch theme={null} { "userType": "free", "subscriptionActive": false, "balance": 0 } ``` ```json Edge Case theme={null} { "userType": null, "subscriptionActive": undefined, "balance": null } ``` Erwartung: Der jeweils passende Branch wird ausgeführt, der andere übersprungen. Bei den Null/Undefined-Fällen prüfen Sie, wie sich der Node verhält, ob Fehler geworfen werden und ob Ihr Error-Handling greift. ### Daten-Transformation testen (Set/Code) Definieren Sie Input-Daten, konfigurieren Sie die Transformation und vergleichen Sie den Output mit dem erwarteten Ergebnis. Beispiel für einen Set-Node mit den Feldern `fullName`: `{{ $json.firstName }} {{ $json.lastName }}`, `greeting`: `Hallo {{ $json.firstName }}!` und `email`: `{{ $json.email }}`: ```json Input theme={null} { "firstName": "Max", "lastName": "Mustermann", "email": "max@example.com" } ``` ```json Erwarteter Output theme={null} { "fullName": "Max Mustermann", "greeting": "Hallo Max!", "email": "max@example.com" } ``` ## Best Practices * **Früh testen:** jeden Node sofort nach Erstellung, nicht erst am Ende der Entwicklung. * **Outputs pinnen:** spart Zeit und Credits bei Downstream-Tests. * **Realistische Test-Daten:** Daten verwenden, die echten Szenarien entsprechen — plus Edge Cases (null-Werte, leere Strings, sehr lange Texte). * **Tests dokumentieren:** Szenarien und erwartete Outputs für zukünftige Referenz notieren. * **Tests isolieren:** jeder Test funktioniert unabhängig von anderen. ## Checkliste vor dem Aktivieren * [ ] Alle Nodes wurden einzeln getestet und liefern grünen Status * [ ] Output-Daten wurden validiert: erwartete Felder vorhanden, Formate korrekt, keine null/undefined-Werte in kritischen Feldern * [ ] Der Workflow wurde vollständig durchlaufen * [ ] Alle Branches wurden getestet (IF/Switch), Edge Cases eingeschlossen * [ ] Error-Handling und Retry-Logik wurden getestet, Timeouts sind angemessen * [ ] Execution-Zeit ist akzeptabel (unter 30 Sekunden) * [ ] Execution Logs wurden überprüft * [ ] Credit-Verbrauch wurde kalkuliert (bei KI-Nodes) ## Nächste Schritte Erfahren Sie mehr über fortgeschrittene Debugging-Techniken. Optimieren Sie die Performance Ihrer Workflows. Lernen Sie weitere Best Practices für professionelle Workflows. Erfahren Sie mehr über sichere Workflow-Implementierung. Bei Fragen zum Testing Ihrer Workflows hilft unser Support-Team unter [support@localmind.ai](mailto:support@localmind.ai). # Versionierung Source: https://docs.localmind.ai/automate/versioning Workflow-Versionierung und Backup-Strategien für Automate Eine solide Versionierungsstrategie ist essentiell für die Wartbarkeit und Zuverlässigkeit Ihrer Automate-Workflows: Sie macht Änderungen rückverfolgbar, ermöglicht Teamarbeit ohne gegenseitiges Überschreiben, erlaubt bei Problemen ein schnelles Rollback auf eine funktionierende Version und schafft Audit-Trails für Compliance. Ob eine integrierte Workflow-Historie verfügbar ist, hängt von Ihrer Automate-Version ab — verlassen Sie sich für belastbare Versionierung auf den Export-Weg unten. Er funktioniert unabhängig von der eingesetzten Version. ## Workflows in Git speichern Der verlässliche Weg zur Versionierung: Sie laden den Workflow als JSON-Datei herunter und verwalten ihn in Git. Öffnen Sie den Workflow, dann das Workflow-Menü (**⋯** oben rechts), und klicken Sie auf **Download** — der Workflow wird als JSON-Datei gespeichert. Der Menüpunkt heißt **Download**, nicht „Export". Legen Sie die Datei in Ihrer Repository-Struktur ab und committen Sie mit einer aussagekräftigen Message, die die Änderung beschreibt: ```bash theme={null} git add workflows/ git commit -m "Update welcome email workflow" git push ``` Verwenden Sie Git Tags für Releases: ```bash theme={null} git tag -a v1.0.0 -m "Initial workflow version" git push --tags ``` Und Branches für Experimente: ```bash theme={null} git checkout -b feature/new-workflow # Änderungen machen git commit -m "Add new workflow feature" ``` ### Empfohlene Repository-Struktur ``` localmind-workflows/ ├── .gitignore ├── README.md ├── workflows/ │ ├── production/ │ │ ├── welcome-email.json │ │ └── order-processing.json │ ├── staging/ │ │ └── welcome-email.json │ └── development/ │ └── test-workflow.json ├── scripts/ │ ├── export-all.sh │ └── import-workflow.sh └── docs/ └── workflow-documentation.md ``` Die Ordner `production/`, `staging/` und `development/` sind eine **reine Git-Ordnerkonvention** zur Organisation Ihrer Dateien. Automate selbst kennt keine Environments — alle Workflows laufen in derselben Instanz. ## Backup-Strategien Automatisieren Sie regelmäßige Exports (täglich oder wöchentlich), speichern Sie sie in sicherem Speicher und behalten Sie mehrere Backup-Generationen. Exportieren Sie zusätzlich manuell vor größeren Änderungen und Updates — und testen Sie die Wiederherstellung Ihrer Backups regelmäßig. ```bash theme={null} #!/bin/bash # backup-workflows.sh BACKUP_DIR="./backups/$(date +%Y-%m-%d)" mkdir -p "$BACKUP_DIR" # Die über die Web-App heruntergeladenen Workflow-JSON-Dateien # in das datierte Backup-Verzeichnis ablegen echo "Backups erstellt in: $BACKUP_DIR" ``` Die Workflow-JSON-Dateien laden Sie über die Web-App herunter (siehe [Workflows in Git speichern](#workflows-in-git-speichern) oben); zum Zurückspielen importieren Sie die gesicherte Datei wieder. Eine programmatische Verwaltung dokumentieren wir unter [Automate-API](/administration/api), sobald die Schnittstelle verifiziert ist. ## Versionsnummern Verwenden Sie semantische Versionierung im Format `MAJOR.MINOR.PATCH`: **MAJOR** für Breaking Changes, **MINOR** für neue, rückwärtskompatible Features, **PATCH** für Bugfixes. Beispiel: `1.0.0` (Initial Release) → `1.1.0` (neue Features) → `1.1.1` (Bugfix) → `2.0.0` (Breaking Changes). Setzen Sie die Versionen als Git Tags: ```bash theme={null} # Major Release git tag -a v2.0.0 -m "Major update with breaking changes" # Minor Release git tag -a v1.1.0 -m "Added new features" # Patch Release git tag -a v1.0.1 -m "Fixed critical bug" ``` Dokumentieren Sie Versionsänderungen in einer `CHANGELOG.md`: ```markdown theme={null} # Changelog ## [2.0.0] - 2026-01-15 ### Breaking Changes - Workflow-Struktur geändert: Neue Node-Reihenfolge erforderlich - API-Endpunkt geändert: Migration erforderlich ### Added - Neue Error-Handling-Logik - Retry-Mechanismus für API-Calls - Performance-Monitoring ### Changed - Verbesserte Datenvalidierung - Optimierte API-Call-Reihenfolge ### Fixed - Bug bei Timeout-Behandlung - Fehlerhafte Daten-Transformation behoben ## [1.1.0] - 2026-01-01 ### Added - Neue E-Mail-Templates - Erweiterte Logging-Funktionen ``` ## Migration zwischen Versionen 1. **Backup erstellen:** Exportieren Sie die aktuelle Version als Backup. 2. **Änderungen prüfen:** Lesen Sie den CHANGELOG und prüfen Sie Breaking Changes. 3. **Test-Kopie:** Testen Sie die neue Version als Kopie des Workflows (z.B. aus Ihrem `development/`-Ordner importiert), bevor Sie den produktiven Workflow ersetzen. 4. **Migration:** Ersetzen Sie den produktiven Workflow durch die getestete Version. 5. **Validierung:** Überprüfen Sie, dass alles funktioniert. ## Checkliste * [ ] Workflows sind in Git versioniert * [ ] Regelmäßige Backups werden erstellt * [ ] Versionsnummern werden verwendet * [ ] CHANGELOG wird gepflegt * [ ] Migration-Strategien sind dokumentiert * [ ] Backup-Wiederherstellung wurde getestet Weiterführend: [Naming Conventions](/automate/Naming-Conventions) und [Sicherheit](/automate/security). # Changelog Source: https://docs.localmind.ai/changelog/overview Alle Releases der Localmind-Plattform im Überblick. Hier finden Sie alle Releases. Jede Version hat ihre eigene Page mit Neuerungen, Verbesserungen, Bugfixes und Breaking Changes. 13. August 2026 — Neue App Poststelle (Beta), Export vollständiger Gesprächsverläufe in der Analytik, Modellwahl in den Dokumenten-Apps, Automate-Hauptversions-Update. 24. Juli 2026 — Wartungsrelease: behebt die OAuth-Zugangsdaten-Erstellung in Automate. 13. Juli 2026 — GA-Release: Code-Sandbox und Skills für Agenten, Nutzungsübersicht mit Kostenaufschlüsselung, überarbeitete Benutzeroberfläche. 22. Juni 2026 — OAuth-Integrationen (SharePoint, Outlook, Teams), 2FA selbst deaktivieren, Bibliotheks-Fixes. 15. Juni 2026 — OpenAI-kompatible API, Bildgenerierung im Chat, Konversationen teilen, Prompt-Caching. 1. Juni 2026 — Mermaid-Diagramme im Chat, Admin-Ankündigungen, Tool-Call-Limit-Hinweis. 12. Mai 2026 — Persönliche API-Schlüssel, rollenbasierte Modellzugriffe, 180-Tage-Audit-Log-Retention. 3. April 2026 — Chat-Zusammenfassung, erweiterte Audit-Logs, In-App-Changelog. **Versions-Schema** (`HAUPTZAHL.MINOR.PATCH`, z.B. `1.0.0-beta.5`): * **Hauptzahl** (`1.x`): Major-Release mit möglichen Breaking Changes * **Minor** (`x.1`): neue Features, abwärts-kompatibel * **Patch** (`x.x.1`): Bugfixes und Sicherheitsupdates Das Suffix `-beta.N` kennzeichnet Pre-Releases auf dem Beta-Track, die vor dem stabilen Release der jeweiligen Version erscheinen. **Beim Update auf eine neue Version:** 1. Prüfen Sie die Versions-Page auf ``-markierte Breaking Changes 2. Folgen Sie den Migration-Hinweisen 3. Bei API-Konsumenten: testen Sie alle veränderten Endpoints 4. Bei Self-Hosting: planen Sie ein Wartungsfenster für Major-Updates — siehe [Hosting-Optionen](/pricing/Hosting-Options) **Markierungen in Versions-Pages:** * `` umschließt jeden Release-Block (Mintlify-Komponente mit Datum-Header) * `` markiert Breaking Changes * `` markiert Deprecation-Hinweise (Funktionalität bleibt für einen angemessenen Übergangszeitraum erhalten) # v1.0.0 — Code-Sandbox, Skills und Nutzungsübersicht Source: https://docs.localmind.ai/changelog/v1.0.0 GA-Release vom 13. Juli 2026 — Code-Sandbox, Skills, Nutzungsübersicht und zahlreiche Bugfixes. ## Neu * KI-Agenten können jetzt Code (Python, JavaScript und Bash) in einer sicheren, isolierten Sandbox schreiben und ausführen – und mit integrierten Skills Word-, Excel-, PowerPoint- und PDF-Dateien direkt in der Konversation erstellen und bearbeiten. Siehe [Werkzeuge](/core-functions/Werkzeuge#skills-und-die-code-sandbox) und [Administration → Werkzeuge](/administration/Werkzeuge). * Agenten können jetzt mit Skills erweitert werden – wiederverwendbare Pakete aus Anweisungen und Assets (nach der SKILL.md-Konvention), die einem Agenten beibringen, eine bestimmte Aufgabe auszuführen. Sie können eigene Skills erstellen oder bestehende importieren. Siehe [Werkzeuge](/core-functions/Werkzeuge#skills-und-die-code-sandbox). * Die Benutzeroberfläche wurde in der gesamten Anwendung überarbeitet, inklusive eines neuen integrierten PDF-Viewers. * Die Navigations-Seitenleisten können jetzt eingeklappt werden, um Konversationen und Dokumenten mehr Platz zu geben. * Persönliche API-Schlüssel können jetzt Dokumente, Dateien und Ordner verwalten – Dateien hochladen, Dokumente durchsuchen, Ergebnisse herunterladen und Ordner programmatisch organisieren. Siehe [Dateien und Ordner](/api-reference/Dateien-und-Ordner) und [Dokumente und Suche](/api-reference/Dokumente-und-Suche). * Die Outlook- und Teams-Integrationen bieten jetzt Kalenderzugriff, und ihre Antworten werden korrekt formatiert dargestellt. Siehe [Outlook](/integrations/Outlook) und [Microsoft Teams](/integrations/Microsoft-Teams). * Das Hochladen von ZIP-Archiven wird wieder unterstützt; deren Inhalte werden automatisch extrahiert und verarbeitet. Siehe [Dokumente](/core-functions/Dokumente). * Sie können jetzt festlegen, wie viele Einträge pro Seite in Listen angezeigt werden – Ihre Einstellung wird gespeichert. * Die Mitgliedertabelle in den Organisations- und Instanz-Einstellungen zeigt jetzt an, wann jedes Mitglied zuletzt aktiv war. Siehe [Mitglieder](/settings/organization/Mitglieder) und [Benutzer verwalten](/settings/instance/users). * Localmind nutzt jetzt ein Lizenzmodell: Jede Instanz benötigt eine gültige Lizenz für den Betrieb, und Administratoren werden rechtzeitig vor Ablauf einer Lizenz gewarnt. Siehe [Lizenz](/settings/instance/Lizenz). * Eine neue Nutzungsübersicht ermöglicht Organisationen, Ressourcenverbrauch und Kosten über alle Spaces hinweg in Echtzeit zu überwachen – mit einer Kostenaufschlüsselung nach Dienst und exportierbaren Nutzungsberichten. Administratoren können Preismodelle, Tarife und Währungen festlegen. Siehe [Nutzungsübersicht](/administration/Nutzungsübersicht). ## Verbessert * Wenn ein KI-Anbieter überlastet ist oder das Anfragelimit erreicht wird, wird jetzt eine verständliche Meldung anstelle eines generischen Fehlers angezeigt. * Einladungs-E-Mails wurden für ein klareres, professionelleres Erscheinungsbild überarbeitet und enthalten jetzt das Logo Ihrer Organisation. Siehe [Erscheinungsbild](/settings/organization/Erscheinungsbild). * In den Dokumenten-Apps (Analyse, Vergleich, Extraktion und mehr) können jetzt mehrere Dateien gleichzeitig ausgewählt werden. Siehe [Dokumentenanalyse](/apps/Document-Analysis), [Dokumentenvergleich](/apps/Document-Comparison) und [Dokumentenextraktion](/apps/Document-Extraction). ## Behoben * Fehler behoben, bei dem Antworten bei 4096 Tokens abgeschnitten wurden; Modelle nutzen jetzt ihre volle konfigurierte Ausgabelänge. * Fehler behoben, bei dem die Zwei-Faktor-Authentifizierung in manchen Fällen nicht funktionierte. Siehe [Authentifizierung](/settings/organization/Authentifizierung). * Fehler behoben, bei dem Dokumentenanalyse, -vergleich und -extraktion bei länger laufenden Vorgängen manchmal fehlschlugen. Siehe [Dokumentenanalyse](/apps/Document-Analysis). * Fehler behoben, bei dem Ordner mit gleichem Namen zusammengeführt wurden, sowie inkonsistentes Verhalten beim Verschieben von Ordnern. Siehe [Dokumente](/core-functions/Dokumente). * Fehler behoben, bei dem der Import großer Datentabellen-Dateien ohne Fehlermeldung nie abgeschlossen wurde, sowie zeitweise fehlschlagende Agenten-Abfragen auf Datentabellen. Siehe [Tabellen](/core-functions/Tabellen). * Zahlreiche Fehlerbehebungen bei Dokumentenextraktion und -vergleich, darunter Extraktion mit mehr Modellen (nicht nur Mistral), korrekte Leerzustände, Dokumentenvorschau, dokumentweises Entfernen im Vergleich und die Schrittführung im App-Assistenten. Siehe [Dokumentenextraktion](/apps/Document-Extraction) und [Dokumentenvergleich](/apps/Document-Comparison). * Fehler behoben, bei dem Web-Quellen nach dem Hinzufügen nicht automatisch mit dem Scraping begannen. Siehe [Webseiten](/core-functions/Webseiten). * Zahlreiche Fehlerbehebungen beim Chat-Widget: Pro Widget-Sitzung werden zuverlässig neue Konversationen erstellt, der schwarze Kasten vor dem Laden des Chats ist verschwunden und das automatische Öffnen funktioniert jetzt. * Fehler behoben, bei dem neu hinzugefügte Werkzeuge nicht an bereits veröffentlichte und verlinkte Agenten übertragen wurden. Siehe [Bibliothek](/library/overview). * Fehler behoben, bei dem das Deaktivieren integrierter Werkzeuge keine Wirkung zeigte, sowie ein falsch angezeigter Verbindungsstatus des Python-Werkzeugs. Siehe [Werkzeuge](/core-functions/Werkzeuge). * Fehler behoben, bei dem sich das Agenten-Bearbeitungsfenster nach dem Speichern von selbst schloss. Siehe [Agent erstellen](/core-functions/agents). * Fehler behoben, bei dem das Symbol eines Agenten beim Duplizieren verloren ging und von Agenten erstellte Tabellen im falschen Ordner abgelegt wurden. Siehe [Agent erstellen](/core-functions/agents) und [Tabellen](/core-functions/Tabellen). * Fehler behoben, bei dem sich der Reasoning-Schalter nicht deaktivieren ließ. Siehe [Reasoning & Thinking](/arbeiten-mit-ki/Reasoning-und-Thinking). * Abstürze in Konversationen mit mehreren Verzweigungen und beim Öffnen des Event-Emitters behoben. * Fehler behoben, bei dem sich SMTP- und Postausgangs-E-Mail-Einstellungen nicht speichern oder aktualisieren ließen, sowie beim OAuth-E-Mail-Einrichtungsprozess. Siehe [E-Mail (SMTP)](/settings/organization/E-Mail-SMTP). * Fehler behoben, bei dem die Oberflächensprache für alle auf Englisch zurückfiel, obwohl Deutsch ausgewählt war. * Fehler behoben, bei dem sich der Bibliotheks-Installationsdialog nicht öffnete, sowie die Paginierung in der Bibliothek. Siehe [Bibliothek](/library/overview). * Berechtigungsprobleme der Rolle Space Viewer behoben, die keine persönlichen Pins erstellen konnte und Apps sowie Einstellungen sah, die sie nicht nutzen konnte, sowie ein Serverfehler auf Space-Seiten für Benutzer, die zwei oder mehr Teams im selben Space angehören. Siehe [Space-Rollen](/settings/organization/Space-Rollen). * Mehrere Probleme mit persönlichen API-Schlüsseln behoben, darunter über API-Schlüssel gesendete Nachrichten, die nicht im Konversationsverlauf gespeichert wurden, und eine Token-Validierung, die Schlüssel fälschlicherweise als inaktiv meldete. Siehe [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel). * Mehrere Fehler beim Verbinden von Microsoft-Integrationen (Outlook, Teams, SharePoint) in bestimmten Organisationskonfigurationen behoben. Siehe [SharePoint](/integrations/SharePoint) und [Outlook](/integrations/Outlook). * Fehler bei der JSON-Formatierung in Antworten von HTTP-Werkzeugen behoben. Siehe [Werkzeuge](/core-functions/Werkzeuge). * Fehlende Übersetzungen im Dokumentmenü des PDF-Viewers und falsche Darstellung beim Drucken oder Erstellen von Screenshots behoben. * Verbesserte Suchergebnisse für Dokumente, die zuvor als einzelner Chunk verarbeitet wurden; sie greifen jetzt auf zeichenbasiertes Chunking zurück. Siehe [Verarbeitung](/settings/organization/Verarbeitung). * Das Scrollen innerhalb eingebetteter Tabellen und langer Textblöcke im Chat wurde überarbeitet und fühlt sich natürlicher an. # v1.0.0-beta.4 — Chat-Zusammenfassung und erweiterte Audit-Logs Source: https://docs.localmind.ai/changelog/v1.0.0-beta.4 Release vom 3. April 2026 — automatische Chat-Zusammenfassung, erweiterte Audit-Logs, In-App-Changelog, viele Bugfixes. ## Neu * Automatische Chat-Zusammenfassung ermöglicht endlose Konversationen ohne Kontextlimit. Siehe [Kontextfenster](/arbeiten-mit-ki/Context-Fenster#automatische-chat-zusammenfassung). * Erweiterte Audit-Logs mit Nachrichteninhalt, Detail-Ansicht und vollständigem CSV-Export. Siehe [Audit-Logs](/settings/instance/Audit-Logs). * In-App-Changelog hinzugefügt, um Sie über neue Funktionen und Updates zu informieren. Siehe [Changelog](/changelog/overview). ## Verbessert * Viele weitere deutsche Übersetzungen in der gesamten Anwendung hinzugefügt. * Dateigrößenlimits für Chat-Anhänge erhöht. * Umfassende Berechtigungsprüfungen in der gesamten Anwendung hinzugefügt. * Veraltete Datenzugriffsmodus-Einstellungen von der Agenten-Bearbeitungsseite entfernt. Siehe [KI-Konfiguration: Agenten](/settings/organization/Agenten). ## Behoben * Fehler beim Löschen von Geheimnissen aus Tools behoben. * Entfernen von Space-Rollen behoben — ein Bestätigungsdialog erscheint jetzt beim Entfernen der letzten Rolle eines Mitglieds. Siehe [Space-Rollen](/settings/organization/Space-Rollen). * Farbspeicherung bei der Anpassung der Oberfläche behoben. * Fehler bei der Ablehnung von Bibliotheks-Veröffentlichungsanfragen behoben. * Fehler beim Kopieren von Tools und Berechtigungswarnungen bei Bibliotheksinstallation behoben. * Organisationslöschung und Weiterleitungsverhalten behoben. * Fehler behoben, bei dem Dateien nach dem Upload kurzzeitig verschwanden, bevor der Status angezeigt wurde. * Fehler behoben, bei dem Benutzer in falschen Organisationen angezeigt wurden. * Chat-Eingaben werden jetzt beibehalten, wenn Ihre Sitzung während der Eingabe abläuft. * Beschreibung des Websuche-Tools aktualisiert. # v1.0.0-beta.5 — Persönliche API-Schlüssel und rollenbasierte Modellzugriffe Source: https://docs.localmind.ai/changelog/v1.0.0-beta.5 Release vom 12. Mai 2026 — persönliche API-Schlüssel, rollenbasierte Basismodell-Zugriffe, 180-Tage-Audit-Log-Retention, Library zeigt installierte Spaces. ## Neu * Bibliotheksressourcen zeigen jetzt an, in welchen Spaces sie installiert wurden. Siehe [Bibliothek](/library/overview). * Audit-Logs werden jetzt 180 Tage aufbewahrt, zuvor waren es 30. Siehe [Audit Logs](/settings/instance/Audit-Logs). * API-Schlüssel sind jetzt persönlich — jeder Benutzer verwaltet seine eigenen Schlüssel in den Kontoeinstellungen. Organisationsadministratoren können steuern, ob Mitglieder API-Schlüssel erstellen dürfen. Siehe [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel) und [Zugangsdaten](/settings/organization/Zugangsdaten). * Der Zugriff auf Basis-KI-Modelle kann jetzt rollenbasiert verwaltet werden. Siehe [Modellauswahl](/arbeiten-mit-ki/modellauswahl) und [Rollenvorlagen](/settings/instance/Role-Templates). ## Verbessert * Gesprächstitel werden jetzt mit dem konfigurierten KI-Modell generiert, anstatt immer auf dasselbe Standardmodell zurückzugreifen. Siehe [KI-Konfiguration: Chats](/settings/organization/Chats). * Die Dokumentenverarbeitung ist dank einer verbesserten Pipeline jetzt schneller und zuverlässiger. Siehe [Dokumente: Verarbeitung](/settings/organization/Verarbeitung). * Rollen und Zugriffskontrollen wurden für zuverlässigere und vorhersehbarere Berechtigungsprüfungen überarbeitet. Siehe [Rollenvorlagen](/settings/instance/Role-Templates) und [Space-Rollen](/settings/organization/Space-Rollen). * Der Organisationsfilter in der Mitgliederliste zeigt jetzt alle Organisationen korrekt an. Siehe [Mitglieder](/settings/organization/Mitglieder). ## Behoben * Fehler beim Zurücksetzen des Passworts in Multi-Organisations-Konfigurationen behoben. * Fehler behoben, bei dem Tools in Konversationen nach dem Deaktivieren noch aktiv blieben. * Fehler mit dem Datentabellen-Tool in Konversationen behoben. * Fehler behoben, bei dem Benutzer in sekundären Organisationen nicht gelöscht werden konnten. * Fehler behoben, bei dem Einladungsbestätigungen nicht angezeigt wurden, wenn [E-Mail (SMTP)](/settings/organization/E-Mail-SMTP) nicht konfiguriert ist. * Fehler auf der Einladungs-Annahmeseite in bestimmten Konfigurationen behoben. * Fehler bei der Aktivierung von Workflow-Automatisierungs-Benutzern nach einem Update behoben. * Darstellungsfehler behoben, der dazu führte, dass bestimmte Ansichten falsch angezeigt wurden. * Fehler behoben, bei dem Dokumente nach einem Sitzungsfehler manchmal während der Verarbeitung hängen blieben. * Anfrage-Routing für den OpenAI-kompatiblen API-Endpunkt behoben. Siehe [OpenAI-kompatible API](/api-reference/OpenAI-Kompatibel). # v1.0.0-beta.6 — Admin-Ankündigungen und Mermaid-Diagramme im Chat Source: https://docs.localmind.ai/changelog/v1.0.0-beta.6 Release vom 1. Juni 2026 — Admin-Ankündigungen als Banner oder Dialog, Mermaid-Diagramme im Chat, verständliche Tool-Call-Limit-Benachrichtigung, mehrere Bugfixes. ## Neu * Mermaid-Diagramme werden jetzt direkt in Chat-Antworten gerendert. * Administratoren können jetzt Ankündigungen erstellen, die allen Benutzern als Banner oder Dialog angezeigt werden. Siehe [Instanz-Einstellungen](/settings/instance/overview). ## Verbessert * Wenn ein KI-Agent sein Tool-Call-Limit erreicht, wird jetzt eine verständliche Benachrichtigung in der Konversation angezeigt, anstatt still zu stoppen. Siehe [Werkzeuge](/core-functions/Werkzeuge). ## Behoben * Fehler behoben, bei dem Konversationen in der Seitenleiste anderer Space-Mitglieder erschienen. Siehe [Chat History](/navigation/Chat-History). * Fehler beim Duplizieren der Space-Viewer-Rolle in den Organisationseinstellungen behoben. Siehe [Space-Rollen](/settings/organization/Space-Rollen). * Fehler behoben, bei dem die Passwortänderung nach einem Update fehlschlug. Siehe [Authentifizierung](/settings/organization/Authentifizierung). # v1.0.0-beta.7 — Bildgenerierung im Chat und OpenAI-kompatible API Source: https://docs.localmind.ai/changelog/v1.0.0-beta.7 Release vom 15. Juni 2026 — Bildgenerierung in Konversationen, Konversationen per Link teilen, Ungelesen-Indikator, OpenAI-kompatible API-Endpunkte, Prompt-Caching, Audit-Log-Verbesserungen. ## Neu * KI-Agenten können jetzt Bilder direkt in Konversationen mithilfe von Bildgenerierungsmodellen erstellen und bearbeiten. Siehe [Werkzeuge](/core-functions/Werkzeuge). * Konversationen können jetzt über einen Link mit anderen Space-Mitgliedern geteilt werden, optional mit einem Ablaufdatum. Siehe [Chat History](/navigation/Chat-History). * Die Space-Seitenleiste zeigt jetzt einen Ungelesen-Indikator bei Konversationen an, die seit dem letzten Besuch neue Nachrichten erhalten haben. Siehe [Chat History](/navigation/Chat-History). * OpenAI-kompatible API-Endpunkte (`GET /v1/models` und `POST /v1/chat/completions`) sind jetzt verfügbar und über persönliche API-Schlüssel zugänglich, was die Konfiguration externer Integrationen vereinfacht. Siehe [OpenAI-kompatible API](/api-reference/OpenAI-Kompatibel) und [API-Einführung](/api-reference/introduction). * Audit-Log-Einträge enthalten jetzt eine verbesserte Identitätsanzeige und einen Statusindikator pro Ereignis. Siehe [Audit Logs](/settings/instance/Audit-Logs). ## Verbessert * Antworten sind jetzt schneller und kosteneffizienter dank automatischem Prompt-Caching. Siehe [API-Einführung](/api-reference/introduction). ## Behoben * Fehler behoben, bei dem der Lade-Indikator von Widgets nach dem Abschluss der Agenten-Antwort nicht aufgehört hat zu drehen. * Fehler behoben, bei dem Organisations- und Space-Admins keine Berechtigung hatten, Widgets zu erstellen oder zu veröffentlichen. * Mehrere visuelle Fehler beim Interface-Theming behoben, darunter ein Farbwähler, der im Light Mode nicht korrekt funktionierte. * Fehler behoben, bei dem Ankündigungs-Banner in bestimmten Konfigurationen nicht korrekt angezeigt wurden. Siehe [Instanz-Einstellungen](/settings/instance/overview#ankündigungen). # v1.0.0-beta.8 — OAuth-Integrationen und 2FA-Selbstverwaltung Source: https://docs.localmind.ai/changelog/v1.0.0-beta.8 Release vom 22. Juni 2026 — SharePoint-, Outlook- und Teams-OAuth-Integrationen, Zwei-Faktor-Authentifizierung selbst deaktivieren, Bibliothek-Sortierung und Duplizieren-Fixes. ## Neu * SharePoint, Outlook, Teams und mehr können jetzt als OAuth-Integrationen verbunden werden, sodass KI-Agenten auf Inhalte dieser Plattformen zugreifen und damit arbeiten können. Siehe [Integrationen nutzen](/integrations/Integrationen-Nutzen) und [SharePoint einrichten](/integrations/SharePoint). * Benutzer können ihre eigene Zwei-Faktor-Authentifizierung jetzt in den Kontoeinstellungen deaktivieren. Siehe [Authentifizierung](/settings/organization/Authentifizierung). ## Behoben * Fehler behoben, bei dem die Admin-Option zum Zurücksetzen der Zwei-Faktor-Authentifizierung für Benutzer, die 2FA vor beta.5 eingerichtet hatten, nicht angezeigt wurde. Siehe [Authentifizierung](/settings/organization/Authentifizierung). * Die Bibliothek ordnet ihre Einträge nach einer Installation nicht mehr neu an; Einträge werden jetzt standardmäßig alphabetisch sortiert. Siehe [Bibliothek](/library/overview). * Systemseitig bereitgestellte Werkzeuge in der Bibliothek bieten die ohnehin fehlschlagende Duplizieren-Option nicht mehr an; sie können nur verlinkt werden. Siehe [Bibliothek](/library/overview). # v1.1.0 — Fehlerbehebung bei OAuth-Zugangsdaten in Automate Source: https://docs.localmind.ai/changelog/v1.1.0 Wartungsrelease vom 24. Juli 2026 — behebt die Erstellung von OAuth-Zugangsdaten in Automate. ## Behoben * Fehler in der Workflow-Automatisierung behoben, bei dem OAuth-Zugangsdaten nicht erstellt werden konnten, da der Autorisierungs-Callback fehlschlug. Siehe [Sicherheit in Automate](/automate/security). # v1.2.0 — Poststelle (Beta), Analytik-Exporte und Modellwahl in Dokumenten-Apps Source: https://docs.localmind.ai/changelog/v1.2.0 Release vom 13. August 2026 — Poststelle (Beta), Analytik-Exporte, Modellwahl in Dokumenten-Apps. ## Neu * Neue App: **Poststelle (Beta)** – verbinden Sie die Postfächer Ihrer Organisation und lassen Sie eingehende Post automatisch sortieren. Regeln – auf Wunsch mit KI-Unterstützung – klassifizieren jede E-Mail und schlagen die Weiterleitung an die richtigen Empfänger vor; Sie geben frei, bevor etwas versendet wird, oder lassen vertrauenswürdige Regeln automatisch weiterleiten. Die KI kann außerdem Antwortentwürfe vorbereiten, die immer von einer Person geprüft und versendet werden. Siehe [Poststelle](/apps/Poststelle). * Administratoren können in der Analytik jetzt vollständige Gesprächsverläufe von Konversationen öffnen und exportieren, die mit Admins geteilt werden – einschließlich Website-Widget-Chats, die zuvor nicht eingesehen werden konnten. Siehe [Analytik](/administration/observability#analytik). * In den Dokumenten-Apps (Analyse, Vergleich, Extraktion und mehr) kann jetzt das verwendete KI-Modell gewählt werden – als Administrator-Standard pro Space und persönlich pro App. Siehe [Dokumentenanalyse](/apps/Document-Analysis), [Dokumentenvergleich](/apps/Document-Comparison) und [Dokumentenextraktion](/apps/Document-Extraction). ## Verbessert * Die Workflow-Automatisierung wurde auf eine neue Hauptversion aktualisiert – mit zahlreichen Verbesserungen am eingebetteten Editor und strikterer Isolation: Code-Schritte laufen jetzt in einer separaten, netzwerkisolierten Umgebung. Siehe [Automate](/automate/overview) und [Sicherheit in Automate](/automate/security). * Code-Ausführung muss nicht mehr als separates Werkzeug konfiguriert werden – sie wird automatisch aktiviert, wenn ein Agent Skills verwendet. Siehe [Werkzeuge](/core-functions/Werkzeuge#skills-und-die-code-sandbox) und [Administration → Werkzeuge](/administration/Werkzeuge). * Interne Konversationsdaten werden jetzt beim Löschen von Konversationen sowie regelmäßig automatisch bereinigt, damit die Datenbank nicht unnötig wächst. * Die Übersetzung einer Datei startet nicht mehr sofort beim Auswählen: Das Dokument wird mit Namen und Größe angezeigt, sodass das Sprachpaar vor dem Absenden noch korrigiert werden kann. Siehe [Übersetzung](/apps/Translation). * Zahlreiche Sicherheitsupdates in der gesamten Plattform und ihren mitgelieferten Diensten. ## Behoben * Fehler behoben, bei dem der Credit-Verbrauch bei fehlendem Preis falsch berechnet wurde: Dienste wie OCR wurden mit dem Ersatzwert pro Seite statt einmalig pro Auftrag verrechnet, und der Ersatzwert konnte später wie ein echter Preis weiterverwendet werden. Credit-Limits gelten jetzt außerdem auch für Konversationen im Website-Widget. Siehe [Nutzungsübersicht](/administration/Nutzungsübersicht). * Fehler behoben, bei dem Listen nur ihre ersten zehn Einträge zeigten: Die Werkzeug-Übersicht meldete „10 Einträge" für einen Space mit mehr, und im Agenten-Konfigurationsbereich standen nur zehn Werkzeuge zur Auswahl – ein frisch importierter Skill ließ sich dort nicht zuweisen. Siehe [Werkzeuge](/core-functions/Werkzeuge). * Fehler behoben, bei dem in einer Konversation angehängte Dateien für Mitglieder unbrauchbar waren, deren Heimat-Organisation von der Organisation des Space abweicht – die Datei wurde am falschen Ort abgelegt und konnte von Agenten nicht gelesen werden. * Fehler behoben, bei dem das integrierte Websuche-Werkzeug in manchen Installationen nach dem Update auf 1.0.0 nicht verfügbar war. Siehe [Werkzeuge](/core-functions/Werkzeuge). * Fehler behoben, bei dem hochgeladene Dateien mit Sonderzeichen im Namen kurzzeitig doppelt in der Dateiliste erschienen. * Fehler behoben, bei dem Datumsfilter im Audit-Log in der falschen Zeitzone angewendet wurden und Tage in den Analytik-Diagrammen in Zeitzonen westlich von UTC um einen Tag verschoben beschriftet waren. Siehe [Audit-Logs](/settings/instance/Audit-Logs) und [Analytik](/administration/observability#analytik). * Layout-Probleme in der Mitgliederverwaltung der Organisation behoben, darunter eine überlaufende Mitgliedertabelle und abgeschnittene Auswahlmenüs. Siehe [Mitglieder](/settings/organization/Mitglieder). * Fehler behoben, bei dem im Agenten-Auswahlmenü des Chats das Modell-Logo über dem Agentennamen lag und statt lesbarer Namen interne Anbieter-Kürzel angezeigt wurden. * Fehler behoben, bei dem das Abmelden in bestimmten Konfigurationen nicht zuverlässig funktionierte. * Fehler behoben, bei dem fehlgeschlagene Dokumentverarbeitungen hängende Einträge in der Verarbeitungswarteschlange hinterließen. Siehe [Verarbeitung](/settings/organization/Verarbeitung). * Die Bibliothek verweigert jetzt die Installation von Einträgen, die sie nicht verarbeiten kann, anstatt eine fehlerhafte Installation anzulegen. Siehe [Bibliothek](/library/overview). # Unterauftragsverarbeiter Source: https://docs.localmind.ai/compliance/Sub-Processors Verzeichnis aller Unterauftragsverarbeiter von Localmind gemäß DSGVO ## EU Cloud Modelle Die folgenden Unterauftragsverarbeiter werden für den Betrieb der EU-Cloud-Instanzen eingesetzt. | Unternehmen | Zweck der Verarbeitung | Region | Datenschutz-Link | | ---------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Hetzner Online GmbH** | Hosting und Infrastrukturbereitstellung der virtuellen Localmind-Maschinen | Deutschland | [https://www.hetzner.com/de/legal/privacy-policy/](https://www.hetzner.com/de/legal/privacy-policy/) | | **Timewarp Wien** | Hosting und Infrastrukturbereitstellung | Österreich | [https://www.localmind.ai/downloads/avv/twlm-avv.pdf](https://www.localmind.ai/downloads/avv/twlm-avv.pdf) | | **Mistral** | Prozessieren von Bildern in diversen Dokumentenprozesspipelines, allgemeine Bereitstellung von KI-Modellen | Frankreich | [https://mistral.ai/terms#privacy-policy](https://mistral.ai/terms#privacy-policy) | | **Nebius** | Allgemeine Bereitstellung von KI-Modellen | GPU-Datencenter: Finnland, Operations & Business: Deutschland, Israel | [https://docs.nebius.com/legal/dpa](https://docs.nebius.com/legal/dpa) | | **Scrapingbee** | Web-Scraping zur Datenextraktion für den Web-Funktionsskill von Localmind AI | Frankreich | [https://www.scrapingbee.com/data-processing-agreement/](https://www.scrapingbee.com/data-processing-agreement/) | | **VERTEX (Google Gemini)** | Allgemeine Bereitstellung von KI-Modellen | EU | [https://cloud.google.com/terms/data-processing-addendum](https://cloud.google.com/terms/data-processing-addendum) | | **Black Forest Labs (FLUX)** | Nutzung der API zur Bereitstellung von Bildgenerierungs-KI-Modellen | EU | [https://bfl.ai/legal/privacy-policy](https://bfl.ai/legal/privacy-policy) | | **Microsoft Azure** | Nutzung der API zur Bereitstellung von KI-Modellen | EU | [https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA](https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA) | | **STACKIT** | Hosting und Infrastrukturbereitstellung der virtuellen Localmind-Maschinen | Deutschland | [https://stackit.com/de/agb/cloud-services](https://stackit.com/de/agb/cloud-services) | *** ## Lokale Modelle Die folgenden Unterauftragsverarbeiter werden für den Betrieb lokaler Modell-Instanzen eingesetzt. | Unternehmen | Zweck der Verarbeitung | Region | Datenschutz-Link | | ----------------------- | ---------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------- | | **Hetzner Online GmbH** | Hosting und Infrastrukturbereitstellung der virtuellen Localmind-Maschinen | Deutschland | [https://www.hetzner.com/de/legal/privacy-policy/](https://www.hetzner.com/de/legal/privacy-policy/) | | **Scrapingbee** | Web-Scraping zur Datenextraktion für den Web-Funktionsskill von Localmind AI | Frankreich | [https://www.scrapingbee.com/data-processing-agreement/](https://www.scrapingbee.com/data-processing-agreement/) | | **Notion** | Aufgabenverwaltung, ERP und CRM | USA | [https://www.notion.com/help/gdpr-at-notion](https://www.notion.com/help/gdpr-at-notion) | | **Timewarp Wien** | Hosting und Infrastrukturbereitstellung | Österreich | [https://www.localmind.ai/downloads/avv/twlm-avv.pdf](https://www.localmind.ai/downloads/avv/twlm-avv.pdf) | *** Dieses Verzeichnis wird laufend aktualisiert. Bei Fragen zu unseren Unterauftragsverarbeitern erreichst du uns unter [hello@localmind.ai](mailto:hello@localmind.ai). # Dokumente Source: https://docs.localmind.ai/compliance/documents Compliance-Dokumente von Localmind zum Download Alle relevanten Compliance-Dokumente von Localmind zum Download: # Dokumente Source: https://docs.localmind.ai/core-functions/Dokumente Dokumente hochladen und durch die Parsing Engine für KI-Agenten aufbereiten lassen. Dokumente sind der häufigste Datentyp in Localmind. Du kannst PDFs, Word-Dateien und andere Dokumentformate hochladen, die anschließend automatisch für deine [Agenten](/core-functions/agents) aufbereitet werden. ## Dokumente hochladen Navigiere zu **Ressourcen → Daten** und lade Dateien hoch oder erstelle Ordner, um deine Dokumente thematisch zu organisieren. Auch ZIP-Archive kannst du hochladen: Deren Inhalte werden automatisch extrahiert und wie einzeln hochgeladene Dokumente verarbeitet. ## Verarbeitung durch die Parsing Engine Nach dem Upload durchläuft jedes Dokument die **Parsing Engine**: 1. **Text-Extraktion** — Der Inhalt wird aus dem Dateiformat extrahiert (z.B. aus PDF-Seiten oder Word-Absätzen). 2. **Markdown-Konvertierung** — Der extrahierte Text wird in ein einheitliches Markdown-Format überführt. 3. **Chunking** — Das Dokument wird in kleinere, zusammenhängende Abschnitte (Chunks) zerlegt, die KI-Modelle effizient verarbeiten können. 4. **Embedding** — Die Chunks werden in Vektoren umgewandelt und für die Hybrid Search indexiert. Dokumentenansicht mit hochgeladenen Dateien und deren Verarbeitungsstatus Die Chunks werden automatisch für die Suche optimiert. Wenn du einem Agenten das **Daten**-Tool (Hybrid Search) zuweist, kann er gezielt relevante Stellen in deinen Dokumenten finden – auch bei ungenauer Fragestellung. ## Verwendung durch Agenten Hochgeladene Dokumente stehen Agenten über folgende [Werkzeuge](/core-functions/Werkzeuge) zur Verfügung: * **Daten** — Durchsucht den Inhalt deiner Dokumente per Hybrid Search nach relevanten Abschnitten. * **Document Analysis** — Analysiert Dokumente Seite für Seite und kann Inhalte zusammenfassen oder vergleichen. # Einstieg Source: https://docs.localmind.ai/core-functions/Einstieg Einstieg in die Datentypen im Space – Dokumente, Tabellen und Webseiten. Im Bereich **Daten** verwaltest du alle Inhalte, auf die deine [Agenten](/core-functions/agents) über [Werkzeuge](/core-functions/Werkzeuge) zugreifen können. Du findest ihn unter **Ressourcen → Daten**. Localmind unterscheidet drei Datentypen: PDFs, Word-Dateien und andere Dokumente, die durch die Parsing Engine verarbeitet und für KI-Modelle aufbereitet werden. Strukturierte Daten in Tabellenform, auf die Agenten per Data-Tables-Werkzeug zugreifen können. URLs, deren Inhalte abgerufen, geparst und als Wissensquelle bereitgestellt werden. ## Wie werden Daten für KI nutzbar? Dokumente und Webseiten durchlaufen die **Verarbeitungs-Pipeline**: Sie analysiert den Inhalt, extrahiert den Text und zerlegt ihn in **Markdown-Chunks**, die KI-Modelle effizient durchsuchen und verstehen können. Tabellen bleiben strukturiert und werden direkt abgefragt – sie durchlaufen die Pipeline nicht. Die Datenverwaltung (Hochladen, Ordnen, Konfigurieren) findet hier statt. Die eigentliche Abfrage durch den Agenten erfolgt über [Werkzeuge](/core-functions/Werkzeuge) wie **Daten** (Hybrid Search) oder Data Tables. # Tabellen Source: https://docs.localmind.ai/core-functions/Tabellen Strukturierte Daten in Tabellenform verwalten und per Agent abfragen lassen. Tabellen (Data Tables) ermöglichen es dir, strukturierte Daten im Space zu verwalten – z.B. Produktlisten, Kontaktdaten oder Auswertungen. Agenten können diese Daten über das **Data Tables**-Werkzeug lesen und bearbeiten. ## Tabellen erstellen Navigiere zu **Ressourcen → Daten** und erstelle eine neue Tabelle. Du kannst Spalten definieren und Daten manuell eingeben oder importieren. ## Spalten-Typen Beim Anlegen einer Spalte wählst du einen der folgenden Typen: | Typ | Geeignet für | | -------------------- | ------------------------------------------------------- | | **Langer Text** | Mehrzeilige Freitexte, z.B. Beschreibungen oder Notizen | | **Kurztext** | Einzeilige Werte, z.B. Namen, IDs oder Kategorien | | **Zahl** | Ganzzahlen, z.B. Stückzahlen | | **Dezimalzahl** | Zahlen mit Nachkommastellen, z.B. Preise | | **Datum** | Kalenderdaten ohne Uhrzeit | | **Datum & Uhrzeit** | Zeitstempel mit Datum und Uhrzeit | | **Kontrollkästchen** | Ja/Nein-Werte | Zusätzlich legst du pro Spalte zwei Eigenschaften fest: * **Primärschlüssel** — Die Spalte identifiziert jede Zeile eindeutig. * **Nullable** — Die Spalte darf in einzelnen Zeilen leer bleiben. ## Wie werden Tabellen genutzt? Wenn du einem [Agenten](/core-functions/agents) das **Data Tables**-[Werkzeug](/core-functions/Werkzeuge) zuweist, kann er: * **Einträge lesen** — Daten aus Tabellen abfragen und in Antworten einbeziehen * **Einträge erstellen** — Neue Zeilen basierend auf Benutzeranfragen hinzufügen * **Einträge aktualisieren** — Bestehende Daten ändern * **Einträge löschen** — Zeilen entfernen Tabellen werden nicht durch die Parsing Engine verarbeitet wie Dokumente. Sie bleiben in ihrer strukturierten Form erhalten und sind über das Data-Tool strukturiert abfragbar. # Terminologie Source: https://docs.localmind.ai/core-functions/Terminology Wichtige Begriffe rund um KI-Agenten einfach erklärt. Diese Übersicht erklärt die wichtigsten Begriffe, die dir bei der Arbeit mit KI-Agenten begegnen – alphabetisch sortiert. Das Modell wird angewiesen, seinen **Denkprozess offenzulegen** – Schritt für Schritt. **Trigger-Phrase:** "Denke Schritt für Schritt" oder "Erkläre deinen Denkweg" **Numerische Repräsentationen** von Text als Vektoren (Listen von Zahlen). Ähnliche Texte haben ähnliche Vektoren. **Verwendet für:** * Semantische Suche * Dokumenten-Ähnlichkeit * RAG-Systeme Dem Modell werden **Beispiele** gezeigt, bevor es die eigentliche Aufgabe löst. ``` Beispiel 1: Input → Output Beispiel 2: Input → Output Deine Anfrage: Input → ? ``` **Vorteil:** Modell versteht das gewünschte Format besser. Wenn ein Modell **falsche Informationen überzeugend präsentiert** – Fakten erfindet, die nicht existieren. **Ursachen:** * Frage liegt außerhalb des Trainingswissens * Modell "füllt Lücken" mit plausibel klingendem Text **Gegenmaßnahmen:** * RAG verwenden (Dokumente als Quelle) * Modell anweisen: "Sage wenn du unsicher bist" * Quellen/Zitate einfordern Kombination aus **semantischer Suche** (Bedeutung) und **Keyword-Suche** (exakte Wörter) für beste Ergebnisse. In Localmind führt das **Data-Tool** (UI: „Daten") die Hybrid Search aus. Die **maximale Textmenge**, die ein Modell gleichzeitig verarbeiten kann – gemessen in Tokens. | Größe | Entspricht ca. | | ----------- | ------------------ | | 8k Tokens | 12 Seiten Text | | 32k Tokens | 50 Seiten Text | | 128k Tokens | 200 Seiten Text | | 1M+ Tokens | 1.500+ Seiten Text | **Wichtig:** Das Kontextfenster umfasst sowohl deine Eingabe als auch die Antwort des Modells. Modelle, die **verschiedene Medientypen** verarbeiten können: * Text * Bilder * Audio * Video (bei einigen Modellen) **Beispiel:** aktuelle Claude- und Gemini-Modelle Eine Technik, bei der das Modell **zuerst relevante Dokumente abruft** und dann basierend auf diesen antwortet. ``` Frage → Dokumente durchsuchen → Relevante Stellen finden → Antwort generieren ``` **Vorteile:** * Antworten basieren auf deinen Daten * Reduziert Halluzinationen * Aktuellere Informationen als das Trainings-Cutoff In Localmind aktivierst du RAG, indem du dem Agenten das **Data-Tool** (UI: „Daten") zuweist — es durchsucht deine Dokumente per Hybrid Search. Modelle mit Reasoning **denken schrittweise nach**, bevor sie antworten. Sie zerlegen komplexe Probleme in Teilschritte. **Ideal für:** * Mathematische Berechnungen * Logische Schlussfolgerungen * Mehrstufige Analysen * Wissenschaftliche Probleme **Ohne Reasoning:** Modell antwortet direkt. **Mit Reasoning:** Modell plant → denkt → prüft → antwortet. Die **grundlegende Anweisung**, die das Verhalten des Agenten definiert. Wird vor jeder Konversation geladen. **Enthält typischerweise:** * Rolle des Agenten * Verhaltensregeln * Ausgabeformat * Einschränkungen Steuert die **Kreativität** der Antworten. | Wert | Verhalten | | ------- | -------------------------------------------- | | 0.0 | Deterministisch – immer die gleiche Antwort | | 0.3–0.7 | Ausgewogen – leichte Variation | | 1.0+ | Kreativ – unvorhersehbare, diverse Antworten | **In Localmind:** nicht pro Agent einstellbar – bei [API-Nutzung](/api-reference/OpenAI-Kompatibel) wird `temperature` an das Modell durchgereicht. Die **Grundeinheit**, in der KI-Modelle Text verarbeiten. Ein Token ist ungefähr: * 4 Zeichen im Englischen * 3 Zeichen im Deutschen * 1 häufiges Wort oder Wortteil **Beispiel:** "Localmind ist großartig" ≈ 5 Tokens Begrenzt die Auswahl auf die **K wahrscheinlichsten nächsten Wörter**. | Wert | Verhalten | | ---- | ------------------------------- | | 1 | Nur das wahrscheinlichste Wort | | 40 | Auswahl aus den Top 40 Optionen | | 100+ | Sehr breite Auswahl | **In Localmind:** nicht einstellbar – über die API wird nur `temperature` durchgereicht, nicht `top_k`. Begrenzt die Auswahl auf die **wahrscheinlichsten Wörter**, deren kumulierte Wahrscheinlichkeit den Wert P erreicht. | Wert | Verhalten | | ---- | --------------------------------------------- | | 0.1 | Sehr fokussiert – nur die sichersten Optionen | | 0.9 | Breite Auswahl – mehr Variation | | 1.0 | Keine Einschränkung | **In Localmind:** nicht einstellbar – über die API wird nur `temperature` durchgereicht, nicht `top_p`. Eine Datenbank, die **Embeddings speichert** und schnelle Ähnlichkeitssuchen ermöglicht. Localmind verwaltet dies automatisch im Hintergrund. Das Modell löst eine Aufgabe **ohne Beispiele** – nur basierend auf der Anweisung. # Webseiten Source: https://docs.localmind.ai/core-functions/Webseiten Webseiten als Wissensquelle einbinden – Inhalte werden geparst und für KI-Agenten aufbereitet. Du kannst URLs als Datenquelle hinzufügen. Localmind ruft den Inhalt der Webseite ab, verarbeitet ihn durch die **Parsing Engine** und stellt ihn deinen [Agenten](/core-functions/agents) als durchsuchbare Wissensquelle zur Verfügung. ## Webseite hinzufügen Navigiere zu **Ressourcen → Daten** und füge eine URL hinzu. Der Inhalt der Seite wird automatisch abgerufen und verarbeitet. ## Verarbeitung Webseiten durchlaufen denselben Prozess wie [Dokumente](/core-functions/Dokumente): 1. **Inhalt abrufen** — Die Seite wird geladen und der Textinhalt extrahiert. 2. **Markdown-Konvertierung** — Der Inhalt wird in ein einheitliches Markdown-Format überführt. 3. **Chunking** — Der Text wird in kleinere Abschnitte zerlegt, die KI-Modelle effizient verarbeiten können. 4. **Embedding** — Die Chunks werden in Vektoren umgewandelt und für die Hybrid Search indexiert. ## Verwendung durch Agenten Webseiten-Inhalte stehen Agenten über das [Werkzeug](/core-functions/Werkzeuge) **Daten** (Hybrid Search) zur Verfügung. Der Agent kann relevante Abschnitte aus den gespeicherten Webseiten-Inhalten finden und in seine Antworten einbeziehen. Der Inhalt wird einmalig beim Hinzufügen abgerufen und danach nicht automatisch aktualisiert. Ändert sich die Quellseite, füge die URL erneut hinzu, damit der neue Stand verarbeitet wird. # Werkzeuge Source: https://docs.localmind.ai/core-functions/Werkzeuge Tools und Integrationen, die Agenten im Space verwenden können – von Bibliotheks-Tools über eigene MCP-Server bis zu Skills. Werkzeuge sind Fähigkeiten und Integrationen, die [Agenten](/core-functions/agents) innerhalb eines Space nutzen können. Du findest sie unter **Ressourcen → Werkzeuge**. ## Vorhandene Werkzeuge In vielen Spaces sind bereits Standard-Tools aus der [Library](/library/overview) verlinkt. Diese erscheinen mit dem Hinweis **„Aus Bibliothek verlinkt"** und stehen sofort zur Verfügung: Durchsucht deine hochgeladenen Dokumente per Hybrid Search nach relevanten Inhalten – auch wenn du nicht die exakten Suchbegriffe kennst. Ideal, wenn ein Agent Fragen anhand deiner Wissensbasis beantworten soll. Analysiert hochgeladene Dokumente Seite für Seite und kann Inhalte zusammenfassen, vergleichen oder gezielt Informationen extrahieren. Ermöglicht dem Agenten, aktuelle Informationen aus dem Internet abzurufen – z.B. wenn deine Wissensbasis nicht ausreicht oder tagesaktuelle Daten benötigt werden. Erzeugt Bilder direkt aus Text-Prompts im Chat (Bildgenerierungsmodell) und bettet sie in die Antwort ein. Gibt dem Agenten Zugriff auf strukturierte Daten in Tabellen. Er kann Einträge lesen, erstellen, aktualisieren und löschen. Der Agent kann im Chat strukturierte Eingaben über Formularfelder abfragen. „Aus Bibliothek verlinkt" bedeutet, dass das Tool aus einem vorkonfigurierten Standardset stammt, das in der [Library](/library/overview) verwaltet wird. Diese Tools können direkt Agenten zugewiesen werden. ## Integrierte Konnektoren Neben den Standard-Tools gibt es vorgebaute, OAuth-basierte Konnektoren zu externen Diensten: **Jira, Confluence, Notion, SharePoint, Outlook** und **Microsoft Teams**. Ein Administrator stellt sie einmalig org-weit bereit und gibt sie über die [Library](/library/overview) in deinen Space frei. Sobald das der Fall ist, nutzt dein Agent sie wie jedes andere Werkzeug – du verbindest beim ersten Aufruf im Chat dein eigenes Konto. Wie du Konnektoren im Chat nutzt und dein Konto verbindest, liest du unter [Integrationen verwenden](/integrations/Integrationen-Nutzen). Die Einrichtung auf Organisationsebene ist im Administration-Tab beschrieben. ## Neues Werkzeug hinzufügen Du kannst eigene Tool-Server (MCP) anbinden, um die Fähigkeiten deiner Agenten zu erweitern. Navigiere zu **Werkzeuge → Tool hinzufügen**. Vergib einen aussagekräftigen **Namen** (Pflicht) und optional eine **Beschreibung**, die erklärt, was der Tool-Server bereitstellt. Wähle einen der sechs Verbindungstypen: Verbindung zu einem entfernten MCP-Server über eine HTTP-URL. Geeignet für bereits gehostete MCP-Server. **Erforderlich:** Server-URL Führt einen MCP-Server aus einem npm-Paket mit `npx` aus. Geeignet für Community- und Open-Source-MCP-Server, die als npm-Paket verfügbar sind. **Erforderlich:** Paketname Führt einen MCP-Server aus einem Python-Paket mit `uvx` aus. Geeignet für Python-basierte MCP-Server. **Erforderlich:** Paketname Verbindung zu REST-API-Endpunkten mit benutzerdefinierter Konfiguration. Geeignet für eigene APIs, die kein MCP-Protokoll sprechen. **Erforderlich:** Endpoint-URL, ggf. Auth-Konfiguration Generiert Werkzeuge automatisch aus einer OpenAPI-Spezifikation. Geeignet, wenn eine API bereits eine OpenAPI/Swagger-Beschreibung mitbringt. **Erforderlich:** OpenAPI-Spec-URL oder -Datei Bündelt eine `SKILL.md`-Anleitung mit optionalen Code-Dateien, die der Agent in einer isolierten **Code-Sandbox** ausführt. Geeignet für deterministische Aufgaben per Code – Details unter [Skills und die Code-Sandbox](#skills-und-die-code-sandbox). **Erforderlich:** `SKILL.md`, optional Code- und Vorlagen-Dateien Dialog zum Hinzufügen eines Werkzeugs mit Tabs für Remote-HTTP, NPX-Paket, Python-Paket, HTTP API und OpenAPI Je nach Verbindungstyp gibst du hier die HTTP-Endpoint-URL für den Tool-Server ein. Der Typ **Skill** benötigt keine Server-URL – hier hinterlegst du stattdessen die `SKILL.md` und optionale Skill-Dateien. Füge optionale Konfigurationsvariablen als **Schlüssel/Wert-Paare** hinzu (z.B. API-Keys oder Umgebungsparameter). Werte können als **„Sicher"** markiert werden – sichere Werte werden in der Oberfläche maskiert angezeigt. Klicke auf **Verbindung testen**, um zu prüfen, ob der Tool-Server erreichbar und korrekt konfiguriert ist. **Speichern** legt den Tool-Server im Space an. **Abbrechen** verwirft die Eingaben. **Admin-Sicht:** Wie Tool-Server zentral in der Library angelegt und an mehrere Spaces verteilt werden, siehst du in [Administration → Werkzeuge](/administration/Werkzeuge). Erreicht ein Agent während einer Konversation sein **Tool-Call-Limit**, erscheint eine verständliche Benachrichtigung direkt in der Konversation, statt dass der Agent still stoppt. So weißt du sofort, warum die Antwort endet, und kannst den Agenten gezielt erneut beauftragen. ## Skills und die Code-Sandbox Neben den fünf Verbindungstypen Remote-HTTP, NPX-Paket, Python-Paket, HTTP API und OpenAPI gibt es den Typ **Skill**: Ein Skill bündelt eine `SKILL.md`-Anleitung mit optionalen Code-Dateien, die der Agent in einer isolierten **Code-Sandbox** ausführt. So erledigt ein Agent deterministische Aufgaben per Code – zum Beispiel Office-Dateien erzeugen. Du legst einen Skill unter **Werkzeuge → Tool hinzufügen → Typ „Skill"** an. Seit [v1.2.0](/changelog/v1.2.0) wird die Code-Ausführung dabei automatisch aktiviert, sobald ein Agent Skills verwendet – du musst sie nicht mehr separat als Werkzeug konfigurieren. Die Office-Fähigkeiten (DOCX, PDF, PPTX, XLSX) sind zugleich Standard-Tool und Skill: Sie stehen als eingebautes Tool bereit und laufen technisch als Skill in der Code-Sandbox. ### Dateien für deinen Code Dateien, die dein Code in der Sandbox braucht, gehören als **Skill-Dateien** in den Skill – auch binäre Dateien, zum Beispiel eine Vorlagen-Datei für generierte Dokumente. **Chat-Anhänge erreichen die Sandbox nicht als Datei** – sie stehen dem Agenten nur als Text-Auszug im Kontext zur Verfügung. Alles, was dein Code als Datei verarbeiten soll, hinterlegst du als Skill-Datei im Skill. ### Zugangsdaten in der Sandbox Braucht dein Code Zugangsdaten für einen externen Dienst, gelten diese Regeln: * Nur **Organisations-Zugangsdaten**, die unter **Org-Einstellungen → KI-Konfiguration → Code-Sandbox** verknüpft (angehakt) sind, werden als Umgebungsvariablen in die Sandbox injiziert. * **Space-Zugangsdaten** werden **nicht** injiziert. * Änderungen an der Verknüpfung wirken nur für **neu** gestartete Sandboxen. Die Code-Sandbox-Einstellungen (verknüpfte Zugangsdaten, Ressourcen-Grenzen) verwaltet dein Administrator – siehe [Administration → Werkzeuge](/administration/Werkzeuge). Wie Zugangsdaten angelegt werden, liest du unter [Zugangsdaten](/settings/organization/Zugangsdaten). ### Netzwerkzugriff Der Netzwerkzugriff der Sandbox richtet sich nach der Netzwerkrichtlinie deiner Instanz – was erreichbar ist (z.B. für die Installation von Paketen), konfiguriert dein Administrator. Details siehe [Administration → Werkzeuge](/administration/Werkzeuge). ### Best Practices für Skill-Autoren * **Entwickle test-getrieben:** Führe den Skill mit realistischen Beispiel-Aufgaben aus und verfeinere die `SKILL.md`, bis das Ergebnis zuverlässig stimmt. * **Die Beschreibung beantwortet „Wann nutzen?":** Der Agent entscheidet anhand der Beschreibung, ob er den Skill einsetzt – beschreibe die Situation, nicht nur die Funktion. * **Halte die Anleitung knapp:** Ein gutes Beispiel plus ein Hinweis auf die Grenzen des Skills wirkt besser als lange Erklärungen. * **Verzichte auf Formeln wie „CRITICAL!" oder „YOU MUST":** Klare, neutrale Anweisungen funktionieren zuverlässiger als Druck-Formulierungen. * **Halte den System-Prompt kurz:** Die Detail-Anleitung gehört in die `SKILL.md`, nicht in den System-Prompt des Agenten. Der wichtigste Hebel ist die Beschreibung: Ein Skill mit präziser „Wann nutzen?"-Beschreibung wird vom Agenten im richtigen Moment gewählt – und im falschen ignoriert. # Agent erstellen Source: https://docs.localmind.ai/core-functions/agents KI-Agenten im Space erstellen, konfigurieren und mit Tools ausstatten. Agenten sind konfigurierbare KI-Assistenten innerhalb eines [Space](/navigation/Spaces). Du legst fest, welches Modell ein Agent nutzt, wie er sich verhält und auf welche [Werkzeuge](/core-functions/Werkzeuge) er zugreifen darf. ## Agent erstellen Navigiere zu **Ressourcen → Agenten → Agent erstellen**, um einen neuen Agenten anzulegen. Lade ein Bild hoch, das deinen Agenten repräsentiert. Format- und Größenvorgaben zeigt dir das Upload-Feld an. Fülle die folgenden Felder aus: * **Name** (Pflicht) — Der Anzeigename deines Agenten * **Beschreibung** (optional) — Kurze Beschreibung, was der Agent macht * **Modell** (Pflicht) — Das LLM-Modell, das der Agent nutzt. Im Dropdown erscheinen nur Modelle, die deinem Space über die [Library](/library/overview) bereitgestellt wurden. Eine Übersicht der Modellkategorien findest du unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). * **System-Prompt** (Pflicht) — Definiert das Grundverhalten, die Rolle und die Tonalität des Agenten. Tipps dazu findest du unter [Prompting-Grundlagen](/arbeiten-mit-ki/Prompting-Grundlagen). Formular zur Agent-Erstellung mit den Feldern Name, Beschreibung, Modell-Dropdown und System-Prompt-Editor Im System-Prompt-Editor stehen dir zwei Hilfsfunktionen zur Verfügung: * **Prompt verbessern** — Optimiert deinen Prompt automatisch, z.B. durch klarere Rollenanweisungen oder Regeln. * **Variable einfügen** — Fügt vordefinierte Variablen/Platzhalter in den Prompt ein. Die verfügbaren Variablen hängen von der Systemkonfiguration ab. Nutze [Prompt-Templates](/arbeiten-mit-ki/Prompt-Templates) als Startpunkt, wenn du nicht bei null anfangen möchtest. Wähle aus, welche Werkzeuge der Agent verwenden darf. Typische Tools sind: * **Daten (Hybrid Search)** — Der Agent durchsucht deine hochgeladenen Dokumente per Hybrid Search nach relevanten Inhalten – auch wenn du nicht die exakten Suchbegriffe kennst. * **Data Tables** — Ermöglicht dem Agenten, strukturierte Daten aus Tabellen im Space zu lesen und zu bearbeiten. * **Document Analysis** — Der Agent kann hochgeladene Dokumente Seite für Seite analysieren und Inhalte zusammenfassen. * **Image Generation** — Der Agent erzeugt Bilder aus Text-Prompts und bettet sie direkt in seine Antwort ein. * **Web Search** — Der Agent kann aktuelle Informationen aus dem Internet abrufen. Welche Tools zur Auswahl stehen, hängt davon ab, welche [Werkzeuge](/core-functions/Werkzeuge) im Space verfügbar sind. Aktiviert schrittweises Denken vor der Antwort. Nur für reasoning-fähige Modelle wirksam – bei Standardmodellen hat diese Option keinen Effekt. Mehr dazu unter [Reasoning und Thinking](/arbeiten-mit-ki/Reasoning-und-Thinking). Zeigt Quellenangaben an, wenn der Agent Informationen aus Dokumenten abruft. Besonders sinnvoll bei dokumentenbasierten Use Cases mit Hybrid Search. Legt fest, ob Nutzungsdaten dieses Agenten mit deinem Administrator geteilt werden – etwa zur Auswertung, wie intensiv der Agent genutzt wird. Klicke auf **Agent erstellen**, um den Agenten im Space anzulegen. Mit **Abbrechen** verwirfst du alle Eingaben. **Admin-Sicht:** Wie Agenten zentral in der Library angelegt, freigegeben und an mehrere Spaces verteilt werden, siehst du in [Administration → Agenten](/settings/organization/Agenten). # Confluence Integration einrichten Source: https://docs.localmind.ai/integrations/Confluence Confluence als integrierten Konnektor bereitstellen, damit Agenten Wiki-Seiten, Spaces und Kommentare durchsuchen, lesen und erstellen können. Die Confluence Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus Wiki-Seiten, Spaces und Kommentare durchsuchen, lesen und erstellen. Sie stellen die Integration einmalig auf Organisationsebene bereit; die Nutzer authentifizieren sich anschließend pro Person mit ihrem eigenen Confluence-Konto. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Zugang zur **Atlassian Developer Console** ([developer.atlassian.com](https://developer.atlassian.com)) mit Administratorrechten für die Confluence-Instanz. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. Wenn Sie Jira und Confluence aus derselben Atlassian-Cloud nutzen, legen Sie für jeden Konnektor eine **eigene** OAuth-App mit den jeweils passenden Scopes an. So bleiben die Berechtigungen sauber getrennt und nachvollziehbar. ## Schritt 1: OAuth-App in Atlassian anlegen Legen Sie zunächst eine OAuth 2.0 (3LO) Integration in der Atlassian Developer Console an. Daraus erhalten Sie die Client ID und das Client Secret, die Sie in Localmind hinterlegen. Melden Sie sich bei [developer.atlassian.com](https://developer.atlassian.com) an und öffnen Sie **My Apps**. Erstellen Sie eine neue **OAuth 2.0 (3LO)** Integration und vergeben Sie einen aussagekräftigen Namen, z.B. `Localmind Confluence Connector`. Fügen Sie unter **Permissions** die **Confluence API** hinzu und fordern Sie folgende Scopes an: * `read:confluence-content.all` * `read:confluence-space.summary` * `read:confluence-user` * `write:confluence-content` * `offline_access` `offline_access` ist erforderlich, damit Localmind die Sitzung über ein Refresh-Token erneuern kann, ohne dass sich Nutzer wiederholt anmelden müssen. Setzen Sie unter **Authorization** die Callback-URL auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/confluence/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Öffnen Sie die App-Einstellungen und kopieren Sie die **Client ID** und das **Client Secret**. Sie benötigen beide Werte im nächsten Schritt. ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Atlassian-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **Confluence**-Kachel. Tragen Sie die in Schritt 1 kopierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------------------------------- | | **Client ID** | OAuth Client ID aus der Atlassian Developer Console | | **Client Secret** | OAuth Client Secret aus der Atlassian Developer Console | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Callback-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URL ab. ## Schritt 3: Nutzer-Authentifizierung (Per-User OAuth) Confluence verwendet ausschließlich **Per-User OAuth** – jeder Nutzer verbindet sein eigenes Confluence-Konto. Der Datenzugriff entspricht damit exakt den individuellen Confluence-Berechtigungen jedes Nutzers. * Beim **ersten Aufruf des Confluence-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Es gibt keinen Service-Account-Modus: Aktionen werden immer im Namen des angemeldeten Nutzers ausgeführt. Aus Sicht der Endanwender ist dieser Schritt in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **Confluence**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das Confluence-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID und Secret zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # Integrationen verwenden Source: https://docs.localmind.ai/integrations/Integrationen-Nutzen Vorgebaute Konnektoren wie Jira, Confluence oder Outlook im Chat als Agent-Tools nutzen und mit deinem eigenen Konto verbinden. Integrationen sind vorgebaute Verbindungen zu externen Diensten, die dein Agent direkt im Chat als Tools nutzt. Statt selbst etwas zu konfigurieren, fragst du den Agent einfach in deinen eigenen Worten – er ruft die passende Integration auf und arbeitet mit den Daten aus dem verbundenen Dienst. Aktuell stehen diese Konnektoren zur Verfügung: Issues, Sprints und Backlogs durchsuchen, erstellen und verwalten. Wiki-Seiten und Spaces lesen, durchsuchen und zusammenfassen. Seiten und Datenbanken im Workspace lesen und erstellen. Auf Sites, Dokumentbibliotheken und OneDrive-Dateien zugreifen. E-Mails lesen und senden, Termine aus dem Kalender abrufen. Nachrichten in Kanälen und Chats lesen und senden, Termine aus dem Kalender abrufen. ## Voraussetzung: Integration muss freigegeben sein Integrationen erscheinen nicht automatisch in jedem Space. Bevor du sie nutzen kannst, müssen zwei Dinge passieren: 1. Ein **Administrator** richtet die Integration einmalig org-weit ein (OAuth-App und Zugangsdaten). 2. Die Integration wird aus der [Library](/library/overview) in deinen Space freigegeben. Erst danach steht das Tool deinen Agenten in diesem Space zur Verfügung. Integration nicht sichtbar? Bitte deinen Space- oder Org-Admin, sie in der [Library](/library/overview) für deinen Space freizugeben. Die Einrichtung auf Organisationsebene ist im Administration-Tab beschrieben (siehe die Karten am Ende dieser Seite). ## Erste Nutzung: dein Konto verbinden Beim **ersten Aufruf** eines Integrations-Tools im Chat verbindest du dein eigenes Konto. Du musst vorab nichts einrichten – der Ablauf startet automatisch: Stelle deinem Agent eine Frage oder Aufgabe, die die Integration betrifft – zum Beispiel „Zeige mir meine offenen Jira-Tickets". Der Agent erkennt, dass er die Integration braucht, und ruft das Tool auf. Es erscheint ein **Popup zur Anmeldung**. Melde dich dort mit deinem eigenen Konto des jeweiligen Dienstes an (zum Beispiel deinem Atlassian- oder Microsoft-Konto) und bestätige den Zugriff. Nach der Anmeldung führt der Agent die Aufgabe aus und antwortet im Chat mit dem Ergebnis. Weil du dich mit deinem **eigenen** Konto anmeldest, ist der Zugriff auf deine eigenen Daten beschränkt – der Agent sieht zum Beispiel nur die Jira-Tickets, die auch du sehen darfst. Die Anmeldung bleibt gespeichert; du musst dich beim nächsten Mal nicht erneut anmelden. ## Beispiel-Prompts Du steuerst Integrationen rein über deine Eingabe im Chat. Ein paar Beispiele, was du formulieren kannst: | Konnektor | Beispiel-Prompt | | --------------- | ---------------------------------------------------------------------- | | Jira | „Zeige mir meine offenen Jira-Tickets im Projekt LM." | | Confluence | „Fasse die Confluence-Seite ‚Onboarding-Leitfaden' für mich zusammen." | | Notion | „Suche in Notion nach unseren Meeting-Notizen von dieser Woche." | | SharePoint | „Finde das aktuelle Angebots-Dokument in unserer SharePoint-Site." | | Outlook | „Entwirf eine Outlook-Mail an das Projektteam mit dem Status-Update." | | Microsoft Teams | „Sende eine Teams-Nachricht an den Kanal ‚Vertrieb' mit dem Termin." | Formuliere konkret, welcher Dienst gemeint ist und was du erreichen willst. Je klarer die Aufgabe, desto zuverlässiger wählt der Agent die richtige Integration und die passende Aktion. ## Einrichtung (für Admins) Du bist Administrator und möchtest eine Integration org-weit bereitstellen? Die Einrichtung jedes Konnektors – OAuth-App anlegen, Zugangsdaten hinterlegen und für Spaces freigeben – ist auf den folgenden Setup-Seiten im Administration-Tab beschrieben: Einrichtung (für Admins) Einrichtung (für Admins) Einrichtung (für Admins) Einrichtung (für Admins) Einrichtung (für Admins) Einrichtung (für Admins) ## Verwandte Themen Wie Standard-Tools und integrierte Konnektoren in deinem Space zusammenspielen. Wie Ressourcen org-weit verfügbar gemacht und in Spaces freigegeben werden. # Jira Integration einrichten Source: https://docs.localmind.ai/integrations/Jira Jira als integrierten Konnektor bereitstellen, damit Agenten Issues, Sprints und Backlogs durchsuchen, erstellen und verwalten können. Die Jira Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus Issues, Sprints und Backlogs durchsuchen, erstellen und verwalten. Sie stellen die Integration einmalig auf Organisationsebene bereit; die Nutzer authentifizieren sich anschließend pro Person mit ihrem eigenen Jira-Konto. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Zugang zur **Atlassian Developer Console** ([developer.atlassian.com](https://developer.atlassian.com)) mit Administratorrechten für die Jira-Instanz. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. ## Schritt 1: OAuth-App in Atlassian anlegen Legen Sie zunächst eine OAuth 2.0 (3LO) Integration in der Atlassian Developer Console an. Daraus erhalten Sie die Client ID und das Client Secret, die Sie in Localmind hinterlegen. Melden Sie sich bei [developer.atlassian.com](https://developer.atlassian.com) an und öffnen Sie **My Apps**. Erstellen Sie eine neue **OAuth 2.0 (3LO)** Integration und vergeben Sie einen aussagekräftigen Namen, z.B. `Localmind Jira Connector`. Fügen Sie unter **Permissions** die **Jira API** hinzu und fordern Sie folgende Scopes an: * `read:jira-work` * `write:jira-work` * `read:jira-user` * `offline_access` `offline_access` ist erforderlich, damit Localmind die Sitzung über ein Refresh-Token erneuern kann, ohne dass sich Nutzer wiederholt anmelden müssen. Setzen Sie unter **Authorization** die Callback-URL auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/jira/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Öffnen Sie die App-Einstellungen und kopieren Sie die **Client ID** und das **Client Secret**. Sie benötigen beide Werte im nächsten Schritt. ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Atlassian-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **Jira**-Kachel. Tragen Sie die in Schritt 1 kopierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------------------------------- | | **Client ID** | OAuth Client ID aus der Atlassian Developer Console | | **Client Secret** | OAuth Client Secret aus der Atlassian Developer Console | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Callback-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URL ab. ## Schritt 3: Nutzer-Authentifizierung (Per-User OAuth) Jira verwendet ausschließlich **Per-User OAuth** – jeder Nutzer verbindet sein eigenes Jira-Konto. Der Datenzugriff entspricht damit exakt den individuellen Jira-Berechtigungen jedes Nutzers. * Beim **ersten Aufruf des Jira-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Es gibt keinen Service-Account-Modus: Aktionen werden immer im Namen des angemeldeten Nutzers ausgeführt. Aus Sicht der Endanwender ist dieser Schritt in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **Jira**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das Jira-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID und Secret zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # Microsoft 365 Integration Source: https://docs.localmind.ai/integrations/Microsoft-365-MCP Verbinden Sie Localmind mit Microsoft 365 um Mail-Entwürfe zu erstellen, Kalender abzurufen und SharePoint-Dateien im Chat zu nutzen. Mit der Microsoft 365 Integration können Sie direkt aus dem Agentic Chat heraus auf Ihr Microsoft-Ökosystem zugreifen. Der Agent kann Mail-Entwürfe in Outlook erstellen, Kalender-Einträge abrufen und SharePoint-Dateien durchsuchen und analysieren. Die Integration basiert auf dem Open-Source MCP Server [`@softeria/ms-365-mcp-server`](https://github.com/softeria/ms-365-mcp-server) (MIT-Lizenz) und nutzt die Microsoft Graph API. Sie verwendet ausschließlich **Delegated Permissions**: Jeder User authentifiziert sich selbst über den Device Code Flow und greift nur auf seine eigenen Daten zu. Der Zugriff ist auf die Berechtigungen des jeweils angemeldeten Users beschränkt – ein Zugriff auf Daten anderer User ist über diesen Weg nicht vorgesehen. Für die meisten Anwendungsfälle sind die nativen Konnektoren der empfohlene Standard-Weg: [SharePoint](/integrations/SharePoint), [Outlook](/integrations/Outlook) und [Microsoft Teams](/integrations/Microsoft-Teams) richten Sie geführt über **Org-Einstellungen → Sicherheit → Zugangsdaten** ein. Diese MCP-Server-Variante ist der fortgeschrittene Alternativweg über einen selbst konfigurierten Tool-Server. ## Voraussetzungen * Microsoft 365 Tenant mit Entra ID (Azure AD) * **Admin-Zugang zum Azure Portal** für die App Registration und Admin Consent * **Mindestens Space Administrator** für die Tool Server Konfiguration ## Azure Einrichtung Navigieren Sie in Entra ID zu **Gruppen → Neue Gruppe** und erstellen Sie eine Sicherheitsgruppe: | Feld | Wert | | ------------------- | --------------------------------------------------- | | Gruppentyp | Sicherheit | | Gruppenname | `Localmind M365 Users` | | Gruppenbeschreibung | User mit Zugriff auf die Localmind M365 Integration | Fügen Sie unter **Mitglieder** alle User hinzu, die die Integration nutzen sollen. Diese Gruppe steuert, wer die App nutzen darf: Nur Mitglieder können sich über den Device Code Flow authentifizieren, Nicht-Mitglieder erhalten beim Login eine Fehlermeldung. Navigieren Sie zu **Entra ID → App-Registrierungen → Neue Registrierung** und tragen Sie folgende Werte ein: | Feld | Wert | | ----------------------- | ----------------------------------------------------------------- | | Name | `Localmind M365 Connector` | | Unterstützte Kontotypen | Nur Konten in diesem Organisationsverzeichnis (Einzelner Mandant) | | Umleitungs-URI | Leer lassen | Klicken Sie auf **Registrieren** und notieren Sie sich anschließend die **Anwendungs-ID (Client-ID)** und die **Verzeichnis-ID (Mandanten-ID)** von der Übersichtsseite — Sie brauchen beide Werte für die Localmind Konfiguration. Navigieren Sie zu **API-Berechtigungen → Berechtigung hinzufügen → Microsoft Graph → Delegierte Berechtigungen** und fügen Sie folgende Berechtigungen hinzu: | Berechtigung | Zweck | | ---------------- | -------------------------------------- | | `User.Read` | Basis-Profil des angemeldeten Users | | `Calendars.Read` | Kalender-Einträge abrufen | | `Mail.ReadWrite` | Mail-Entwürfe erstellen und lesen | | `Files.Read.All` | OneDrive- und SharePoint-Dateien lesen | | `Sites.Read.All` | SharePoint Sites durchsuchen | Klicken Sie anschließend auf **Administratoreinwilligung erteilen für \[Ihr Tenant]** und bestätigen Sie. Verwenden Sie ausschließlich **Delegierte Berechtigungen** (Delegated Permissions), keine Anwendungsberechtigungen (Application Permissions). Delegierte Berechtigungen stellen sicher, dass jeder User nur auf seine eigenen Daten zugreift. Application Permissions würden der App eigenständigen Zugriff auf alle Mailboxen im Tenant geben. Navigieren Sie zu **Authentifizierung → Erweiterte Einstellungen**, setzen Sie **Öffentliche Clientflows zulassen** auf **Ja** und klicken Sie auf **Speichern**. Dies ermöglicht den **Device Code Flow**, über den sich User im Agentic Chat authentifizieren. Bei diesem Flow wird kein Client Secret benötigt. Die **App-Instanzeigenschaftssperre** kann auf den Standardeinstellungen belassen werden (alle Optionen angehakt). Wechseln Sie zu **Unternehmensanwendungen** (Enterprise Applications) – das ist ein separater Menüpunkt in Entra ID, nicht innerhalb der App-Registrierungen. Suchen Sie Ihre App (`Localmind M365 Connector`), setzen Sie unter **Eigenschaften** die Einstellung **Zuweisung erforderlich?** auf **Ja** und speichern Sie. Navigieren Sie dann zu **Benutzer und Gruppen → Benutzer/Gruppe hinzufügen** und weisen Sie die in Schritt 1 erstellte Sicherheitsgruppe (`Localmind M365 Users`) zu. Nur Mitglieder der zugewiesenen Gruppe können die Integration nutzen. Wenn ein User, der nicht in der Gruppe ist, versucht sich einzuloggen, erhält er die Fehlermeldung `AADSTS50105`. ## Localmind Konfiguration Navigieren Sie in Localmind zu **Einstellungen → Tool Server → Neuen Tool Server erstellen** und tragen Sie folgende Werte ein: | Feld | Wert | | -------------- | --------------------------------------------------------- | | Name | `Microsoft 365` | | Beschreibung | `Mail-Entwürfe, Kalender, SharePoint via Microsoft Graph` | | Verbindungstyp | NPX-Paket | | Paket | `@softeria/ms-365-mcp-server` | | Args | `--org-mode` | Fügen Sie unter **Konfiguration** folgende Schlüssel-Wert-Paare hinzu: | Schlüssel | Wert | Sicher | | --------------------- | ------------------------------------------------ | ------ | | `MS365_MCP_TENANT_ID` | Ihre Verzeichnis-ID (Mandanten-ID) aus Schritt 2 | Nein | | `MS365_MCP_CLIENT_ID` | Ihre Anwendungs-ID (Client-ID) aus Schritt 2 | Nein | | `ENABLED_TOOLS` | `mail\|calendar\|login\|verify\|sharepoint` | Nein | Der MCP Server stellt im Vollmodus über **100 Tools** bereit. Diese werden alle als Tool-Beschreibungen in den System-Prompt des Agenten injiziert und können das Token-Limit sprengen – der Agent antwortet dann gar nicht mehr, auch nicht auf einfache Nachrichten. Die Variable `ENABLED_TOOLS` ist daher **zwingend erforderlich**. `ENABLED_TOOLS` ist ein Regex-Pattern; mehrere Kategorien werden mit `|` (Pipe) getrennt. Die Tools `login` und `verify` sollten immer enthalten sein, da sie für die Authentifizierung benötigt werden. Beispiele: * `mail|calendar|login|verify` — nur Mail und Kalender * `mail|calendar|login|verify|sharepoint` — zusätzlich SharePoint * `mail|calendar|login|verify|drive|file|folder` — zusätzlich OneDrive * `mail|calendar|login|verify|excel` — zusätzlich Excel-Operationen Tenant ID und Client ID sind keine Geheimnisse – sie sind öffentliche Identifier. Ohne den Device Code Login eines berechtigten Users sind sie wertlos. Ein Client Secret wird bei diesem Flow nicht benötigt. Klicken Sie auf **Verbindung testen**, um zu prüfen, ob der MCP Server korrekt startet und die Tools geladen werden. Nach erfolgreichem Test klicken Sie auf **Speichern**. Microsoft 365 MCP Server Verbindungstest ## Erster Login & Nutzung Öffnen Sie einen Agentic Chat in Ihrem Privaten Space und schreiben Sie z.B.: > Zeig mir meine Kalender-Einträge für heute Der Agent erkennt, dass noch kein Token vorhanden ist und startet den Device Code Flow. Sie erhalten eine Nachricht mit einer URL und einem Code. Device Code Flow Login im Agentic Chat 1. Öffnen Sie [https://microsoft.com/devicelogin](https://microsoft.com/devicelogin) in einem Browser 2. Geben Sie den angezeigten Code ein 3. Loggen Sie sich mit Ihrem Microsoft 365 Account ein (muss Mitglied der Sicherheitsgruppe sein) 4. Bestätigen Sie die angeforderten Berechtigungen Nach erfolgreichem Login hat der Agent Zugriff auf Ihre Microsoft 365 Daten. Das Token wird gecacht – Sie müssen sich nicht bei jedem Chat neu einloggen. ## Use Cases **Mail-Entwurf erstellen** — „Erstelle einen Mail-Entwurf an [max@firma.de](mailto:max@firma.de) mit dem Betreff ‚Angebot Projektstart' und fasse unsere bisherige Diskussion als Inhalt zusammen." Der Entwurf erscheint in Outlook unter **Entwürfe**; Sie können ihn dort prüfen, bearbeiten und versenden. **Kalender abfragen** — „Was steht morgen in meinem Kalender? Bereite mir eine Zusammenfassung mit Notizen vor." Der Agent listet Ihre Termine auf und kann Kontext aus dem Chat hinzufügen – z.B. offene Punkte aus einem vorherigen Gespräch als Vorbereitung für ein Meeting. **SharePoint-Dateien im Chat nutzen** — „Suche in unserem SharePoint nach dem letzten Quartalsbericht und fasse die wichtigsten Kennzahlen zusammen." Der Agent findet die Datei über die SharePoint-Suche, liest den Inhalt und liefert eine strukturierte Zusammenfassung. ## Sicherheit & Datenschutz **Datenisolation:** Jeder User authentifiziert sich selbst über den Device Code Flow. Der API-Zugriff läuft über `/me/`-Endpunkte und ist auf die eigenen Daten beschränkt. Ein Zugriff auf Daten anderer User ist über diesen Weg nicht vorgesehen – der Zugriff richtet sich immer nach den delegierten Berechtigungen des angemeldeten Users. **Token-Speicherung:** Access Tokens werden lokal in der MCP Server Instanz gecacht und laufen automatisch ab. Refresh Tokens erneuern die Session ohne erneuten Login. **GDPR / Datenschutz:** Der Abruf der Microsoft-365-Daten läuft direkt zwischen der Localmind-Instanz und der Microsoft Graph API. Beachten Sie: Chat-Inhalte – einschließlich der Daten, die der Agent über die Integration abruft – werden zur Inferenz an die konfigurierten Modell-Provider übermittelt. Welche Provider das sind, sehen Sie unter [Unterauftragsverarbeiter](/compliance/Sub-Processors). # Microsoft Teams Integration einrichten Source: https://docs.localmind.ai/integrations/Microsoft-Teams Microsoft Teams als integrierten Konnektor bereitstellen, damit Agenten Nachrichten lesen und senden sowie auf den Kalender zugreifen können. Die Microsoft Teams Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus Nachrichten in Kanälen und Chats lesen und senden. Seit [v1.0.0](/changelog/v1.0.0) bietet die Integration zusätzlich Kalenderzugriff, etwa um Termine abzurufen. Sie stellen die Integration einmalig auf Organisationsebene bereit; die Nutzer authentifizieren sich anschließend pro Person mit ihrem eigenen Microsoft-Konto. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. Dieser native Konnektor ist der empfohlene Standard-Weg, um Microsoft Teams anzubinden. Für fortgeschrittene Szenarien gibt es einen alternativen Weg über einen eigenen MCP-Server: siehe [Microsoft 365 Integration](/integrations/Microsoft-365-MCP). ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Eine **Microsoft Entra (Azure AD) App-Registrierung** mit Administratorrechten im Azure-Tenant für die Vergabe der Berechtigungen. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. ## Schritt 1: OAuth-App in Microsoft Entra (Azure AD) anlegen Legen Sie zunächst eine App-Registrierung in Microsoft Entra an. Daraus erhalten Sie die Client ID, das Client Secret und die Tenant ID, die Sie in Localmind hinterlegen. Melden Sie sich im **Azure-Portal** an und öffnen Sie **App registrations**. Erstellen Sie eine neue App-Registrierung und vergeben Sie einen aussagekräftigen Namen, z.B. `Localmind Teams Connector`. Fügen Sie unter **Authentication** eine **Web**-Plattform hinzu und setzen Sie die Redirect-URI auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/microsoft_teams/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Fügen Sie unter **API permissions** folgende **delegierte** Microsoft-Graph-Berechtigungen hinzu: * `Team.ReadBasic.All` * `Channel.ReadBasic.All` * `ChannelMessage.Read.All` * `ChannelMessage.Send` * `User.Read` * `offline_access` Diese Microsoft-Graph-Berechtigungen erfordern **Admin-Zustimmung** im Azure-Tenant. Erteilen Sie die Admin-Zustimmung (**Grant admin consent**), bevor sich Nutzende anmelden können – andernfalls schlägt der OAuth-Flow fehl. `offline_access` ist erforderlich, damit Localmind die Sitzung über ein Refresh-Token erneuern kann, ohne dass sich Nutzer wiederholt anmelden müssen. Erstellen Sie unter **Certificates & secrets** ein neues Client Secret und kopieren Sie den angezeigten Wert sofort. Der Wert wird nur einmal vollständig angezeigt. Notieren Sie die folgenden drei Werte aus der Übersichtsseite Ihrer App-Registrierung. Sie benötigen sie im nächsten Schritt: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret** ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Entra-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **Microsoft Teams**-Kachel. Tragen Sie die in Schritt 1 notierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------------------------------ | | **Client ID** | Application (client) ID aus Azure | | **Client Secret** | Secret-Wert aus Azure (wird verschlüsselt gespeichert) | | **Tenant ID** | Directory (tenant) ID aus Azure | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Redirect-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URI ab. ## Schritt 3: Nutzer-Authentifizierung (Per-User OAuth) Microsoft Teams verwendet **Per-User OAuth** – jeder Nutzer verbindet sein eigenes Microsoft-Konto. Der Datenzugriff entspricht damit exakt den individuellen Teams-Berechtigungen jedes Nutzers. * Beim **ersten Aufruf des Teams-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Aktionen werden immer im Namen des angemeldeten Nutzers ausgeführt. Aus Sicht der Endanwender ist dieser Schritt in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **Microsoft Teams**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das Teams-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID, Client Secret und Tenant ID zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # Notion Integration einrichten Source: https://docs.localmind.ai/integrations/Notion Notion als integrierten Konnektor bereitstellen, damit Agenten Seiten und Datenbanken im Workspace durchsuchen, lesen und erstellen können. Die Notion Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus Seiten und Datenbanken im Notion-Workspace durchsuchen, lesen und erstellen. Sie stellen die Integration einmalig auf Organisationsebene bereit; die Nutzer authentifizieren sich anschließend pro Person mit ihrem eigenen Notion-Konto. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Zugang zu den **Notion-Integrationen** ([notion.so/my-integrations](https://www.notion.so/my-integrations)) mit Administratorrechten für den Workspace. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. ## Schritt 1: OAuth-Integration in Notion anlegen Legen Sie zunächst eine öffentliche Integration in Notion an. Daraus erhalten Sie die Client ID und das Client Secret, die Sie in Localmind hinterlegen. Melden Sie sich bei Notion an und öffnen Sie [notion.so/my-integrations](https://www.notion.so/my-integrations). Erstellen Sie eine neue **öffentliche Integration** und füllen Sie die erforderlichen Metadaten (Name, Logo, Beschreibung) aus. Verwenden Sie einen aussagekräftigen Namen, z.B. `Localmind Notion Connector`. Für den OAuth-Flow ist eine **öffentliche** Integration erforderlich. Eine interne Integration (Single-Workspace-Token) lässt sich nicht für die Per-User-Anmeldung verwenden. Aktivieren Sie unter **Capabilities** folgende Berechtigungen: * Read content * Update content * Insert content Setzen Sie unter **OAuth Domain & URIs** die Redirect-URI auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/notion/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Öffnen Sie die Integrations-Einstellungen und kopieren Sie die **OAuth Client ID** und das **OAuth Client Secret**. Sie benötigen beide Werte im nächsten Schritt. ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Notion-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **Notion**-Kachel. Tragen Sie die in Schritt 1 kopierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------ | | **Client ID** | OAuth Client ID aus Notion | | **Client Secret** | OAuth Client Secret aus Notion | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Redirect-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URI ab. ## Schritt 3: Nutzer-Authentifizierung (Per-User OAuth) Notion verwendet ausschließlich **Per-User OAuth** – jeder Nutzer verbindet sein eigenes Notion-Konto. Der Datenzugriff ist auf die Seiten und Datenbanken beschränkt, die der Nutzer während der OAuth-Anmeldung für die Integration freigibt. * Beim **ersten Aufruf des Notion-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Während der Anmeldung wählt der Nutzer aus, auf welche Seiten und Datenbanken die Integration zugreifen darf. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Es gibt keinen Service-Account-Modus: Aktionen werden immer im Namen des angemeldeten Nutzers ausgeführt. Aus Sicht der Endanwender ist dieser Schritt in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **Notion**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das Notion-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID und Secret zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # Outlook Integration einrichten Source: https://docs.localmind.ai/integrations/Outlook Outlook als integrierten Konnektor bereitstellen, damit Agenten E-Mails lesen, senden und verwalten sowie auf den Kalender zugreifen können. Die Outlook Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus E-Mails im Namen der Nutzenden lesen, senden und verwalten. Seit [v1.0.0](/changelog/v1.0.0) bietet die Integration zusätzlich Kalenderzugriff, etwa um Termine abzurufen. Sie stellen die Integration einmalig auf Organisationsebene bereit und wählen anschließend, ob sich Nutzer pro Person anmelden oder die Integration über einen Service-Account läuft. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. Dieser native Konnektor ist der empfohlene Standard-Weg, um Outlook anzubinden. Für fortgeschrittene Szenarien gibt es einen alternativen Weg über einen eigenen MCP-Server: siehe [Microsoft 365 Integration](/integrations/Microsoft-365-MCP). ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Eine **Microsoft Entra (Azure AD) App-Registrierung** mit Administratorrechten im Azure-Tenant für die Vergabe der Berechtigungen. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. ## Schritt 1: OAuth-App in Microsoft Entra (Azure AD) anlegen Legen Sie zunächst eine App-Registrierung in Microsoft Entra an. Daraus erhalten Sie die Client ID, das Client Secret und die Tenant ID, die Sie in Localmind hinterlegen. Melden Sie sich im **Azure-Portal** an und öffnen Sie **App registrations**. Erstellen Sie eine neue App-Registrierung und vergeben Sie einen aussagekräftigen Namen, z.B. `Localmind Outlook Connector`. Fügen Sie unter **Authentication** eine **Web**-Plattform hinzu und setzen Sie die Redirect-URI auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/microsoft_outlook/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Fügen Sie unter **API permissions** folgende **delegierte** Microsoft-Graph-Berechtigungen hinzu: * `Mail.Read` * `Mail.Send` * `User.Read` * `offline_access` Diese Microsoft-Graph-Berechtigungen erfordern **Admin-Zustimmung** im Azure-Tenant. Erteilen Sie die Admin-Zustimmung (**Grant admin consent**), bevor sich Nutzende anmelden können – andernfalls schlägt der OAuth-Flow fehl. `offline_access` ist erforderlich, damit Localmind die Sitzung über ein Refresh-Token erneuern kann, ohne dass sich Nutzer wiederholt anmelden müssen. Erstellen Sie unter **Certificates & secrets** ein neues Client Secret und kopieren Sie den angezeigten Wert sofort. Der Wert wird nur einmal vollständig angezeigt. Notieren Sie die folgenden drei Werte aus der Übersichtsseite Ihrer App-Registrierung. Sie benötigen sie im nächsten Schritt: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret** ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Entra-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **Outlook**-Kachel. Tragen Sie die in Schritt 1 notierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------------------------------------------------------------- | | **Client ID** | Application (client) ID aus Azure | | **Client Secret** | Secret-Wert aus Azure (wird verschlüsselt gespeichert; nur neu eingeben zum Ersetzen) | | **Tenant ID** | Directory (tenant) ID aus Azure | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Redirect-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URI ab. ## Schritt 3: Authentifizierungsmodus wählen Outlook bietet zwei Authentifizierungsmodi. Sie wählen den Modus auf der gleichen Seite direkt unter den Zugangsdaten. Welcher Modus passt, hängt davon ab, ob Aktionen mit dem individuellen Postfach jedes Nutzers oder mit einem zentralen Postfach ausgeführt werden sollen. Im Modus **Pro Nutzer (individuell)** verbindet jeder Nutzer sein eigenes Outlook-Konto über [Per-User OAuth](/integrations/Integrationen-Nutzen). Der Datenzugriff entspricht den individuellen Berechtigungen jedes Nutzers. Dies ist die **Standard-Auswahl**. * Beim **ersten Aufruf des Outlook-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Aktionen werden im Namen des jeweils angemeldeten Nutzers ausgeführt. Im Modus **Nur App (Service Account)** verwendet die Integration Anwendungsanmeldedaten ohne Nutzerkontext. Alle Aktionen werden als konfigurierter Service-Principal ausgeführt – unabhängig davon, welcher Nutzer das Tool im Chat aufruft. * Stellen Sie die Service-Account-Verbindung direkt über den **Outlook-Verbindung**-Button her. * Es erfolgt keine individuelle Nutzeranmeldung; der Zugriff richtet sich nach den Berechtigungen des Service-Accounts. Im Service-Account-Modus handeln alle Nutzer mit denselben Rechten. Beschränken Sie die Berechtigungen des Service-Accounts auf das tatsächlich benötigte Postfach und prüfen Sie den Zugriff regelmäßig. Aus Sicht der Endanwender ist die Per-User-Anmeldung in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **Outlook**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das Outlook-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID, Client Secret und Tenant ID zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # SharePoint Integration einrichten Source: https://docs.localmind.ai/integrations/SharePoint SharePoint als integrierten Konnektor bereitstellen, damit Agenten auf Sites, Dokumentbibliotheken und OneDrive-Dateien zugreifen können. Die SharePoint Integration ist ein integrierter Konnektor, mit dem Agenten direkt aus dem Chat heraus auf SharePoint-Sites, Dokumentbibliotheken und OneDrive-Dateien zugreifen. Sie stellen die Integration einmalig auf Organisationsebene bereit; die Nutzer authentifizieren sich anschließend pro Person mit ihrem eigenen Microsoft-Konto. Erfordert die Rolle **Org Admin**. Die Konfiguration erfolgt pro Organisation. Auch Instanz-Administratoren konfigurieren Integrationen nur innerhalb ihrer eigenen Organisation. Dieser native Konnektor ist der empfohlene Standard-Weg, um SharePoint anzubinden. Für fortgeschrittene Szenarien gibt es einen alternativen Weg über einen eigenen MCP-Server: siehe [Microsoft 365 Integration](/integrations/Microsoft-365-MCP). ## Voraussetzungen * Rolle **Org Admin** (oder Instanz-Administrator innerhalb der eigenen Organisation). * Eine **Microsoft Entra (Azure AD) App-Registrierung** mit Administratorrechten im Azure-Tenant für die Vergabe der Berechtigungen. * Die Integration muss zuerst org-weit bereitgestellt werden, bevor sie über die [Library](/library/overview) in einem Space genutzt werden kann. ## Schritt 1: OAuth-App in Microsoft Entra (Azure AD) anlegen Legen Sie zunächst eine App-Registrierung in Microsoft Entra an. Daraus erhalten Sie die Client ID, das Client Secret und die Tenant ID, die Sie in Localmind hinterlegen. Melden Sie sich im **Azure-Portal** an und öffnen Sie **App registrations**. Erstellen Sie eine neue App-Registrierung und vergeben Sie einen aussagekräftigen Namen, z.B. `Localmind SharePoint Connector`. Fügen Sie unter **Authentication** eine **Web**-Plattform hinzu und setzen Sie die Redirect-URI auf die OAuth-Redirect-URL Ihrer Instanz: ``` https://-api.localmind.ai/v1/oauth/microsoft/callback ``` Die exakte URL wird nach dem Speichern auf dem Konfigurationsbildschirm in Localmind angezeigt. Ersetzen Sie `` durch den Host Ihrer Localmind-Instanz und übernehmen Sie die dort angezeigte URL. Fügen Sie unter **API permissions** folgende **delegierte** Microsoft-Graph-Berechtigungen hinzu: * `Sites.Read.All` * `Files.Read.All` * `User.Read` * `offline_access` Diese Microsoft-Graph-Berechtigungen erfordern **Admin-Zustimmung** im Azure-Tenant. Erteilen Sie die Admin-Zustimmung (**Grant admin consent**), bevor sich Nutzende anmelden können – andernfalls schlägt der OAuth-Flow fehl. `offline_access` ist erforderlich, damit Localmind die Sitzung über ein Refresh-Token erneuern kann, ohne dass sich Nutzer wiederholt anmelden müssen. Erstellen Sie unter **Certificates & secrets** ein neues Client Secret und kopieren Sie den angezeigten Wert sofort. Der Wert wird nur einmal vollständig angezeigt. Notieren Sie die folgenden drei Werte aus der Übersichtsseite Ihrer App-Registrierung. Sie benötigen sie im nächsten Schritt: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret** ## Schritt 2: Konfiguration in Localmind hinterlegen Hinterlegen Sie die Entra-Zugangsdaten in den [Zugangsdaten](/settings/organization/Zugangsdaten) Ihrer Organisation. Navigieren Sie zu **Einstellungen (Zahnrad-Icon unten links) → Org-Einstellungen → Sicherheit → Zugangsdaten** und klicken Sie auf die **SharePoint**-Kachel. Tragen Sie die in Schritt 1 notierten Werte ein: | Feld | Beschreibung | | ----------------- | ------------------------------------------------------ | | **Client ID** | Application (client) ID aus Azure | | **Client Secret** | Secret-Wert aus Azure (wird verschlüsselt gespeichert) | | **Tenant ID** | Directory (tenant) ID aus Azure | Geben Sie das Client Secret niemals in Prompts, Variablen oder externen Notizen weiter. Localmind speichert das Secret verschlüsselt und zeigt es nach dem Speichern nicht erneut an. Klicken Sie auf **Konfiguration speichern**. Localmind zeigt anschließend die exakte Redirect-URL für Ihre Instanz an. Gleichen Sie diese mit der in Schritt 1 hinterlegten URI ab. ## Schritt 3: Nutzer-Authentifizierung (Per-User OAuth) SharePoint verwendet **Per-User OAuth** – jeder Nutzer verbindet sein eigenes Microsoft-Konto. Der Datenzugriff entspricht damit exakt den individuellen SharePoint-Berechtigungen jedes Nutzers. * Beim **ersten Aufruf des SharePoint-Tools** im Chat erscheint ein OAuth-Popup mit der Aufforderung zur Anmeldung. * Nach erfolgreicher Anmeldung wird das Token gecacht – ein erneutes Login ist nicht erforderlich. * Aktionen werden immer im Namen des angemeldeten Nutzers ausgeführt. Aus Sicht der Endanwender ist dieser Schritt in [Integrationen nutzen](/integrations/Integrationen-Nutzen) beschrieben. ## Verwendung in Spaces Nach dem org-weiten Bereitstellen ist die Integration noch nicht automatisch in jedem Space sichtbar. Ein Admin oder ein berechtigter Nutzer muss sie aus der [Library](/library/overview) in den jeweiligen Space freigeben. 1. Öffnen Sie die **Library** (Org-Navigation). 2. Wählen Sie die **SharePoint**-Integration und geben Sie sie für den gewünschten Space frei. 3. Danach steht das SharePoint-Tool den Agenten dieses Space zur Verfügung – siehe [Werkzeuge](/core-functions/Werkzeuge). ## Nächste Schritte So verbinden Endanwender ihr Konto und rufen die Integration im Chat auf. Client ID, Client Secret und Tenant ID zentral und verschlüsselt verwalten. Integrationen org-weit verfügbar machen und in Spaces freigeben. Wie Agenten Tools und Konnektoren im Chat einsetzen. # Library Source: https://docs.localmind.ai/library/overview Das Zuweisungs-Werkzeug deiner Organisation – Agenten, Werkzeuge und Basismodelle per Verknüpfung oder Kopie in Spaces bereitstellen. Die Library ist das **Zuweisungs-Werkzeug** deiner Organisation: Sie zeigt, welche **Agenten**, **Werkzeuge** und **Basismodelle** org-weit verfügbar sind, und bringt sie per **Verknüpfen** oder **Duplizieren** in deine [Spaces](/navigation/Spaces). Die Library ist **kein Speicher**: Jede Ressource lebt immer in einem konkreten Space. Über die Library wird sie anderen Spaces bereitgestellt – als **Verknüpfung** (schreibgeschützt, Änderungen am Original wirken automatisch) oder als **Duplikat** (eigenständige, frei bearbeitbare Kopie). Du erreichst die Library über den Sidebar-Punkt **„Bibliothek"**. ## Kategorien In der linken Spalte filterst du die Library nach Ressourcentyp: Gesamtübersicht aller org-weit verfügbaren Ressourcen. KI-Assistenten, die du in deine Spaces verknüpfst oder duplizierst. Tools und Integrationen, die Agenten als Fähigkeiten nutzen können. LLM-Modelle, die Spaces zugewiesen werden können. ## Suchen, Filtern und Sortieren In der oberen Leiste stehen dir folgende Funktionen zur Verfügung: * **Suchfeld** — „Bibliothekselemente suchen…" durchsucht Namen und Beschreibungen. * **Tags** — Filtere Ressourcen nach Tags, die von Library Managern vergeben wurden. * **Sortierung** — Wähle z.B. „Meist installiert", um die beliebtesten Ressourcen zuerst zu sehen. * **Ansicht** — Wechsle zwischen Grid- und Listenansicht. Library-Einträge sind standardmäßig **alphabetisch** sortiert. Nachdem du eine Ressource zu einem Space hinzugefügt hast, wird sie **nicht mehr umsortiert** — sie behält ihre Position, sodass die Liste stabil bleibt. Siehe [Changelog 1.0.0-beta.8](/changelog/v1.0.0-beta.8). ## Woher kommen die Ressourcen? Neue Ressourcen entstehen nicht in der Library, sondern immer in einem Space. Von dort werden sie org-weit bereitgestellt – entweder durch einen **Library Manager** oder über einen [Vorschlag aus deinem Space](#agent-zur-library-vorschlagen). Die Library vermittelt anschließend nur die Zuweisung in weitere Spaces. ## Sehen, wo eine Ressource verfügbar ist Bei jeder Library-Ressource siehst du, in welchen Spaces sie bereits verfügbar ist. So erkennst du schnell, ob ein Agent oder Werkzeug schon in deinen Spaces vorhanden ist, und fügst nichts doppelt hinzu. Neu seit v1.0.0-beta.5. Siehe [Changelog 1.0.0-beta.5](/changelog/v1.0.0-beta.5). ## Ressourcen durchsuchen Die Library zeigt Ressourcen als Karten an, gruppiert nach Kategorie. Jede Karte enthält den Ressourcennamen, den Typ und einen **Installieren**-Button, über den du die Ressource in einen Space bringst — je nach Freigabe als **Verknüpfung** oder als **Duplikat**. Library-Ansicht mit Kategorien links, Suchleiste oben und Ressourcen als Karten im Grid-Layout mit Installieren-Buttons Manche Werkzeuge können als **„Versteckt"** markiert sein. Diese sind in der Library vorhanden, werden aber in der Standardansicht nicht angezeigt. Die Sichtbarkeit wird von Library Managern gesteuert. Systemseitig bereitgestellte Werkzeuge kannst du nur **verknüpfen** — nicht duplizieren. Es entsteht also eine **Verknüpfung**, die Updates am Original automatisch übernimmt, statt einer eigenständigen Kopie. Siehe [Changelog 1.0.0-beta.8](/changelog/v1.0.0-beta.8). ## Basismodelle zu Spaces hinzufügen Modelle wählst du nicht pro Anfrage: Sie werden dem Space über die Library bereitgestellt — **Library → Basismodell → „Zu Spaces hinzufügen"** (als Verknüpfung oder Kopie). Erst danach ist das Modell im Modell-Dropdown deiner Agenten und Apps wählbar. Wie du das passende Modell auswählst, liest du unter [Modellauswahl](/arbeiten-mit-ki/modellauswahl). Wähle in der linken Spalte die Kategorie **Basismodelle**. Finde das gewünschte Modell im Katalog und klicke darauf. Klicke auf **Zu Spaces hinzufügen**. Wähle einen oder mehrere Spaces aus, denen das Modell zugewiesen werden soll. Spaces, die das ausgewählte Modell bereits haben, werden in der Auswahl automatisch ausgeblendet. Alternativ kann ein Basismodell org-weit über seine **Verteilungseinstellungen** bereitgestellt werden (durch einen Library Manager). Diese greifen jedoch nur für **neu erstellte** Spaces — bestehende Spaces erhalten das Modell nicht rückwirkend. Fehlt ein Modell in einem bestehenden Space, füge es wie oben beschrieben über **Zu Spaces hinzufügen** hinzu. ## Agent zur Library vorschlagen Du kannst Agenten aus deinem Space zur Library vorschlagen, damit sie auch anderen Mitgliedern deiner Organisation zur Verfügung stehen. Dein Vorschlag wird von einem Benutzer mit **Library-Manager-Rechten** geprüft und freigeschaltet. Details zum Freigabeprozess und zur Verwaltung der Library findest du im [Administration-Tab unter Library Management](/administration/Einstieg). # Chat History Source: https://docs.localmind.ai/navigation/Chat-History Vergangene Konversationen im aktuellen Space einsehen und fortsetzen. Die Chat History zeigt dir alle bisherigen Konversationen innerhalb des aktuellen [Space](/navigation/Spaces). Du findest sie in der linken Sidebar und kannst jederzeit zu einem früheren Chat zurückkehren, um ihn weiterzuführen. Die Chat History ist auf den aktuellen Space bezogen. Wenn du den Space wechselst, siehst du die Konversationen des jeweiligen Space. Die Chat History in deinem [Privaten Space](/navigation/Spaces) ist immer privat und für andere Mitglieder der Organisation nicht einsehbar. Auch sehr lange Konversationen kannst du nahtlos fortsetzen — Localmind [fasst ältere Nachrichten automatisch zusammen](/arbeiten-mit-ki/Context-Fenster#automatische-chat-zusammenfassung), wenn das Kontextlimit erreicht wird. ## Konversation teilen Du kannst eine Conversation per Link mit anderen Mitgliedern deines Space teilen. So können Kolleg:innen den Gesprächsverlauf einsehen, ohne dass du ihn kopieren musst. Beim Teilen kannst du optional ein **Ablaufdatum** setzen. Nach Ablauf des Datums ist der geteilte Link nicht mehr gültig und die Conversation wieder privat. Der geteilte Link funktioniert nur für Mitglieder desselben [Space](/navigation/Spaces). Personen außerhalb des Space erhalten keinen Zugriff. ## Ungelesen-Indikator Konversationen, die seit deinem letzten Besuch neue Nachrichten erhalten haben, markiert die Space-Seitenleiste mit einem **Ungelesen-Indikator**. So erkennst du auf einen Blick, wo es in einer geteilten Conversation etwas Neues gibt, und musst nicht jeden Chat einzeln durchsehen. Siehe auch [Changelog 1.0.0-beta.7](/changelog/v1.0.0-beta.7) für alle Neuerungen dieser Version. # Organisationen Source: https://docs.localmind.ai/navigation/Organisationen Die oberste Strukturebene in Localmind – hier werden Teams, Spaces und Mitglieder verwaltet. Eine Organisation ist die oberste Einheit in Localmind. Sie bildet dein Unternehmen oder deine Abteilung ab und bündelt alle Ressourcen, Personen und Spaces an einem Ort. ## Was gehört zu einer Organisation? Innerhalb einer Organisation werden drei zentrale Bereiche verwaltet: * **[Teams](/navigation/Teams)** — Gruppen von Benutzern, über die Zugriffsrechte auf Spaces gesteuert werden * **[Spaces](/navigation/Spaces)** — bündeln KI-Ressourcen wie Agenten, Daten, Apps und Tools * **Mitglieder** — Alle Personen, die Teil der Organisation sind ## Ein Benutzer, eine Organisation Jeder Benutzer kann mit derselben E-Mail-Adresse nur Teil **einer** Organisation sein. Das gilt auch für Instanz-Admins, die organisationsübergreifend administrieren können – auch sie sind immer Mitglied genau einer Organisation. ## Mitglieder einladen Neue Mitglieder fügst du über **Organisationseinstellungen → Mitglieder → Einladungen** hinzu. Du kannst einzelne E-Mail-Adressen eingeben oder mehrere Adressen kommagetrennt einfügen. Details zur Rollen- und Rechteverwaltung auf Organisationsebene findest du im Administration-Tab unter [Rollenvorlagen](/settings/instance/Role-Templates). Org-Profil, Mitglieder, Authentifizierung, Variablen, Speicher und mehr — die zentrale Admin-Sicht auf eine Organisation. Detaillierte Verwaltung von Mitgliedern, Einladungen und Rollen-Zuweisung. # Persönliche API-Schlüssel Source: https://docs.localmind.ai/navigation/Persönliche-API-Schlüssel Persönliche API-Schlüssel in den Benutzereinstellungen erstellen, Scope wählen, verwalten und widerrufen. Persönliche API-Schlüssel erlauben dir, dich gegenüber der Localmind-API mit deinem eigenen Account zu authentifizieren. Jeder Schlüssel gehört genau dir, ist an dein Konto und deine Heimat-Organisation gebunden — kein anderer Benutzer kann ihn verwenden. Es gibt in Localmind nur **einen** Typ von API-Schlüsseln: den persönlichen. Ein separates Space-API-Schlüssel-Menü existiert nicht — stattdessen legst du beim Erstellen den **Scope** fest: **alle Spaces** oder **ausgewählte Spaces**. Nicht verwechseln mit den [Org-Zugangsdaten](/settings/organization/Zugangsdaten) — dem zentralen Vault für **Drittsystem-Secrets** (z.B. DeepL-API-Key), die nicht für die Localmind-API gelten. Die Erstellung persönlicher API-Schlüssel ist standardmäßig für die Rolle **Org-Member** aktiviert (Berechtigungskategorie „Api Keys" → **Erstellen** — „Api Keys" ist das UI-Label der Berechtigungskategorie). Wenn du keine Schlüssel erstellen kannst, hat dein Org-Admin diese Berechtigung in deiner [Custom Org-Rolle](/settings/instance/Role-Templates#custom-org-rollen-erstellen) entfernt — wende dich an deinen Admin. ## Schlüssel finden Du erreichst die Übersicht deiner persönlichen API-Schlüssel über das **Benutzermenü** (unten in der Seitenleiste) → **Benutzereinstellungen** → **API-Schlüssel**. Dort siehst du eine Liste aller von dir angelegten Schlüssel mit Status, Erstellungsdatum und letzter Verwendung. Schlüssel anderer Benutzer tauchen hier nicht auf — die Ansicht ist strikt persönlich. Org-Admins können allerdings alle Schlüssel der Organisation einsehen (**Einstellungen → Sicherheit → API-Schlüssel**); den Klartext-Schlüssel sieht auch dort niemand nachträglich. ## Neuen Schlüssel erstellen Öffne das **Benutzermenü** unten in der Seitenleiste und wähle **Benutzereinstellungen**. Wechsle in der linken Navigation der Benutzereinstellungen zu **API-Schlüssel**. Klicke auf **Neuen Schlüssel erstellen**. Ein Dialog öffnet sich. Vergib einen aussagekräftigen Namen, der dir später bei der Zuordnung hilft — zum Beispiel „Mein Laptop", „CI-Pipeline staging" oder „Skript-Notebook". Ein guter Name beschreibt **wo** der Schlüssel verwendet wird, nicht **wer** ihn nutzt. So findest du beim Widerruf sofort den richtigen Eintrag. Lege fest, worauf der Schlüssel zugreifen darf: **alle Spaces** oder **ausgewählte Spaces**. Bei „ausgewählte Spaces" wählst du die gewünschten Spaces einzeln aus — Anfragen an andere Spaces schlagen dann fehl. Optional setzt du zusätzlich ein Ablaufdatum; standardmäßig läuft der Schlüssel nie ab. Nach dem Erstellen wird der Schlüssel **einmalig** im Klartext angezeigt. Kopiere ihn sofort. Sobald du den Dialog schließt, ist der Schlüssel **nicht mehr einsehbar**. Wenn du ihn verlierst, musst du ihn widerrufen und einen neuen erstellen. Lege den Schlüssel an einem sicheren Ort ab — Passwort-Manager, Umgebungsvariable (`LOCALMIND_API_KEY` in einer `.env`-Datei) oder verschlüsselter Vault deines CI-Systems. Niemals direkt in Quellcode oder Dokumente einbetten. ## Schlüssel widerrufen Widerrufe einen Schlüssel, sobald einer der folgenden Fälle eintritt: * Du hast den Schlüssel verloren oder bist dir unsicher, wo er gespeichert ist. * Du wechselst Geräte und der alte Schlüssel wird nicht mehr gebraucht. * Du hast den Verdacht, dass der Schlüssel kompromittiert wurde (Repo-Leak, geteiltes System, Phishing). * Du löst dein Konto auf oder verlässt die Organisation. In der Schlüssel-Liste klickst du beim entsprechenden Eintrag auf **Widerrufen** und bestätigst die Aktion. Der Widerruf ist **endgültig und sofort wirksam**. Drittsysteme, die diesen Schlüssel nutzen — Skripte, CI-Pipelines, eigene Tools — schlagen ab dem nächsten Aufruf mit `401 Unauthorized` fehl. Plane den Wechsel auf einen neuen Schlüssel vor dem Widerruf. ## Sicherheits-Hinweise API-Schlüssel haben in Git-Repositories nichts verloren. GitHub, GitLab und automatische Secret-Scanner indizieren öffentliche Repos in Sekunden — ein einmal geleakter Schlüssel ist faktisch verbrannt. Lade den Schlüssel zur Laufzeit aus einer Umgebungsvariable wie `LOCALMIND_API_KEY` oder einer `.env`-Datei (die über `.gitignore` ausgeschlossen ist). Tausche persönliche Schlüssel mindestens vierteljährlich aus, ebenso bei Personal-Wechseln oder nach Audit-Findings. Erstelle den neuen Schlüssel, migriere die Systeme, widerrufe dann den alten. Bei Verdacht auf Kompromittierung wartest du nicht auf den nächsten Audit-Termin — widerrufe sofort und erstelle einen neuen. Dauert keine Minute. ## Erste Anfrage Sobald du den Schlüssel hast, kannst du ihn als Bearer-Token im `Authorization`-Header mitsenden: ```bash cURL theme={null} curl https://-api.localmind.ai/v1/models \ -H "Authorization: Bearer sk-..." ``` Vollständige Endpoint-Referenz und Code-Beispiele findest du in der [API-Dokumentation](/api-reference/introduction) — Auth und Rollen-Scope deines Schlüssels erklärt [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen). ## Weiterführend Endpoint-Referenz, Auth und Code-Beispiele der Localmind v1-API. Wenn deine Anfragen 401, 403 oder stille 404 zurückgeben — typische Ursachen und Lösungen, inklusive Key-Scope. Drittsystem-Secrets im zentralen Org-Vault verwalten — getrennt von persönlichen Schlüsseln. # Space-Einstellungen Source: https://docs.localmind.ai/navigation/Space-Einstellungen Profil, Mitglieder, Standardwerte und Pins eines Space konfigurieren — inklusive Vererbung von der Organisation. In den Space-Einstellungen konfigurieren Space-Administratoren das Profil, die Mitglieder und die Standardwerte ihres Space. Die Einstellungen erreichst du über das Zahnrad-Icon im Space — sie öffnen sich als Modal mit den Bereichen **Space** (Profil), **Zugriff** (Mitglieder), **Standardwerte** (Speicher, Chat-Einstellungen, Parser, Variablen) und **Inhalt** (Pins). Der Zugriff auf Space-Einstellungen erfordert die Rolle **Space-Administrator**. Viewer können die Einstellungen nicht einsehen oder ändern. ## Vererbung von Organisationseinstellungen Space-Einstellungen operieren immer **innerhalb der Grenzen**, die auf [Organisationsebene](/navigation/Organisationen) festgelegt wurden. Viele Einstellungen erben den Standardwert der Organisation und können auf Space-Ebene überschrieben werden – jedoch nur innerhalb der von der Organisation erlaubten Limits. Wo ein Zurücksetzen-Icon neben einem Feld erscheint, kannst du den Wert auf den geerbten Organisationsstandard zurücksetzen. *** ## Profil Grundlegende Informationen und das Erscheinungsbild des Space. | Feld | Beschreibung | Hinweis | | ------------ | ------------------------------------------- | --------------------------------------------------- | | Profilbild | Quadratisches Bild als Avatar des Space | Format- und Größenvorgaben zeigt das Upload-Feld an | | Space-Farbe | Hex-Farbwert für die visuelle Kennzeichnung | Leer lassen für Standardfarbe | | Space-Name | Anzeigename des Space | Pflichtfeld | | Beschreibung | Kurzbeschreibung des Space-Zwecks | Optional | *** ## Mitglieder & Zugriff Verwalte, wer Zugriff auf den Space hat und mit welcher Rolle. **Aktionen:** * **Mitglied hinzufügen** — Fügt ein bestehendes Organisationsmitglied zum Space hinzu. * **Suche** — Filtere die Mitgliederliste nach Name oder E-Mail-Adresse. **Mitgliedertabelle:** | Spalte | Beschreibung | | --------- | ------------------------------------------------------------------------------------- | | Name | Name des Mitglieds | | Rolle | Zugewiesene Space-Rolle als Chip (z.B. „Space Admin", „Space Editor", „Space Viewer") | | Entfernen | Lösch-Icon zum Entfernen des Mitglieds aus dem Space | Mitglieder und Zugriff mit Namensliste, Rollen-Chips wie Space Admin und Space Viewer sowie Lösch-Icons Es können nur Personen hinzugefügt werden, die bereits Mitglied der [Organisation](/navigation/Organisationen) sind. Für die Zuweisung ganzer Gruppen nutze [Teams](/navigation/Teams) – dabei wird die Rolle automatisch über das Team gesteuert. *** ## API-Schlüssel Die Space-Einstellungen enthalten **kein eigenes API-Schlüssel-Menü**. Programmatischer Zugriff auf die Agenten eines Space läuft über deine **persönlichen API-Schlüssel**: Du erstellst sie über das **Benutzermenü** (unten in der Seitenleiste) → **Benutzereinstellungen** → **API-Schlüssel** und kannst sie dabei optional auf ausgewählte Spaces einschränken. * Schritt-für-Schritt-Anleitung: [Persönliche API-Schlüssel](/navigation/Persönliche-API-Schlüssel) * Wie Schlüssel-Scope und Rollen zusammenspielen: [Authentifizierung und Rollen](/api-reference/Authentifizierung-und-Rollen) *** ## Speicher Zeigt den aktuell belegten Speicher des Space mit einer prozentualen Auslastungsanzeige. Die geltenden Grenzwerte siehst du direkt in den jeweiligen Feldern. Diese Einstellungen erben den Standard aus [Org-Einstellungen → Speicher](/settings/organization/Speicher). Änderungen erstellen Space-spezifische Überschreibungen — immer innerhalb der Org-Limits. ### Speicherlimits | Feld | Beschreibung | | ------------------------ | ------------------------------------ | | Maximale Dateigröße | Größenlimit pro hochgeladener Datei | | Maximaler Gesamtspeicher | Gesamtes Speicherlimit für den Space | Neben jedem Feld befindet sich ein **Zurücksetzen-Icon**. Damit setzt du den Wert auf den geerbten Organisationsstandard zurück. *** ## Chat-Einstellungen In den Chat-Einstellungen legst du fest, welche Dateitypen im Chat hochgeladen werden dürfen und wie groß die jeweiligen Dateien maximal sein dürfen. Pro Dateityp kann ein eigenes **Größenlimit** definiert werden. So kannst du beispielsweise Bilder auf eine kleinere Dateigröße beschränken als PDFs. Die aktuell geltenden Werte siehst du direkt in den Feldern. Die Dateityp-Limits erben den Standard aus [Org-Einstellungen → Chats](/settings/organization/Chats) und lassen sich hier für den Space überschreiben — innerhalb der Org-Limits. *** ## Parser-Einstellungen Konfiguriere, welcher Parser für welchen Dateityp verwendet wird. Pro Dateityp wählst du aus einem Dropdown den gewünschten Parser. Der als **Standard** markierte Parser ist die empfohlene Wahl. Ist ein Parser als **Geerbt** gekennzeichnet, wird der Organisationsstandard verwendet. Diese Einstellungen erben den Standard aus [Org-Einstellungen → Parser](/settings/organization/Parser). Nimm Änderungen vor, um sie für diesen Space zu überschreiben. | Parser | Beschreibung | Geeignet für | | ------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------ | | `pdf_pymupdf` | Schnelle, regelbasierte Textextraktion. Liest Text direkt aus der PDF-Struktur. | Rein textbasierte PDFs ohne komplexes Layout | | `pdf_docling` | Strukturerhaltende Extraktion, die Überschriften, Tabellen und Listen erkennt. | PDFs mit Tabellen, Listen und mehrspaltigem Layout | | `mistral_ocr` | KI-gestützte Texterkennung (OCR). Erkennt Text in gescannten Dokumenten und Bildern. | Gescannte PDFs, fotografierte Dokumente **(Standard)** | | `ultraparse` | Universalparser mit breiter Formatunterstützung. | Gemischte PDF-Typen als Fallback | | Parser | Beschreibung | Geeignet für | | -------------- | --------------------------------------------------------------------------------------------- | ---------------------------------- | | `docx_docling` | Strukturerhaltende Extraktion für Word-Dateien. Erkennt Formatierungen, Tabellen und Absätze. | Alle Word-Dokumente **(Standard)** | | Parser | Beschreibung | Geeignet für | | ------------------ | ------------------------------------------------------------------------------ | -------------------------------------------------- | | `pptx_python_pptx` | Regelbasierte Extraktion von Folieninhalten und Notizen. | Textlastige Präsentationen | | `pptx_docling` | Strukturerhaltende Extraktion, die auch Layout und Tabellen in Folien erkennt. | Präsentationen mit komplexem Layout **(Standard)** | | Parser | Beschreibung | Geeignet für | | --------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------ | | `xlsx_openpyxl` | Regelbasierte Tabellenextraktion. Liest Zellen, Blätter und Formeln. | Standardmäßige Tabellen und Berichte | | `xlsx_docling` | Strukturerhaltende Extraktion mit besserer Erkennung von Tabellenlayouts. | Komplexe Arbeitsmappen mit verschachtelten Tabellen **(Standard)** | | Parser | Beschreibung | Geeignet für | | ---------------- | -------------------------------------------------------------------- | ---------------------------------------------------------- | | `mistral_ocr` | KI-gestützte Texterkennung. Extrahiert sichtbaren Text aus Bildern. | Bilder mit Text, Screenshots, Scans | | `mistral_vision` | KI-Bildanalyse, die Inhalte, Objekte und Kontext im Bild beschreibt. | Fotos, Diagramme, Grafiken ohne reinen Text **(Standard)** | | Parser | Beschreibung | Geeignet für | | ---------- | ----------------------------------------------------------- | ------------------------------------ | | `markdown` | Native Markdown-Verarbeitung mit Beibehaltung der Struktur. | Alle Markdown-Dateien **(Standard)** | | Parser | Beschreibung | Geeignet für | | ------ | ----------------------------------------- | -------------------------------- | | `text` | Direkte Textübernahme ohne Konvertierung. | Reine Textdateien **(Standard)** | | Parser | Beschreibung | Geeignet für | | ------ | -------------------------------------------------------------------------- | ------------------------------- | | `csv` | Tabellarische Verarbeitung von CSV-Daten mit Spalten- und Zeilenerkennung. | Alle CSV-Dateien **(Standard)** | **Aktion:** **Zurücksetzen** – setzt alle Parser-Einstellungen auf die Organisationsstandards zurück. Wenn du unsicher bist, welcher Parser am besten passt, bleib beim mit **Standard** markierten Parser. Für gescannte Dokumente oder Bilder mit Text empfiehlt sich `mistral_ocr`, für strukturierte Dokumente mit Tabellen und Listen die `docling`-Varianten. Die vollständige Parser-Referenz mit Admin-Detailtiefe findest du unter [Org-Einstellungen → Parser](/settings/organization/Parser). *** ## Variablen Variablen sind wiederverwendbare Platzhalter, die in System-Prompts von [Agenten](/core-functions/agents) eingefügt werden können. Space-Variablen überschreiben gleichnamige Organisationsstandards aus [Org-Einstellungen → Variablen](/settings/organization/Variablen). **Aktion:** **Variable hinzufügen** ### Vorhandene Variablen | Schlüssel | Beschreibung | Geltungsbereich | | --------------- | ---------------------------- | --------------- | | `{{DATE}}` | Aktuelles Datum | Space | | `{{DATETIME}}` | Aktuelles Datum und Uhrzeit | Space | | `{{TIME}}` | Aktuelle Uhrzeit | Space | | `{{USER_NAME}}` | Name des aktuellen Benutzers | Space | | `{{WEEKDAY}}` | Aktueller Wochentag | Space | Pro Zeile stehen die Aktionen **Bearbeiten** (Stift-Icon) und **Löschen** (Papierkorb-Icon) zur Verfügung. ### Verwendung in System-Prompts Variablen werden mit doppelten geschweiften Klammern referenziert: ``` Mein Firmenname ist {{Company Name}} ``` Du kannst eigene Variablen erstellen (z.B. `{{Company Name}}`, `{{Support Email}}`) und diese in den System-Prompts deiner Agenten verwenden. *** ## Pins Hefte häufig benötigte Elemente an den Space an, um schnellen Zugriff zu ermöglichen. *** ## Grenzen durch Organisationsrichtlinien Alle Space-Einstellungen sind an die Limits gebunden, die auf [Organisationsebene](/navigation/Organisationen) definiert wurden. Wenn ein Organisationsadministrator ein Limit herabsetzt, können bestehende Space-Überschreibungen, die über dem neuen Limit liegen, davon betroffen sein. Details zur Konfiguration der organisationsweiten Limits findest du in den [Org-Einstellungen](/settings/organization/Einstieg). Informationen zum Berechtigungsmodell findest du unter [Rollenvorlagen](/settings/instance/Role-Templates). # Spaces Source: https://docs.localmind.ai/navigation/Spaces Spaces bündeln alle KI-Ressourcen für deine Projekte – Agenten, Daten, Apps und Werkzeuge an einem Ort. Spaces sind der zentrale Ort für deine Arbeit in Localmind. Hier befinden sich alle KI-Ressourcen, die du für deine Projekte brauchst: **Agenten, Daten, Apps, Werkzeuge (Tools) und Automatisierungen**. Spaces bilden Projekte und kollaboratives Arbeiten ab. Space-Übersicht mit linker Sidebar für Agenten, Daten, Apps und Werkzeuge sowie dem zentralen Content-Bereich ## Zugehörigkeit * Du kannst Teil von **mehreren Spaces** gleichzeitig sein. * Spaces können sowohl [Teams](/navigation/Teams) als auch einzelne Benutzer als Mitglieder haben. * Über welche Spaces du verfügst, hängt davon ab, welchen Spaces du direkt oder über dein Team zugeordnet bist. ## Privater Space Jeder Benutzer hat einen eigenen **Privaten Space**. Dieser ist privat und kann nur von dir selbst eingesehen werden. Dein Privater Space gehört nur dir – niemand sonst hat Zugriff darauf. In geteilten Spaces arbeitest du mit deinem Team zusammen. ## Berechtigungen im Space Auf Space-Ebene gibt es drei Systemrollen: Hat **Lesezugriff** auf alle KI-Ressourcen im Space und kann **Agenten ausführen** – Inhalte verändern kann er nicht. Kann zusätzlich **Inhalte erstellen und bearbeiten** – z.B. Agenten, Daten und Apps. Space-Einstellungen und Mitgliederverwaltung bleiben Administratoren vorbehalten. Hat **Vollzugriff**: verwaltet **Mitglieder** (nur Personen, die bereits Teil der Organisation sind) und konfiguriert **Space-Einstellungen** – z.B. Parser, Prompt-Variablen oder maximale Dateigrößen pro Dateityp. Deine Berechtigung in einem Space kann auf zwei Wegen entstehen: durch **direkte Zuweisung** oder über ein **[Team](/navigation/Teams), dem eine Rolle mitgegeben wird**. Verschiedene Teams können im selben Space unterschiedliche Rollen haben – so lässt sich z.B. steuern, dass ein Team Datentabellen nur lesen, ein anderes sie aber auch bearbeiten darf. Zusätzlich zu den drei Systemrollen sind [Custom-Rollen](/settings/organization/Space-Rollen) möglich – damit lassen sich Berechtigungen noch feiner steuern als mit Viewer, Editor und Administrator. Ein konkretes Beispiel, wie verschiedene Teams im selben Space mit unterschiedlichen Rollen arbeiten, findest du unter [Teams → Praxisbeispiel](/navigation/Teams#praxisbeispiel). Space-Einstellungen wie maximale Dateigrößen können nur innerhalb der Limits konfiguriert werden, die auf [Organisationsebene](/navigation/Organisationen) festgelegt wurden. Details zur Konfiguration findest du im [Administration-Tab](/administration/settings). **Admin-Sicht:** Welche Space-Rollen es gibt, wie Custom Roles Org-weit angelegt und vererbt werden, siehst du in [Administration → Space-Rollen](/settings/organization/Space-Rollen). # Teams Source: https://docs.localmind.ai/navigation/Teams Wie Teams den Zugriff auf Spaces organisieren und was das für dich als Benutzer bedeutet. Teams sind Gruppen innerhalb deiner [Organisation](/navigation/Organisationen), mit denen sich der Zugriff auf verschiedene [Spaces](/navigation/Spaces) zentral steuern lässt. Statt jeden Benutzer einzeln einem Space zuzuweisen, wird das Team als Ganzes zugeordnet. ## So funktionieren Teams * Du kannst Mitglied in **mehreren Teams** gleichzeitig sein. * Ein Team kann **mehreren Spaces** zugewiesen werden. * Über Teams erhältst du automatisch Zugriff auf alle Spaces, denen dein Team zugeordnet ist. Teams sind damit das zentrale Werkzeug, um Zugriffsrechte effizient über mehrere Spaces hinweg zu verwalten – ohne jeden Nutzer einzeln zuweisen zu müssen. Wenn du plötzlich in einem neuen Space auftauchst, liegt das vermutlich daran, dass dein Team diesem Space zugewiesen wurde. ## Rollen über Teams steuern Wenn ein Team einem Space zugewiesen wird, wird gleichzeitig eine **Space-Rolle** festgelegt. Alle Mitglieder des Teams erhalten diese Rolle automatisch im jeweiligen Space. Das funktioniert mit den Standard-Rollen (Viewer, Editor, Administrator) und mit [Custom Space-Rollen](/settings/organization/Space-Rollen#custom-space-rollen-erstellen), die noch feiner steuern, was erlaubt ist. So lassen sich mehrere Teams mit **unterschiedlichen Berechtigungen** demselben Space zuordnen – ohne einzelne Benutzer verwalten zu müssen. ## Praxisbeispiel Stell dir einen Space **"Produktlaunch 2026"** vor, der Agenten für Marktanalyse, Datentabellen mit Wettbewerbsdaten und Automatisierungen enthält. Drei Teams arbeiten im selben Space – jedes mit einer anderen Rolle: Die Projektleitung kann Agenten erstellen und bearbeiten, Datentabellen verwalten, Space-Einstellungen anpassen und neue Mitglieder hinzufügen. Das Marketing-Team kann Agenten befragen, Daten einsehen und Apps nutzen – aber nichts verändern oder konfigurieren. Externe Berater können ausschließlich Agenten befragen. Datentabellen, Einstellungen und andere Ressourcen im Space bleiben für sie unsichtbar. Das Ergebnis: Ein Space, drei Teams, drei verschiedene Zugriffsebenen – komplett über die Team-Zuweisung gesteuert. Team-Space-Zuordnung mit verschiedenen Rollen wie Administrator, Viewer und Custom Role im selben Space Die Erstellung von Teams, die Zuweisung von Rollen und die Konfiguration von Custom Roles liegt bei Organisationsadministratoren. Details dazu findest du im Administration-Tab unter [Rollenvorlagen](/settings/instance/Role-Templates) und [Space-Rollen](/settings/organization/Space-Rollen). **Admin-Sicht:** Wie Teams Org-weit angelegt, mit Mitgliedern befüllt und Spaces zugeordnet werden, siehst du in [Administration → Teams](/settings/organization/Teams). # Hosting Options Source: https://docs.localmind.ai/pricing/Hosting-Options Hosting-Optionen für Localmind Diese Seite wird derzeit erarbeitet. Für aktuelle Informationen zu diesem Thema wenden Sie sich an den [Localmind Support](mailto:support@localmind.ai). # Pricing Tiers Source: https://docs.localmind.ai/pricing/Pricing-Tiers Preispläne und Tarife Diese Seite wird derzeit erarbeitet. Für aktuelle Informationen zu diesem Thema wenden Sie sich an den [Localmind Support](mailto:support@localmind.ai). # Dein erster Agent Source: https://docs.localmind.ai/quickstart/Dein-erster-Agent In wenigen Minuten zum ersten eigenen KI-Agenten — interaktive Demo plus Schritt-für-Schritt-Anleitung zum Nachlesen. Folge der interaktiven Demo, um deinen ersten KI-Agenten einzurichten – Schritt für Schritt direkt in der Oberfläche. Unter der Demo findest du dieselben Schritte zum Nachlesen.