Einstellungen und Anpassung

In CLYE AI kannst du Assistenten und Gruppen an ihren Einsatzzweck anpassen. Dafür musst du keine technischen Details kennen. Wichtig ist nur zu wissen, welche Arten von Einstellungen es gibt und wann sie sinnvoll sind.

Wichtig ist dabei: Du siehst nicht automatisch alle Einstellungsbereiche. Welche Punkte verfügbar sind, hängt vom Bereich und von deiner Rolle ab.

Wann Einstellungen wichtig werden

Einstellungen sind relevant, wenn:

• ein Assistent anders reagieren oder arbeiten soll
• Zugriffe angepasst werden müssen
• Wissen, Quellen oder Werkzeuge ergänzt werden
• Zusammenarbeit für ein Team sauber eingerichtet werden soll

Typische Einstellungsbereiche

Je nach Bereich können unter anderem diese Themen wichtig sein:

• Allgemeine Angaben wie Name, Beschreibung oder Zweck
• Persönlich für deinen eigenen Bereich, dein Profil oder individuelle Präferenzen
• Hinweise für Einführungen und Onboarding in einem Bereich
• Berechtigungen für Zugriff und Zusammenarbeit
• Datenbanken für angebundene strukturierte Daten, Tabellen und Auswertungen im jeweiligen Bereich
• Agent Plugins oder Werkzeuge für zusätzliche Fähigkeiten eines Assistenten
• Externe Quellen oder RAG für den nutzbaren Wissenskontext
• Datenbanken oder Tabellenansichten für strukturierte Datenarbeit im passenden Bereich
• Automationen für wiederkehrende Abläufe
• Feedback oder Dashboard, wenn ein Assistent bereits produktiv genutzt wird
• Q&A oder ähnliche Bereiche für offene Rückfragen und kuratierte Antworten
• Einbettung oder Freigabeoptionen für die Nutzung außerhalb des direkten Arbeitsbereichs
• Änderungen oder Änderungshistorie für nachvollziehbare Anpassungen

Nicht jeder dieser Punkte ist in jedem Bereich sichtbar. Die genaue Auswahl ist meist ein Hinweis darauf, wofür dieser Bereich gedacht ist.

In der Oberfläche heißen diese Punkte oft genau so. Häufig begegnen dir also direkt Labels wie Allgemein, Persönlich, Hinweise, Berechtigungen, Datenbanken, Agent Plugins, RAG, Externe Quellen, Automationen, Feedback, Dashboard, Einbetten oder Änderungen. Viele Einstellungsseiten nutzen dabei denselben Aufbau: Überschrift und Einordnung stehen oben, Aktionen oder Tabs sitzen rechts daneben und rutschen erst auf schmaleren Breiten unter die Beschreibung.

Wenn ihr mit feingranularen Regeln arbeiten wollt (z. B. „public" oder „nur bestimmte Kunden/Projekte"), siehe Zugriffsfilter (Permission Filter).

Wenn in eurem Setup eingebaute Assistenten-Fähigkeiten verwaltet werden, findest du dort oft auch einen Bereich für Agent Plugins oder Werkzeuge. Wie du typische eingebaute Plugins nutzt, steht in Integrierte MCP-Server.

Wenn du einen extern gehosteten MCP-Server anbinden willst, ist derselbe Bereich ebenfalls relevant. Für Smithery-gehostete Server ist der übliche Weg: Agent Plugins öffnen, Plugin hinzufügen wählen, dort die eigene Konfiguration öffnen, Streaming HTTP auswählen und die Verbindungs-URL des Dienstes eintragen. Eine ausführliche Schritt-für-Schritt-Erklärung findest du unter Externe MCP-Server.

Bei der modernen Einstellungsoberfläche ist der Einstieg bewusst einfacher: Für viele externe MCP-Server reichen im ersten Schritt wenige Pflichtfelder. Zusätzliche technische Optionen liegen gesammelt unter Erweiterte Einstellungen, damit Standard-Setups schneller angelegt werden können.

