Fallstudie
Jarvis
Ein eigenes Assistenzsystem, das per Sprache bedient wird, Aufträge im Hintergrund abarbeitet und sich selbst überwacht. Entstanden als internes Werkzeug — und die Grundlage für das, was wir an Automatisierung für Kunden bauen.
- Art
- Eigenes System
- Bereiche
- Software · Automation · Infrastructure
- Laufzeit
- Seit 2026, laufend erweitert
- Umfang
- Sprachdienst, Schnittstelle, zwei iPhone-Apps, Hintergrund-Dienste
Internes System ohne öffentlichen Zugang. Im Gespräch zeigen wir es gerne live.
-
01
AusgangslageWer allein eine Firma führt und gleichzeitig entwickelt, verliert die meiste Zeit nicht an schwere Aufgaben, sondern an viele kleine: Zahlen zusammensuchen, Postfach sortieren, nachsehen ob ein Dienst noch läuft, immer wieder dieselbe Auswertung. Jede einzelne dauert fünf Minuten. Zusammen sind es Stunden.
-
02
Die IdeeEin System, das man anspricht wie einen Mitarbeiter: Es versteht die Aufgabe, erledigt sie selbst, und meldet sich, wenn es fertig ist. Nichts, wofür man eine Oberfläche öffnen und sich durch Menüs klicken muss — sondern etwas, das nebenher läuft, während man weiterarbeitet.
- Per Sprache bedienbar, ohne dass dafür ein Fenster offen sein muss
- Längere Aufträge laufen im Hintergrund weiter, auch wenn man weggeht
- Ein Gedächtnis über einzelne Gespräche hinaus
- Auf dem Rechner und auf dem Telefon derselbe Stand
-
03
Die UmsetzungGebaut in Etappen, jede für sich nutzbar: zuerst die Sprachbedienung auf dem Rechner, dann eine abgesicherte Schnittstelle mit gemeinsamem Gedächtnis, darauf zwei native iPhone-Apps, danach die Hintergrund-Dienste und zuletzt eine Schicht, die das ganze System selbst überwacht. Kein großer Wurf auf einmal — jede Etappe musste im Alltag bestehen, bevor die nächste begann.
-
04
Was dabei schwierig warDie interessanten Probleme lagen nicht in der Technik, sondern im Verhalten. Ein Assistent, der zu viel redet, nervt. Einer, der zu wenig fragt, macht Dinge, die niemand wollte. Einer, der jede Aktion bestätigen lässt, ist langsamer als Handarbeit. Die meiste Arbeit steckte darin, diese Grenzen zu finden — und sie so festzulegen, dass sie prüfbar sind und nicht vom Zufall abhängen.
Architektur
Wie es aufgebaut ist.
Sechs Schichten, jede mit einer Aufgabe. Was oben hereinkommt, wird nach unten durchgereicht — und jede Schicht lässt sich austauschen, ohne die anderen anzufassen.
-
01
Spracherkennung
Eingabe
Nimmt Gesprochenes auf und wandelt es in Text. Läuft dauerhaft mit, reagiert aber erst auf ein Schlüsselwort — und lässt sich auf Zuruf ganz abschalten.
-
02
Sprachmodelle mit Aufgaben-Zuordnung
Entscheidung
Versteht die Aufgabe und wählt, was zu tun ist: selbst antworten, ein Werkzeug benutzen, oder den Auftrag an den Hintergrund abgeben. Wählt dabei auch, wie viel Rechenleistung die Aufgabe wert ist.
-
03
Eigene Werkzeug-Schicht
Werkzeuge
Was das System tatsächlich tun kann: Dateien lesen und schreiben, Befehle ausführen, im Netz nachsehen, auf dem Webserver arbeiten, Postfächer einordnen.
-
04
Regelwerk mit eigenen Tests
Schutz
Vor jeder Aktion eine feste Prüfung: Eine kurze Liste wirklich kritischer Dinge wird grundsätzlich abgelehnt — nicht nachgefragt, sondern abgelehnt. Alles andere läuft ohne Unterbrechung durch.
-
05
Dauer-Dienste mit Budgetgrenze
Hintergrund
Ein eigener Dauer-Dienst holt sich längere Aufträge und arbeitet sie ab, während niemand am Rechner sitzt. Mit Kostengrenze je Auftrag und je Tag, und einer Meldung, wenn er fertig ist.
-
06
Strukturierter Speicher
Gedächtnis
Hält fest, was wichtig war — nicht als Protokoll, sondern in einzelne Aussagen zerlegt und verknüpft. Dadurch fällt auf, wenn etwas Neues einer früheren Entscheidung widerspricht.
Entscheidungen
Warum es so gebaut ist.
Die Entscheidungen, die den Unterschied gemacht haben — und was dagegen sprach.
-
01
Nicht jede Aufgabe bekommt die größte Maschine
Ein kurzer Befehl braucht kein Modell, das für Architekturarbeit gedacht ist. Das System entscheidet pro Auftrag, wie viel Rechenleistung angemessen ist. Das senkt die laufenden Kosten deutlich, ohne dass schwere Aufgaben schwächer werden — und es ist derselbe Gedanke, den wir auch in Kundenprojekten anwenden, wo KI im Spiel ist.
-
02
Eine kurze Sperrliste statt vieler Rückfragen
Der erste Entwurf fragte vor riskanten Aktionen nach. In der Praxis war das langsamer als alles von Hand zu machen. Jetzt gibt es eine kurze, feste Liste von Dingen, die grundsätzlich abgelehnt werden — Geld ausgeben, Zugangsdaten anfassen, etwas nach außen senden. Alles andere läuft durch. Weniger Reibung und eine klarere Grenze als eine Rückfrage, die man irgendwann im Reflex wegklickt.
-
03
Erst beobachten, dann reparieren
Die Selbstüberwachung prüft laufend, ob alle Teile gesund sind, untersucht Auffälligkeiten und schlägt Lösungen vor — aber sie ändert nichts. Ein System, das sich selbst repariert, bevor jemand seine Diagnosen überprüft hat, repariert irgendwann das Falsche. Das Reparieren kommt erst, wenn die Vorschläge über längere Zeit gestimmt haben.
-
04
Ausfall einplanen, nicht ausschließen
Die Schnittstelle liegt auf einem eigenen Server, aber das System funktioniert auch ohne sie: Fällt sie aus, greift es unbemerkt auf die lokale Ablage zurück. Eine der beiden Telefon-Apps kommt ganz ohne Netz aus. Die Frage ist nie, ob ein Teil ausfällt, sondern was dann passiert.
-
05
Der Mensch behält den letzten Klick
Das System bereitet vor — sucht heraus, vergleicht, legt an. Aber alles, was Geld kostet oder nach außen geht, macht der Mensch selbst. Dafür hat das System bewusst kein Werkzeug, nicht nur eine Regel.
Was dabei herauskam
Ein System, das täglich im Einsatz ist — und dessen Bausteine inzwischen in Kundenprojekte zurückfließen.
- Wiederkehrende Aufgaben laufen, ohne dass jemand sie anstößt
- Längere Aufträge werden erledigt, während anderswo weitergearbeitet wird
- Störungen fallen auf, bevor sie jemandem auffallen
- Dieselben Daten auf Rechner und Telefon, auch ohne Netz
- Über tausend automatische Tests sichern das Verhalten ab
Was wir daraus mitnehmen
Bei Automatisierung ist die Technik selten das Problem. Schwierig ist die Frage, wie weit ein System allein entscheiden darf — und was passiert, wenn es sich irrt. Darum beginnt jedes Automatisierungs-Projekt bei uns mit dieser Frage und nicht mit der Werkzeugwahl.
Kontakt
Etwas Ähnliches für dein Unternehmen?
Automatisierung muss nicht groß anfangen. Meist reicht eine wiederkehrende Aufgabe, die ab jetzt von selbst läuft.