Gute KI-Automatisierung fängt heute nicht mit dem großen Agentenversprechen an, sondern mit einer einfachen Frage: Wo liegt in deinem Alltag der Kontext herum? Servus, ich bin Lissy, und heute ist Dienstag, also Werkzeugtag. Die Funde von heute wirken klein: ein Zeiterfasser, ein Projektmanagement-Tool, eine Datenbank-Schicht für Buchhaltung, ein Smartphone-Agent und eine Telefonie-Plattform. Zusammen zeigen sie aber ein Muster. KI wird dann nützlich, wenn sie verstreute Spuren in etwas Verwendbares verwandelt: Zeiten, Tickets, Buchungen, Buchhaltungsdaten, Bildschirmaktionen und Telefonate. Genau dort entsteht im Betrieb jeden Tag Reibung.
Fangen wir mit Threshyr an. Der Entwickler arbeitete parallel an mehr als drei Projekten und konnte am Tagesende oder Monatsende nicht mehr sauber rekonstruieren, wo die Zeit geblieben war. Klassische Tracker halfen ihm nicht, weil sie entweder manuelles Start und Stop verlangen, monatlich kosten oder Aktivitäten in die Cloud schicken. Threshyr läuft deshalb als Hintergrund-App auf Windows und macOS. Es erfasst lokal aktive Programme und Browser-Domains, ordnet sie Kategorien zu und markiert sie als produktiv, neutral oder unproduktiv. Die KI hilft auf dem Gerät bei der Einordnung.
Das klingt kleiner als ein autonomer Firmen-Agent, ist aber genau deshalb gut. Viele Selbstständige und Agenturen haben kein Erkenntnisproblem, sondern ein Rekonstruktionsproblem. Man weiß ungefähr, dass man gearbeitet hat, aber nicht sauber genug für Rechnung, Retainer-Auswertung oder Projektplanung. Wenn ein lokales Tool diese Spur zurückgibt, ohne jede Seite an einen Cloud-Dienst zu schicken, ist das ein echter Hebel.
Der erste Test ist simpel. Nimm eine Arbeitswoche und prüfe, ob du für drei parallele Projekte aus dem Kopf sagen kannst, wie viel Zeit in Kommunikation, Produktion und Verwaltung ging. Wenn nicht, brauchst du nicht zuerst einen Agenten. Du brauchst Messbarkeit. Für Solo-Berater, Freelancer oder kleine Studios kann genau das mehr bringen als ein weiterer Textgenerator.
Das zweite Beispiel ist Liniora. Der Builder beschreibt ein Problem aus Remote-Teams: Tickets verlieren Kontext, obwohl schon Projektmanagement-Systeme im Einsatz sind. Ein Bug taucht in Slack auf, wurde vorher in einem Meeting erwähnt, hängt vielleicht mit einem Branch zusammen, und im Ticket steht am Ende trotzdem nur ein Satz. Zwei Tage später reicht das keiner Person mehr. Liniora verbindet deshalb Meeting-Transkripte, Slack-Threads und Versionskontrolle. Meetings werden automatisch registriert und indexiert. Ein Slack-Bugthread kann per Erwähnung übernommen werden. Dazu kommt Code-Bezug.
Wichtig ist hier nicht, dass KI Projektmanager ersetzt. Der Punkt ist nüchterner: Remote-Arbeit erzeugt Spuren in mehreren Systemen. Wenn niemand sie zusammenführt, wird Arbeit teurer, weil Menschen suchen, nachfragen und interpretieren müssen. Liniora macht daraus einen Workflow: Meeting-Kontext sammeln, Slack-Verlauf ziehen, Ticket erzeugen, Code-Bezug herstellen.
Für Unternehmen ist das ein guter Prüfstein. Wenn Tickets schlecht sind, ist die Ursache oft nicht Faulheit. Vielleicht fehlen die Inputs. Dann hilft keine neue Pflichtvorlage mit noch mehr Feldern. Besser ist die Frage: Wo entsteht der Kontext zuerst, und kann ich ihn automatisch an den Ort bringen, an dem entschieden wird?
Dann kommt Instabooks, und das ist der trockenste, aber geschäftlich vielleicht wichtigste Fund. Die Dokumentation sagt klar: Instabooks legt eine read-only PostgreSQL-Schicht über QuickBooks Online. Man kann QuickBooks-Daten also per SQL abfragen, aus psql, Excel, DBeaver, Python oder jedem normalen Postgres-Treiber. Der Builder argumentiert, dass die normale QuickBooks-API für interne Apps und Agenten oft umständlich ist. SQL dagegen können viele Werkzeuge gut.
Praktisch ist das stark. Kleine Betriebe haben ständig Fragen wie: Welche Rechnungen sind überfällig, welche Kunden zahlen spät, welche Ausgaben steigen, welche Projekte bringen Marge? Wenn diese Daten nur über Spezial-APIs zugänglich sind, bleibt Automatisierung liegen. Wenn sie als read-only Datenbank verfügbar sind, lassen sich Reports, Agenten und kleine interne Tools viel schneller bauen.
Der Sicherheitswinkel zählt. Read-only heißt nicht automatisch sicher, aber es reduziert den Schaden. Ein Agent, der Finanzdaten lesen darf, muss noch lange keine Buchungen verändern dürfen. Genau so sollte man anfangen: erst lesen, erklären, markieren, vergleichen. Danach entscheidet ein Mensch. Lesen, Vorschlagen und Schreiben sind drei verschiedene Rechte. Wer das vermischt, baut unnötig Risiko in einen empfindlichen Prozess.
Aus der Forschung passt BlueLM-GUI gut dazu. Das Paper beschreibt einen mobilen GUI-Agenten mit 35 Milliarden Parametern insgesamt, davon etwa drei Milliarden aktiv. Trainiert wird über einen echten Geräte-Flywheel. Der Gedanke: Smartphone-Agenten werden nicht gut genug, wenn sie nur in Sandboxen klicken. Sie müssen an echten Geräten scheitern, diese Fehler einsammeln und daraus wieder Trainingsdaten machen. Der Bericht nennt 87,4 auf MobileGUI-VBench. Das ist ein Paper-Claim, kein unabhängiger Beweis, aber der Ansatz ist spannend.
Warum passt das zu den Business-Tools von eben? Weil Kontext auch auf dem Smartphone konkret ist. Ein Button, ein Pop-up, eine App-Version, ein Login-Zustand, eine seltsame Tastatur, ein Berechtigungsdialog. Ein Agent, der in einer Demo gut aussieht, kann in dieser echten Oberfläche sofort stolpern. BlueLM-GUI setzt deshalb auf Rollouts auf realen Phones, Korrektur von Abläufen und Benchmarks, die mit dem Modell mitwachsen.
Wenn euch ein Anbieter sagt, sein Agent könne eure App bedienen, fragt nicht zuerst nach der schönsten Demo. Fragt, woran er scheitert. Welche echten Geräte wurden getestet? Wie werden Fehlversuche zurückgespielt? Gibt es eine menschliche Korrekturspur? Das ist wie beim Hundetraining, mei. Im Wohnzimmer hört jeder Hund. Draußen wird es interessant.
Als kurzer letzter Werkzeug-Fund ist Ringee dabei. Die Plattform positioniert sich als Open-source Lösung für menschliche und KI-Telefonie. Harte Nutzungszahlen gibt es im öffentlichen Launch noch nicht, deshalb bleibt es ein Quick Hit. Der Bereich ist trotzdem wichtig: Telefon bleibt in vielen kleinen Betrieben der Ort, an dem Termine, Leads, Supportfragen und Notfälle landen.
Der sinnvolle Test ist nicht: Kann die KI ein Gespräch führen? Das können viele Demos irgendwie. Der Test ist: Wann übergibt sie? Erkennt sie, dass ein Kunde wütend ist, dass eine Zahlung strittig ist, dass Verantwortung beim Menschen bleiben muss? Kann sie nach dem Gespräch ein sauberes Protokoll schreiben, einen Termin vorschlagen und trotzdem die Grenze halten?
Wenn Ringee als offene Telefonie-Schicht reift, könnte das für Handwerksbetriebe, kleine Praxen, lokale Dienstleister oder Agenturen interessant werden. Aber nur mit klaren Skripten, klaren Übergaben, klarer Aufzeichnung und klarer Verantwortung. Telefonie ist kein Spielplatz, weil am anderen Ende ein Mensch sitzt, der gerade wirklich etwas will.
Am Ende vom Tag bleibt bei mir: Die besten KI-Werkzeuge von heute wirken fast langweilig, wenn man nur auf Modellnamen schaut. Zeit rekonstruieren. Ticket-Kontext sichern. Buchhaltungsdaten lesbar machen. Smartphone-Aktionen auf echten Geräten testen. Telefonate sauber übergeben. Aber genau diese langweiligen Stellen sind im Betrieb oft teuer. Wenn ihr diese Woche etwas testen wollt, sucht nach einer Aufgabe, bei der Informationen verstreut sind und jeden Monat wieder Arbeit kosten. Dann prüft drei Dinge: Wo entstehen die Daten, wer darf sie lesen, und wo muss ein Mensch entscheiden. Wenn euch die Folge geholfen hat, hinterlasst gern eine Bewertung auf Apple Podcasts oder Spotify. Die Mailadresse steht wie immer in den Shownotes. Pfiat euch und bis morgen, eure Lissy.