Jede Version ist ein Meilenstein, aber Version 2 ist etwas grundlegend Neues. Es ist der Moment, in dem awaBerry von einer Plattform, die Ihnen Zugriff auf Ihre Geräte gewährt, zu einer Plattform wird, die Ihre Geräte für Sie arbeiten lässt – autonom, nach Zeitplan, über die gesamte Flotte hinweg, ohne menschliches Eingreifen für jeden Durchlauf.

Ich möchte Ihnen erläutern, was genau in Version 2 enthalten ist und, was noch wichtiger ist, warum wir sie so entwickelt haben, wie wir sie entwickelt haben.

Der Kontext: Warum Automatisierung als Nächstes kommen musste

Als wir die ersten Versionen von awaBerry veröffentlichten, war das Problem, das wir lösten, der Zugriff. Der Zugriff auf ein Gerät ohne VPN, ohne offene Ports, von überall auf der Welt – dieses Problem wurde von bestehenden Lösungen nicht gut gelöst, insbesondere für die Arten von Geräten, die unseren Nutzern wichtig sind: Edge-Hardware, SoC-Boards, Maschinen hinter NAT, Container ohne öffentliche IPs. Wir haben awaBerry Anywhere entwickelt, um dies zu lösen.

Aber Zugriff ist kein Selbstzweck. Er ist eine Voraussetzung. Was Nutzer tatsächlich wollen, ist nicht, ein Gerät erreichen zu können – sie wollen, dass das Gerät etwas tut. Und etwas wiederholt, zuverlässig, nach einem Zeitplan zu tun, ohne dass eine Person jeden Durchlauf initiiert, ist Automatisierung.

Version 2 ist also die Automatisierungsschicht. Und da wir bereits die Zugriffsschicht aufgebaut hatten, konnten wir die Automatisierungsschicht korrekt aufbauen – nicht als separates Produkt, sondern als natürliche Erweiterung der bereits vorhandenen Infrastruktur.

Das Smart Automation Framework

Das Herzstück von Version 2 ist das Smart Automation Framework. Es ist ein KI-nativer Ansatz zur Automatisierung, der sich meiner Meinung nach architektonisch stark von dem unterscheidet, was die meisten Menschen erwarten, wenn sie "KI-Automatisierung" hören.

Hier ist die zentrale Designentscheidung: Wir trennen strikt die Schreibphase von der Ausführungsphase. Wenn Sie ein neues Automatisierungsprojekt erstellen, analysiert ein leistungsfähiges Reasoning-Modell – Gemini 2.5 Pro – Ihre Anweisungen in einfacher Sprache, erkundet die lokale Umgebung auf dem Zielgerät und schreibt ein deterministisches, ausführbares Skript (Python, JavaScript oder Shell, je nachdem, was sinnvoll ist). Dies geschieht einmal. Die KI-Tokens werden einmal verbraucht. Das Skript wird gespeichert.

Jeder nachfolgende geplante oder ausgelöste Durchlauf führt dieses Skript direkt aus – nur lokale CPU, null KI-Tokens verbraucht. Wenn Sie zur Laufzeit eine KI-Zusammenfassung der Ausgabe benötigen, wird ein günstigeres Modell wie Gemini 2.5 Flash Lite selektiv aufgerufen – etwa 100 bis 500 Tokens pro Durchlauf. Aber die Kernlogik läuft jedes Mal, unbegrenzt, zu null Token-Kosten.

So funktionieren die meisten KI-Automatisierungstools nicht. Die meisten von ihnen binden die LLM bei jeder Ausführung erneut ein. Wir haben diesen Kompromiss sorgfältig abgewogen und entschieden, dass er falsch ist: Er ist langsam, teuer und nicht deterministisch. Ihre Automatisierung sollte sich bei Durchlauf 1 und Durchlauf 1.000 gleich verhalten. KI-Reasoning dient dem Schreiben der Logik. Die Ausführung sollte ein schnelles, zuverlässiges Skript sein.

