Bereit für Agenten — das ist die Runtime, die wir entwerfen.
In Remio ist heute kein Agent-SDK enthalten, und wir versprechen keinen Termin. Was es bereits gibt, ist der Grund, warum wir den Aufbau für lohnenswert halten: Remios native Eingabe- und Bildschirmaufnahme-Pipeline funktioniert schon heute für Menschen, die an einem echten Mac, PC oder Linux-Rechner sitzen. Diese Seite ist der ehrliche Entwurf für das, was als Nächstes kommt — und für die Leitplanken, auf die wir uns festlegen, bevor irgendetwas davon erscheint.
Warum Agenten einen echten Bildschirm brauchen.
Eine Browser-Sandbox genügt für einen Agenten, der nur Webformulare ausfüllt. Sobald die Arbeit in native Apps hineinreicht, ist die Sandbox am Ende. Ein echter Desktop ist die sauberste Laufzeitumgebung für Agenten — was ein Mensch nutzt, kann auch ein Agent nutzen.
Ein Agent, der nur in einem Headless-Browser lebt, kann Final Cut nicht öffnen, keine Videodatei aus dem Finder in ein Kreativwerkzeug ziehen, kein PDF in der Vorschau signieren, kein .dmg- oder .exe-Installationsprogramm ausführen, einer anderen App keine Berechtigung zur Bildschirmaufnahme erteilen, keine Datei im Dateiauswahldialog des Systems auswählen und einen unerwarteten modalen Dialog des Betriebssystems nicht überstehen. Genau in diesen Momenten spielt sich der Großteil echter Arbeitsabläufe ab — und genau dort scheitert der Agent im Headless-Browser leise.
Virtualisierte Container (das Muster „Agent-Computer“ der großen Labore) schließen einige dieser Lücken, bringen aber eigene mit. Das Abbild ist meist ein minimaler Linux-Desktop mit einer Handvoll vorinstallierter Apps; alles außerhalb davon ist unerreichbar. Der Container hat keinerlei Verbindung zur tatsächlichen Arbeit des Nutzers — zu dessen installierten Apps, angemeldeten Konten, gespeicherten Dateien und erteilten Berechtigungen. Jeder Agentenlauf beginnt auf einem leeren Rechner, der nicht der Rechner des Nutzers ist.
Remios Entwurf geht den anderen Weg. Ein Agent, der über die Runtime verbunden wäre, die wir bauen, bekäme den echten Desktop des Nutzers — den tatsächlichen Mac, PC oder Linux-Rechner, an dem der Nutzer arbeitet — über dieselbe Remote-Desktop-Sitzung, die ein Mensch schon heute verwendet. Jede installierte App wäre da. Jedes angemeldete Konto wäre da. Jede Datei wäre da. Der Agent wäre kein Mieter einer künstlichen Umgebung, sondern Gast auf dem tatsächlichen Arbeitsplatz des Nutzers — so lange, wie der Nutzer ihn hineinlässt, und keinen Augenblick länger.
Die Pipeline, die ein Agent nutzen würde — läuft bereits, für Menschen.
Jeder Klick, jeder Tastendruck und jede Scrollbewegung, die ein Remio-Nutzer heute sendet, landet bereits über das native Eingabesystem des Betriebssystems auf dem Host — als genau das Ereignis, das eine physische Maus oder Tastatur erzeugen würde. Diese Pipeline ist nicht hypothetisch; sie ist es, die Remio heute für Menschen auf einem echten Mac, PC oder Linux-Rechner funktionieren lässt. Und sie ist, nicht zufällig, genau das Fundament, an das sich eine Agent Runtime anschließen würde: keine eigene Agenten-API, keine künstlich in die Ereigniswarteschlange eines Fensters eingespeisten Tastenanschläge, kein Bedienungshilfen-Ersatz anstelle eines echten Klicks.
Die Designzusage: Falls es erscheint, wäre Agenteneingabe am Host nicht von menschlicher Eingabe zu unterscheiden — weil sie dieselbe Pipeline nutzen würde und keine parallele, nur für Agenten gebaute.
Das ist wichtiger, als es klingt, und deshalb halten wir Remios Architektur für einen wirklich guten Ausgangspunkt für eine Agent Runtime — nicht bloß für einen bequemen. Agentenplattformen, die Eingaben auf Anwendungsebene vortäuschen — künstliche Tastenanschläge in die Ereigniswarteschlange eines Fensters oder Bedienungshilfen-APIs, die UI-Elemente direkt ansteuern —, stoßen ständig an Grenzen: Geschützte Felder lehnen die Eingabe ab, native Tastenkürzel greifen daneben, Drag-and-drop funktioniert nicht zwischen Apps, die Fokusverwaltung gerät durcheinander. Der Weg über die Eingabe-Pipeline des Betriebssystems umgeht all das bereits für die heute laufenden Sitzungen von Menschen. Ihn auf Agentensitzungen auszuweiten, ist noch Entwurfsarbeit — aber das Fundament, das den schweren Teil übernimmt, wird schon ausgeliefert.
Die Berechtigungsgrenze würde bauartbedingt unverändert übernommen. Die Berechtigungen „Bedienungshilfen“ und „Eingabeüberwachung“ des Hosts, die ein Mensch der Remio-Host-App einmal erteilt hat, steuern schon heute jedes Eingabeereignis einer menschlichen Sitzung. Die Designzusage lautet: Eine Agentensitzung würde durch genau dieselbe Freigabe begrenzt — keine eigene Berechtigung, die ein Agent allein halten könnte, keine breitere Tür als die, die der Mensch der App bereits geöffnet hat.
Bildschirmzugriff — und der Entwurf, wie ein Agent ihn nutzen würde.
Remios Bildschirmaufnahme-Pipeline streamt schon heute eine Live-Ansicht des Hosts an einen menschlichen Client — vollständige Bilder, hardwarekodiert, in Echtzeit. Eine Agent Runtime bräuchte noch ein paar weitere Formen derselben Daten: eine Standbildaufnahme auf Abruf, einen kleineren Ausschnitt, eine strukturierte Auslese dessen, was auf dem Bildschirm steht. Keine dieser zusätzlichen Formen existiert bisher im ausgelieferten Code.
Ausgeliefert wird heute der Live-Stream: der Bildschirm des Hosts, laufend aufgenommen, in Hardware kodiert und über denselben verschlüsselten Kanal geliefert, den ein menschlicher Client bereits nutzt. Eine Agent Runtime würde dieselbe Pipeline für ihre eigenen Standbildaufnahmen wiederverwenden — ein einzelnes Bild auf Abruf oder nur den Bereich, auf den ein Modell ohnehin schaut —, statt einen zweiten, getrennten Aufnahmepfad aufzubauen. Diese Wiederverwendung ist eine Entwurfsentscheidung, auf die wir uns festgelegt haben, keine Aussage darüber, was es heute gibt.
Für Agenten, die mit Text besser arbeiten als mit Pixeln, skizziert der Entwurf einen Transkriptmodus: Bildschirmtext samt Begrenzungsrahmen, erzeugt mit der Texterkennung der Plattform selbst (Vision-Framework unter macOS, Windows-OCR-API unter Windows) statt mit einem Bildmodell in der Schleife. Davon ist nichts gebaut. Es steht auf der Liste, weil ein Agent damit einen Textfund in einen präzisen Klick verwandeln könnte, ohne je ein Bild an sein Modell zu schicken — ein echter Effizienzgewinn, wenn wir es gut umsetzen.
Für den strukturierten Zugriff mit der höchsten Genauigkeit skizziert der Entwurf außerdem das Auslesen des Bedienungshilfen-Baums des Betriebssystems für das fokussierte Fenster — desselben Baums, den auch ein Screenreader durchläuft: eine beschriftete Hierarchie aus Schaltflächen, Textfeldern, Menüs und Rollen. Auch davon existiert noch nichts. Und in jeder Version, die wir skizzieren, gilt dieselbe Regel wie bei der Eingabe-Pipeline: Eine Agentensitzung würde genau das sehen, was die Berechtigung zur Bildschirmaufnahme am Host einer menschlichen Sitzung bereits erlaubt — nicht mehr. Ist diese Berechtigung für ein Display ausgeschaltet, bekäme ein Agent von diesem Display nichts zurück — genau wie ein menschlicher Client heute.
Die Leitplanken, auf die wir uns festlegen, bevor wir Agentencode schreiben.
Das sind keine Funktionen, die wir später bauen und hoffentlich richtig hinbekommen. Es sind die Randbedingungen, die der gesamte Entwurf der Agent Runtime erfüllen muss, bevor irgendetwas davon erscheint — jetzt festgelegt, solange es noch keinen Code gibt, der um sie herum gebaut werden müsste.
Jede Remio-Sitzung — ob von Mensch oder Agent — würde auf dieselbe Weise beginnen: Ein Mensch liest einen sechsstelligen Code vom Bildschirm des Hosts ab und gibt ihn am Client ein. Es gibt keinen Entwurf, in dem ein Agent seine eigene Sitzung erstellt, ein Token hält, das er unbemerkt erneuern kann, oder den Zugriff über den Moment hinaus verlängert, in dem der Mensch, der ihn gekoppelt hat, ihn beenden will. Für den nächsten Agentenlauf müsste der Mensch erneut koppeln — jedes Mal ein neuer Human-in-the-Loop-Moment, bauartbedingt.
Solange eine Agentensitzung aktiv ist, würden Host und Client eine dauerhafte, unmissverständliche Anzeige einblenden — und eine Stopp-Schaltfläche, die die Sitzung sofort beendet und von jedem erreichbar ist, der an der Tastatur des Hosts sitzt, nicht nur von der Person, die sie gestartet hat. Jede Aktion des Agenten würde in ein Protokoll geschrieben, das der Mensch einsehen kann. Nichts davon existiert heute im ausgelieferten Code; es ist die Messlatte, die der Entwurf überspringen muss.
Bei der Berechtigungsgrenze gilt dasselbe wie in den Abschnitten zu Eingabe und Bildschirm oben: Eine Agentensitzung würde genau die Berechtigungen des Host-Betriebssystems erben, die eine menschliche Sitzung ohnehin beachtet — Bildschirmaufnahme, Bedienungshilfen — nichts Weitergehendes. Sie bekäme keine eigene erhöhte Freigabe und hätte keinen Weg, den Rahmen zu erweitern, den der Mensch für die Remio-App bereits gesetzt hat. Passt eine Fähigkeit, die wir entwerfen, nicht in diese Grenze, wird sie nicht ausgeliefert.
Noch kein SDK — das ist die Form, auf die wir hin entwerfen.
Remio hat kein Agent-SDK, keine API-Oberfläche und keine Verbindungsspezifikation für Agenten veröffentlicht. Was wir haben, ist eine kurze Liste grundlegender Fähigkeiten, auf die der Entwurf immer wieder zurückkommt — Eingabe, Bildschirmzugriff, strukturierte UI-Auslese — und die Zusage, dass alles, was erscheint, von Anfang an modellunabhängig sein wird.
Die Form, bei der wir immer wieder landen, ist bewusst klein: ein paar Primitive für die Eingabe (ein Klick, eine Taste), ein paar für das Sehen (ein Standbild, ein Bildausschnitt), eines für eine strukturierte UI-Auslese. Das ist die Skizze, keine Spezifikation — nichts davon ist ausgeliefert, und die genaue Schnittstelle ist noch offen. Festgelegt haben wir uns jetzt auf die Form, nicht auf die Syntax.
Modellunabhängigkeit ist eine Entwurfsanforderung, kein Ziel, das wir irgendwann angehen. Was auch immer erscheint, würde gleich funktionieren, ob das Modell, das den Arbeitsablauf plant, Claude, GPT, Gemini oder etwas ist, das Sie selbst betreiben. Wir bauen das nicht um das Tool-Calling-Format eines einzelnen Anbieters herum, denn in dem Moment, in dem wir die Runtime an die Schnittstelle eines Modells binden, geben wir die falsche Art von Versprechen ab.
Die Desktop-Runtime und die Runtime des Agenten selbst sind zwei verschiedene Dinge, und das soll nach unserer Absicht so bleiben. Remio wäre das, was die Aktionen eines Agenten auf einen echten Desktop bringt; das Modell, die Planungsschleife und der Ort, an dem sie läuft, blieben vollständig denen überlassen, die den Agenten bauen. Wir planen nicht, Modelle selbst zu hosten, abzurechnen oder den Zugang zu ihnen zu steuern.
Wofür dieser Entwurf nicht gebaut ist.
Eine Runtime für echte Desktops wäre für manche Agenten-Workflows die richtige Form und für andere die falsche. Hier die kurze, ehrliche Abgrenzung — noch bevor irgendetwas davon erscheint.
Remio ist nicht für einen Agenten gebaut, der nur einen Webbrowser braucht — Seiten auslesen, Formulare ausfüllen, Dashboards lesen. Eine komplette Remote-Desktop-Sitzung ist mehr, als ein Browser-Tab braucht, und Remio versucht nicht, in dieser Kategorie anzutreten.
Remio ist nicht für einen Agenten gebaut, der Dutzende Wegwerf-Umgebungen braucht — eine pro Aufgabe, jedes Mal frischer Zustand, parallele Ausführung. Remio ist um eine dauerhafte, von einem Menschen gekoppelte Sitzung herum gebaut, also genau die entgegengesetzte Form: geringe Parallelität, hohe Kontinuität, echter Nutzerkontext.
Bauen wir die Agent Runtime so, wie diese Seite sie beschreibt, wäre sie die richtige Antwort, wenn der Agent einen echten Betriebssystem-Desktop mit nativen Apps braucht, die tatsächlich installierte Software des Nutzers, seine echten Konten und Dateien und eine Sitzungsgrenze mit Human-in-the-Loop. Assistenz-Agenten, die für einen Nutzer mit Behinderung einen Desktop bedienen. KI-gestützte Qualitätssicherung an echten Betriebssystem-Apps. Agentische Workflows, die ein bestimmtes natives Werkzeug nutzen müssen, das dem Nutzer schon gehört. Jede Aufgabe, bei der „nutze meinen tatsächlichen Rechner mit allem, was darauf ist, während ich zusehe“ die natürliche Formulierung ist. Für diese Fälle wäre Remio — sobald es erscheint — die Runtime.
Häufige Fragen zur Agent Runtime, die wir entwerfen.
Fünf Fragen, die dieser Entwurf typischerweise aufwirft — ehrliche Antworten unten, auch dort, wo die ehrliche Antwort „noch nicht“ lautet.
Kann ich heute mit Claude, GPT oder einem anderen KI-Agenten meinen Computer über Remio steuern?
Könnte ein Agent von sich aus eine Remio-Sitzung starten, ohne einen Menschen?
Woran würde der Host erkennen, dass ein Agent statt eines Menschen verbunden ist?
Könnte ein Agent mehr sehen oder erreichen, als eine menschliche Sitzung es heute kann?
Welche KI-Modelle würden mit Remios Agent Runtime funktionieren?
Heute real: ein schneller, privater Desktop für Menschen. Eines Tages: auch für ihre Agenten.
Installieren Sie Remio für den schnellsten und privatesten Weg zu Ihrem eigenen Mac, PC oder Linux-Rechner — native Eingabe, nativer Bildschirmzugriff, Ende-zu-Ende-Verschlüsselung, kein Konto erforderlich. Die auf dieser Seite beschriebene Agent Runtime ist nicht erschienen, und wir versprechen keinen Termin — aber dieselbe Architektur ist genau der Grund, warum wir den Aufbau für lohnenswert halten.