Beim persönlichen Assistenten erreichst du diese Einstellungen je nach Oberfläche an zwei Stellen: Entweder über das Drei-Punkte-Menü direkt am Sidebar-Eintrag oder – in der älteren Oberfläche – über das Drei-Punkte-Menü oben rechts in der App-Leiste des geöffneten Assistenten. In dieser älteren Variante liegen deine persönlichen Account-Einstellungen stattdessen wieder im User-Menü.

In der modernen Einstellungsoberfläche sind viele Integrationen außerdem direkt in die Space-Einstellungen verschoben worden. Dazu gehören unter anderem API-Schlüssel, GitHub Integration, Clockify Integration, Clockify Mapping, Kalender Integration, Aufgaben MCP und Space MCP Hub. Du findest sie in der Sidebar des Space unter Integrationen.

Wichtig: Die technische Zuständigkeit ändert sich dadurch nicht automatisch. Einige Seiten verwalten weiterhin persönliche Verbindungen wie GitHub, Clockify oder Kalender, liegen aber aus Gründen der besseren Auffindbarkeit im Space unter Integrationen. Andere Bereiche wie API-Schlüssel, Aufgaben MCP oder Space MCP Hub bleiben echte Space-Einstellungen.

Je nach freigeschaltetem Funktionsumfang kannst du unter Agent Plugins jetzt auch lokale Ordner direkt im Browser verbinden. Dafür wählst du den Ordner über den Browser-Dateidialog aus und erlaubst den Zugriff. Eine ausführlichere Einordnung steht unter Externe MCP-Server; der CLI-Weg bleibt unter Share-Folder dokumentiert.

Für DocuWare gibt es einen von CLYE gehosteten, OAuth-geschützten MCP-Server. Die Einrichtung in DocuWare und die Anbindung im CLYE AI sind unter DocuWare MCP-Server beschrieben.

Für Shopware-Instanzen ab Version 6.7.11.0 verbindet der Shopware-Connector den CLYE AI direkt mit dem nativen MCP-Server der Shop-Installation.

Einstellungen für Assistenten

Bei Assistenten geht es meist darum, wie sie arbeiten sollen und mit welchem Wissen sie arbeiten können.

Sinnvolle Fragen sind:

• Wofür ist dieser Assistent gedacht?
• Welches Wissen soll er kennen?
• Welche Werkzeuge oder Quellen braucht er wirklich?
• Welche Arbeitsweise soll über Skills oder andere Vorgaben standardisiert werden?

Oft findest du dort zusätzlich Bereiche für:

• Quellen und hochgeladene Dateien
• Werkzeuge oder Integrationen
• Dashboard, Feedback oder Änderungen bei aktiv genutzten Assistenten
• Feedback, Fragen oder Änderungen
• Einbettung und Freigaben

Gerade in Bereichen wie Prompt, RAG, Versionen, Webhooks, API-Keys oder Q&A ist die Oberfläche jetzt konsistenter aufgebaut. Titel, Beschreibung, Tabs und Aktionsflächen bleiben besser ausgerichtet, auch wenn rechts zusätzliche Schalter oder Buttons eingeblendet werden.

In den Allgemeinen Einstellungen eines Assistenten stehen Name und Beschreibung und das Profilbild jetzt untereinander. Dadurch bleibt der Bereich „Mit KI generieren“ auch dann vollständig sichtbar, wenn daneben ein Demo-Chat geöffnet ist.

Der Bereich Support-Kontakt gehört jetzt ebenfalls fest zu den Allgemeinen Einstellungen eines Spaces oder Assistenten. Du musst also nicht erst auf eine zusätzliche Freischaltung warten, um diese Kontaktmöglichkeit dort zu sehen.

Wenn ein Assistent auch außerhalb des normalen Arbeitsbereichs erreichbar sein soll, lohnt sich ein Blick auf Einbetten oder ähnliche Freigabeoptionen. Für einen gezielten, kontrollierten Einstieg ist dabei oft ein Assistant Access Link der richtige Weg.

