Desktop-first
Lokal, wo es zählt — zentral, wo es hilft.
CompanyWizard gibt es als Web-Interface und als Desktop-App. Für die meisten Fälle empfehlen wir den Desktop-Client: Er hält Daten lokal auf dem eigenen Rechner und bleibt trotzdem voll an die zentralen Team-Funktionen angebunden. Das Web bleibt die richtige Wahl, wenn ortsunabhängiger Zugriff oder durchgehende Automatisierung im Vordergrund stehen.
Der Browser ist bequem — aber er verlagert alles auf einen Server
Viele LLM-Chats laufen heute im Browser. Das ist bequem, verlagert aber Daten, Zugänge und Verarbeitung auf einen Server. Bei einem Werkzeug, das mit Firmenwissen arbeitet, ist das nicht immer erwünscht.
Die übliche Alternative — alles lokal — kostet meist die Team-Anbindung. CompanyWizard bietet beide Wege an und löst genau diesen Zielkonflikt auf.
Datenhoheit, ohne die Zentrale aufzugeben
Mit der Desktop-App können Daten vollständig lokal bleiben, inklusive lokaler Indizierung über eine eingebaute SQLite-Vec-Datenbank. Lokale Datenhaltung bedeutet dabei nicht den Verzicht auf gemeinsame Arbeit: Über Shared Vaults, LDAP-Anmeldung und Messaging nutzen Sie die zentralen Funktionen weiter.
Hinzu kommt lokale Flexibilität bei Werkzeugen: Über den stdio-Transport binden Sie MCP-Server als lokalen Prozess ein — eigene Python- oder Node-Skripte, die ein reines Web-Interface so nicht erreichen kann. OAuth-Token und Zugänge liegen lokal und sind für andere nicht sichtbar.
Was der Desktop-Client lokal hält
-
Daten & Index
Dokumente und Vektorindex bleiben auf dem eigenen Rechner — die Inhalte verlassen ihn nicht.
-
Lokale Werkzeuge (Beta)
MCP-Server über stdio-Transport: eigene Skripte und Werkzeuge als lokaler Prozess.
-
Private Zugänge
OAuth-Token und angebundene MCPs liegen lokal, für andere nicht sichtbar.
-
Statistik & Nachrichten
Nutzungsstatistik und Chat-/Messaging-Nachrichten in einer lokalen SQLite-Datenbank.
-
Anmeldung ohne Server
Über einen OTP-Fallback ist die Anmeldung lokal möglich, selbst wenn die Server-API gerade nicht erreichbar ist.
Web-Interface oder Desktop-App?
| Kriterium | Web-Interface | Desktop-App |
|---|---|---|
| Installation | Keine, nur Browser | Einmalige Installation pro Rechner |
| Zugriff | Von überall, auch mobil | An den eigenen Rechner gebunden |
| Datenhaltung | Auf dem Server | Vollständig lokal möglich |
| Lokale Werkzeuge (stdio-MCP, Beta) | Nicht möglich | Mit lokaler Python-/Node-Umgebung |
| OAuth-Token & MCP-Zugänge | Serverseitig | Lokal, für andere nicht sichtbar |
| Anmeldung bei Server-Ausfall | Nicht möglich | OTP-Fallback lokal |
| Hintergrund-Automatisierung | Stärker (serverseitig) | Nur bei geöffneter App |
Was das für Sie bedeutet
- Volle Datenhoheit lokal — bei gleichzeitiger Anbindung an Shared Vaults, LDAP und Messaging.
- Lokale stdio-MCPs (Beta) erschließen Ihre eigene Werkzeuglandschaft, die das Web nicht erreicht.
- Private Zugänge: Ihre Verbindungen zu Drittsystemen wandern nicht über einen gemeinsamen Server.
- Arbeitsfähig auch offline oder bei Ausfall der zentralen Infrastruktur.
Ehrlich gesagt: wann das Web die bessere Wahl ist
-
Ortsunabhängiger Zugriff ohne Installation.
Wer von wechselnden Geräten, mobil oder ohne lokale Installation arbeitet, ist im Browser besser bedient. Der Desktop-Client ist an den Rechner gebunden, auf dem er läuft.
-
Niedrige Einstiegshürde.
Für weniger technische Nutzer ist das Web der einfachere Start. Lokale MCPs mit eigener Python-/Node-Umgebung sind ein Vorteil für Power-User, kein Muss für alle.
-
Durchgehende Automatisierung.
Geplante Agenten laufen im Desktop-Modus nur, solange die App geöffnet ist. Wer rund um die Uhr automatisiert, fährt mit dem serverseitig gehosteten Web-Modus besser.
-
Zentrale Wartung.
Updates und Konfiguration lassen sich im Web zentral ausrollen. Beim Desktop-Client wird pro Rechner installiert und aktualisiert.
Klingt passend für Ihr Haus?
In einer 30-minütigen Demo zeigen wir das Konzept an Ihrem konkreten Anwendungsfall — unverbindlich und mit konkreten Vorschlägen am Ende.