Was das Framework automatisieren kann

Das Framework unterstützt eine breite Palette von Automatisierungskategorien:

  • Intelligente Web-Automatisierung – Scraping von dynamischen Single-Page-Anwendungen über Headless-Browser (Playwright / Puppeteer), die automatisch aus einer Beschreibung in einfacher Sprache generiert werden. Preisüberwachung, Wettbewerbsverfolgung, Content-Aggregation, Formularautomatisierung.
  • Lokales Systemmanagement – Parsen von Log-Dateien, Verwalten lokaler Datenbanken, Kategorisieren und Weiterleiten von Dokumenten, Dateisystemoperationen auf dem Gerät, dem die Daten gehören.
  • API- und Service-Orchestrierung – Abrufen von Daten von externen Endpunkten, Transformieren von Payloads, Übermitteln bereinigter Daten an Dashboards oder CRMs nach einem Zeitplan.
  • Brücken zu Legacy-Systemen – Generieren von Automatisierungsskripten auf OS-Ebene, die mit älteren Software-UIs interagieren, denen moderne APIs fehlen.

Zeitplanung für Remote Desktop und Zero-Trust Port Forwarding

Version 2 erweitert auch das Zeitplanungssystem, um zwei der am häufigsten genutzten awaBerry Anywhere-Funktionen abzudecken: Remote Desktop (VNC und RDP) und Zero-Trust Port Forwarding. Sie können jetzt zeitbasierte Zeitpläne definieren, um diese Verbindungstypen auf registrierten Geräten automatisch zu aktivieren.

Dies ist besonders nützlich, wenn Automatisierungsworkflows von einer grafischen Benutzeroberfläche oder einem lokal laufenden Dienst abhängen, der zu einer vorhersehbaren Zeit verfügbar sein muss. Anstatt dass eine Person die Verbindung initiiert, bevor der Workflow beginnt, übernimmt das System dies automatisch.

Verbindungsgeschwindigkeit in Echtzeit

Es gibt eine dritte Änderung in Version 2, die weniger sichtbar, aber wohl genauso wirkungsvoll ist: die Verbindungsgeschwindigkeit. Infrastrukturverbesserungen in dieser Version reduzieren die Zeit von der Initiierung einer Verbindung bis zu einer nutzbaren Sitzung auf nahezu Echtzeit. Dies ist für die interaktive Nutzung wichtig, aber für automatisierte Workflows noch wichtiger – wo eine langsame Verbindungsaufbauzeit sich über Dutzende von Geräten und Hunderte von geplanten Läufen multipliziert.

Wie alles zusammenpasst

Die Architektur der Version 2 betrachte ich als zwei eng gekoppelte Schichten. Die Agentic API ist das Zugangs-Fabric – sie kann jedes registrierte Gerät, überall, über einen Zero-Trust-HTTPS-Tunnel erreichen, authentifiziert durch einen Project Key mit präzise definierten Berechtigungen. Das Smart Automation Framework ist die Intelligenzschicht – es weiß, was zu tun ist, wenn es dort ankommt.

Keine der beiden ist ohne die andere vollständig. Das Smart Automation Framework kann für sich allein nur Dinge auf dem lokalen Computer automatisieren, auf dem es läuft. Die Agentic API bietet für sich allein Zugriff, erfordert aber, dass Sie die gesamte Logik selbst schreiben. Zusammen bilden sie einen geschlossenen Kreislauf: Beschreiben Sie, was auf Ihrer gesamten Flotte geschehen soll, und es geschieht – nach einem Zeitplan, auf jedem Gerät, ohne Ihre fortlaufende Beteiligung.

Das ist die Plattform, die wir aufbauen wollten. Version 2 ist der Zeitpunkt, an dem sie Realität wird. Entdecken Sie awaBerry Device Automation →