Wenn ein Assistent bereits von mehreren Personen genutzt wird, lohnt sich meist zuerst ein Blick auf Zweck, Wissen und Berechtigungen, bevor weitere Optionen angepasst werden.

Feature-Flags und Rollout-Stufen

Wenn in eurem Setup Feature-Flags in der Oberfläche verwaltet werden, zeigt die Übersicht pro Flag die gesetzte Rollout-Stufe und zusätzlich die Zielgruppe an. Die bisherige Eigenschaft Freigabe ist in /admin/testing nicht mehr Teil der Oberfläche. Sichtbarkeit und Rollout werden jetzt nur noch über Zielgruppe und Rollout-Stufe abgebildet.

Die optionale Zielgruppe schränkt zusätzlich ein, für wen ein Flag überhaupt sichtbar sein darf. In /admin/testing erscheint dafür die Spalte Zielgruppe mit deutschen Labels. Möglich sind derzeit Admin, Tester, Entwickler und Support. Ist keine Zielgruppe gesetzt, gilt das Flag aus Nutzersicht als für alle Endnutzer offen, sofern auch die übrigen Freigaben passen.

Wichtig dabei: Ein Flag wird nur sichtbar, wenn beide Prüfungen erfolgreich sind:

1. die gewählte Zielgruppe passt zum aktuellen Nutzer
2. die gesetzte Rollout-Stufe erlaubt das Flag ebenfalls

Wenn ihr auf /admin/testing mit Tabellenfiltern arbeitet, stehen dafür weiterhin Filter wie Rollout, Zielgruppe oder Review offen bereit. Einen separaten Filter Freigabe gibt es dort nicht mehr.

Über Verlauf anzeigen seht ihr pro Flag jetzt außerdem klarer, wer eine Änderung ausgelöst hat. Bei Freigaben, Änderungen der Rollout-Stufe und eingehendem Feedback zeigt der Verlauf den Namen oder ersatzweise die E-Mail des Akteurs an. Fehlen diese Angaben, erscheint weiterhin System.

Dieselbe Akteursangabe wird auch im Release-Kalender verwendet. Wenn ein Flag zum Beispiel auf Released gesetzt oder über einen Release-Sync übernommen wurde, ist dort derselbe Name beziehungsweise dieselbe E-Mail sichtbar wie im Detailverlauf des Flags.

Diese Freigabelogik gilt nicht nur für sichtbare Oberflächen, sondern auch für Funktionen mit Server- oder API-Zugriff über Feature-Flags. Wenn ein Feature für bestimmte Nutzergruppen oder Rollout-Stufen freigeschaltet ist, soll dieselbe Prüfung auch an den zugehörigen Endpunkten greifen.

Das betrifft jetzt auch den Space-MCP-Hub, wenn ihr ihn mit einem Space-Admin-API-Key ansprecht. Für solche API-Keys werden dabei die Test-Overrides des Key-Erstellers mit ausgewertet. Ein in /admin/testing aktiviertes Feature gilt damit auch für MCP-Hub-Aufrufe über diesen Key, statt am Endpoint fälschlich mit 403 zu scheitern.

Wichtig für Versionen eines Flags: Eine bereits gesetzte Rollout-Stufe bleibt auch dann wirksam, wenn die interne Feature-Version erhöht wird. Ein Versionssprung setzt Released also nicht automatisch zurück. Die bisherige Stufe bleibt als Ausgangsbasis aktiv, bis für die neue Version ausdrücklich eine andere Stufe gesetzt wird.

Wenn du ein bereits auf Released gesetztes Flag wieder auf Tester oder Dev zurückstufen willst, verlangt die Oberfläche eine ausdrückliche Bestätigung. Das soll verhindern, dass ein Feature versehentlich wieder für Endnutzer verschwindet.

Zusätzlich wertet die Oberfläche Feature-Flags bei laufender Anmeldung stabiler aus: Solange eine vorhandene Sitzung im Hintergrund noch nachgeladen oder aktualisiert wird, bleibt die bisherige Benutzerzuordnung für die Flag-Auswertung erhalten. Für eingeloggte Nutzer mit einer Rollout-Gruppe wie Alpha oder Beta bleibt damit auch diese Gruppenzuordnung beim Neuladen oder bei einem Session-Refetch erhalten, solange der Server weiterhin dieselbe Freigabe liefert. Dadurch kippen freigeschaltete Funktionen nicht kurz auf Released zurück.

Praktisch bedeutet das:

1. Version erhöht: Die bisherige Rollout-Stufe bleibt zunächst erhalten.
2. Neue Stufe bewusst setzen: Erst dann ändert sich die Freigabe für die neue Version.
3. Zielgruppe prüfen: Zusätzlich muss die gesetzte Zielgruppe zum aktuellen Nutzer passen.
4. Downgrade von Released: Dafür ist eine zusätzliche Bestätigung nötig.
5. Session wird aktualisiert: Bereits sichtbare Flag-abhängige Bereiche bleiben währenddessen stabil und flackern nicht kurz aus.

Wenn ihr im Admin-Bereich den Review-Stand eines Flags prüft, wertet die Oberfläche diesen Stand jetzt pro Flag aus. Maßgeblich ist also nicht mehr nur eine globale Liste der zuletzt eingegangenen flag.*-Ereignisse, sondern der jeweils letzte passende Stand genau dieses Flags. Dadurch verschwinden falsche Hinweise wie „Update blockiert“, wenn ein Flag für seine aktuelle Version bereits freigegeben wurde und zwischenzeitlich andere Flag-Ereignisse, Test-Overrides oder ältere Migrationsereignisse angefallen sind.

Wichtig bleibt: Ein echter Versionssprung eines Flags kann weiterhin bewusst blockierend wirken, bis der neue Stand erneut geprüft oder freigegeben wurde.

Session-Test-Overrides und Whitelabel-Freigaben können dieses Zielgruppen-Gate weiterhin gezielt umgehen. Wenn du auf /admin/testing für einen Login gezielt Test-Overrides setzt, sind diese Overrides jetzt auch während der Anmeldung und in der laufenden Sitzung verbindlich maßgeblich. Manuelle Session-Overrides haben dabei Vorrang vor Whitelabel-Booleans, Rollout-Stufen und Zielgruppe.

Praktisch ist das vor allem für Tests und Abnahmen wichtig: Flag-abhängige Bereiche wie ein Eintrag in der Sidebar, Einführungsdialoge oder Hinweise zur Ablage sollen nach dem Login denselben Override-Stand zeigen wie die Sitzung selbst. Wenn die Oberfläche die Client-Flags noch lädt, warten solche Hinweise deshalb zunächst, statt kurz im falschen Zustand aufzuspringen.

Auf /admin/testing kann zusätzlich der Button Entfernungs-Prompt erscheinen. Er erzeugt einen Prompt für einen Agenten, der veraltete Feature-Flags zur Bereinigung vorbereitet. Berücksichtigt werden dabei nur Flags ohne Aktivität seit mehr als 60 Tagen, die nicht als permanent markiert sind.

Für die vorgeschlagene Bereinigung gilt:

• Released: Das Flag soll auf Bake-in true gesetzt und anschließend entfernt werden.
• Nicht released: Das Flag soll auf Bake-in false gesetzt und anschließend entfernt werden.
• Alpha und Beta: Diese Zwischenstufen werden derzeit nicht automatisch umgestellt, sondern im Prompt nur als Hinweis aufgeführt.

Wenn ihr Änderungen an Feature-Flags plant, prüft nach einem Versionssprung trotzdem kurz die Flag-Übersicht. Nutzt den Entfernungs-Prompt nur als Arbeitsgrundlage und kontrolliert insbesondere Hinweise zu Alpha- und Beta-Flags noch einmal manuell. Wenn ihr auf /admin/testing mit Filtern wie Review offen arbeitet, gelten Karten oberhalb der Tabelle und Tabelleninhalt jetzt auf derselben gefilterten Flag-Menge. Blockierte Flags außerhalb des aktiven Filters erscheinen damit nicht mehr zusätzlich in der Blocker-Karte. Testet bei Nutzer-Flags zusätzlich einen Reload im eingeloggten Zustand oder einen Tab-Wechsel mit anschließendem Fokus. So seht ihr sofort, ob die gewünschte Freigabe auch während einer Session stabil sichtbar bleibt.

Wenn in eurem Setup die Feature-Flag imgproxyAdminSettings freigeschaltet ist und ein Imgproxy-Endpunkt konfiguriert wurde, erscheint in der Admin-Oberfläche unter /admin im Bereich Infrastruktur & Events zusätzlich die Karte Icon Assets. Sie führt zur Seite /admin/assets.

Dort könnt ihr zentral kleine Bilddateien für Symbole und ähnliche Assets verwalten. Die Übersicht lädt vorhandene Bilder direkt aus dem tatsächlichen Imgproxy-MCP-Speicher und zeigt die zuletzt geänderten Dateien zuerst an.

Typischerweise gehört dazu:

1. vorhandene Icon-Assets anzeigen
2. neue Dateien hochladen
3. nicht mehr benötigte Assets löschen
4. für ein vorhandenes Asset einen direkt nutzbaren Imgproxy-Link erzeugen

Beim Erzeugen eines Links arbeitet die Oberfläche mit der hochgeladenen Datei selbst. Imgproxy-Key und Salt werden dabei weiterhin nur für signierte Vorschau- und Transformations-URLs genutzt. Es ist keine separate Asset-Registrierung in einer Datenbank nötig.

Wenn die Karte Icon Assets in eurer Admin-Übersicht fehlt oder die Liste leer bzw. fehlerhaft bleibt, prüft zuerst:

1. ob die Feature-Flag imgproxyAdminSettings für euren Nutzer sichtbar ist
2. ob die Imgproxy-Umgebung in eurem Setup überhaupt konfiguriert wurde
3. ob im Imgproxy-MCP-Speicher bereits passende Bilddateien vorhanden sind
4. ob ihr euch in der Admin-Oberfläche und nicht nur in den normalen Space-Einstellungen befindet

Einstellungen für Gruppen oder gemeinsame Bereiche

Bei Gruppen und gemeinsamen Bereichen ist oft wichtiger:

• wer Zugriff hat
• welche Inhalte dort gemeinsam gepflegt werden
• welche Regeln oder Standards für das Team gelten

Gruppen haben nicht immer dieselben Einstellungsbereiche wie Assistenten. Wenn kein eigener Assistent dahinter liegt, stehen eher Zusammenarbeit, Berechtigungen und gemeinsamer Kontext im Mittelpunkt als direkter Chat-Betrieb.

Einstellungen im persönlichen Bereich

Dein persönlicher Bereich hat oft einige eigene Punkte, die in Gruppen so nicht vorkommen. Dazu gehören zum Beispiel persönliche Angaben, Hinweise oder dein individueller Arbeitskontext. Diese Bereiche helfen dir vor allem dabei, CLYE AI auf deine tägliche Nutzung abzustimmen, nicht auf einen Teamprozess.

Typisch sind dort:

• persönliches Wissen und eigene Vorlagen
• individuelle Dateien oder Notizen
• Anpassungen, die nicht sofort für ein ganzes Team gelten sollen
• persönliche Hinweise und Präferenzen für deinen Arbeitsalltag
• persönliche Agent Plugins, falls sie in eurem Setup dafür freigeschaltet sind

Wenn dir ein Bereich fehlt

Nicht jede Person darf alles anpassen. Wenn du eine Quelle, Integration oder Freigabe brauchst, aber die passende Einstellung nicht siehst, kläre zuerst:

1. Bist du im richtigen Assistenten, Space oder persönlichen Bereich?
2. Hast du dort die nötige Rolle?
3. Ist der gewünschte Bereich überhaupt für diesen Kontext vorgesehen?

Nicht alles auf einmal anpassen

Viele Probleme entstehen nicht durch zu wenig Konfiguration, sondern durch zu viel davon. Ein gutes Vorgehen ist:

1. erst den Einsatzzweck klären
2. nur die nötigen Einstellungen aktiv anpassen
3. im Alltag prüfen, was wirklich hilft
4. Änderungen bei Bedarf schrittweise ergänzen

Hinweise und Einführungen erneut nutzen

Wenn du einen Bereich neu erklären, selbst noch einmal sauber durchgehen oder Onboarding-Hinweise erneut sehen willst, findest du je nach Bereich auch Einstellungen für Hinweise oder Einführungen. Das ist besonders praktisch bei persönlicher Ablage, Gruppen-Ablagen, Assistenten-Ablagen und Skills.

Typischerweise heißt dieser Bereich Hinweise. Dort kannst du Einführungen zurücksetzen, damit sie beim nächsten Besuch erneut angezeigt werden.

Feedback und Verbesserung

Auch Rückmeldungen aus der Nutzung gehören indirekt zu guter Anpassung. Wenn ein Assistent wiederholt unpassend reagiert, lohnt sich meist ein Blick auf:

• das zugrunde liegende Wissen
• bestehende Skills
• genutzte Werkzeuge oder Quellen
• die grundsätzliche Beschreibung des Einsatzzwecks

Kurz gesagt

Einstellungen in CLYE AI sollen Assistenten und Gruppen klarer, nützlicher und passender machen. Passe deshalb vor allem Zweck, Wissen, Zugriff und Zusammenarbeit an, und beachte dabei immer, was in deinem Bereich und mit deiner Rolle tatsächlich sinnvoll freigegeben ist.

Kommandozeilen-Tool (CLI)

Für technische Nutzer:innen gibt es die CLYE CLI (clye). Sie kann genutzt werden, um z. B. eine Verbindung zu einer CLYE-AI-Instanz herzustellen, Tools aufzurufen oder Konnektoren lokal als MCP-Server zu starten.

In vielen Umgebungen wird das Tool zusätzlich unter den Aliasen ai-hub-cli und ai-hub installiert.

• Offizielle Dokumentation & Installation: https://ai-hub-cli.s3.de.io.cloud.ovh.net/index.html

App-Name, Link-Vorschau und Symbole

Die Anwendung verwendet die Bezeichnung CLYE AI konsistent. Dadurch sind Seitentitel, Link-Vorschauen, App-Name, Vorschaubilder und App-Symbole in Browsern und bei installierter Web-App einheitlich.

Auch die öffentliche Changelog-Seite unter /changelog erscheint mit derselben App-Shell wie die Hauptanwendung. Dadurch wirken Browser-Tab, geteilte Links, Mobilansichten und installierte Web-App konsistent. Die Seite wird dabei als vollständiges HTML-Dokument der Anwendung ausgeliefert, inklusive <!DOCTYPE html>, <html lang="de" translate="no" class="notranslate …">, Sprachkennzeichnung, deaktivierter Auto-Übersetzung, Theme-Color, Manifest, Discovery-Link, Open-Graph- und Twitter-Metadaten mit mehreren Vorschaubildern und twitter:card, Apple-Web-App-Angaben wie mobile-web-app-capable, apple-mobile-web-app-title und apple-mobile-web-app-status-bar-style, Favicon- und Touch-Icons in mehreren Varianten sowie direkt eingebundenen Stylesheets und vorab geladenen JavaScript-Chunks der Haupt-App.

Wenn du noch ältere Bezeichnungen, Vorschauen oder Symbole siehst:

1. aktualisiere die Seite im Browser
2. schließe die Web-App vollständig und öffne sie erneut
3. installiere oder hefte die Web-App bei Bedarf neu an, damit aktuelle Symbole und der Name CLYE AI übernommen werden

Eine Übersicht der sichtbaren Änderungen findest du im Changelog.