--- title: "Was ist ein Always-on-KI-Agent? · Comma-Blog" description: "Was einen KI-Agenten wirklich always-on macht: dauerhafter Zustand, ereignisgesteuerte Aufmerksamkeit, wiederherstellbare Ausführung und Kontrolle durch den Nutzer. So funktioniert Comma." url: https://comma.surf/de/blog/what-is-an-always-on-ai-agent language: de --- [Zurück zum Blog](https://comma.surf/de/blog) Comma Team · 28. Oktober 2026 · 11 Min. Lesezeit # Was ist ein Always-on-KI-Agent? Was einen KI-Agenten wirklich always-on macht: dauerhafter Zustand, ereignisgesteuerte Aufmerksamkeit, wiederherstellbare Ausführung und Kontrolle durch den Nutzer. So funktioniert Comma. [Loslegen](https://app.comma.surf/) [Dokumentation lesen](https://comma.surf/de/docs/agent) Ein Always-on-KI-Agent ist ein Agent, der für Arbeit verantwortlich bleiben kann, auch wenn kein Gespräch geöffnet ist. Er kann den Stand eines Auftrags bewahren, darauf warten, dass Zeit vergeht oder sich die Außenwelt ändert, in einer passenden Umgebung weitermachen und die Kontrolle zurückgeben, wenn die nächste Entscheidung bei einem Menschen liegt. „Always-on“ heißt **nicht**, dass ein großes Sprachmodell ununterbrochen nachdenkt. Es heißt nicht, dass ein Computer rund um die Uhr unter Volllast Ressourcen verbrauchen muss. Und es sollte nicht heißen, dass ein Agent ständig Nachrichten schickt oder ohne Erlaubnis handelt. Das nützliche Versprechen ist Kontinuität: Die Verantwortung bleibt lebendig, auch wenn der größte Teil des Systems schläft. Einen Prompt zu planen oder einen Chatverlauf aufzubewahren, beantwortet die praktischen Fragen nicht: Was übersteht einen Neustart? Was weckt den Agenten? Wo arbeitet er weiter? Und wie kann ein Nutzer ihn anhalten? Erst die Antworten auf diese Fragen machen aus „24/7“ statt eines Slogans eine Eigenschaft des Systems. ## Always-on bedeutet Kontinuität, nicht Betriebszeit Betriebszeit beschreibt, ob ein Prozess läuft. Kontinuität beschreibt, ob die Arbeit noch einen Verantwortlichen und einen gültigen nächsten Schritt hat. Angenommen, ein Agent soll auf einen unterschriebenen Vertrag warten, bei dessen Eingang eine Launch-Checkliste aktualisieren und die nächste Entscheidung vorbereiten. Der Vertrag kann morgen zurückkommen oder nächste Woche. Während dieses Wartens findet kein nützliches Schlussfolgern statt. Der Agent braucht keinen offenen Chat, keine warmgehaltene Modellsitzung und keinen Browser, der jede Minute das Postfach neu lädt. Er braucht eine dauerhafte Aufzeichnung der Verantwortung und einen verlässlichen Weg, auf dem das relevante Ereignis diese Verantwortung wieder in Bewegung setzt. Der Unterschied wird bei einem Ausfall offensichtlich. Ein Prozess kann ununterbrochen laufen und den Auftrag trotzdem nach einem Absturz verlieren. Ein anderes System kann stundenlang auf null herunterskalieren, dann seinen Zustand wiederherstellen und korrekt weitermachen, sobald ein Ereignis eintrifft. Das zweite System ist im eigentlichen Sinn always-on. Deshalb trennt die Infrastruktur für dauerhafte Agenten das Warten vom Rechnen. Die aktuelle [Durable Extension für Agent Framework](https://learn.microsoft.com/en-us/agent-framework/hosting/durable-extension) von Microsoft beschreibt etwa Agenten, die ihren Zustand über Worker-Ausführungen hinweg bewahren, pausieren, ohne Rechenleistung oder Modell-Tokens zu verbrauchen, und durch externe Ereignisse fortgesetzt werden. Googles Leitfaden zu [lang laufenden Agenten mit ereignisgesteuerter Fortsetzung](https://developers.googleblog.com/build-long-running-ai-agents-that-pause-resume-and-never-lose-context-with-adk/) zeigt dasselbe Prinzip mit dauerhaften Checkpoints und Webhooks. Die Implementierungsdetails unterscheiden sich, die Lehre für die Architektur bleibt: Eine Verantwortung, die always-on ist, braucht kein Modell, das immer läuft. ## Die sechs Bedingungen hinter einem glaubwürdigen Always-on-Agenten Es gibt keine einzelne Funktion, die einen Agenten always-on macht. Die Eigenschaft entsteht, wenn sechs Bedingungen zusammenwirken. ### Eine fortlaufende Identität trägt die Verantwortung Das System braucht eine stabile Identität, an die sich Nachrichten, Ereignisse, Rechte, Aufgaben und Erwartungen des Nutzers knüpfen lassen. Erzeugt jedes Gespräch einen unabhängigen Agenten ohne gemeinsamen Betriebskontext, gibt es niemanden, den spätere Ereignisse wecken könnten, und niemanden, der für das Weiterführen der Arbeit verantwortlich ist. Eine fortlaufende Identität verlangt kein unbegrenztes Gedächtnis. Sie bedeutet, dass der Nutzer zum selben Agenten zurückkehren kann und das System weiß, welche Verantwortungen zu ihm gehören. Persönliche Fakten, Gesprächsverlauf und Aufgabenstand können weiterhin unterschiedliche Lebensdauern und Kontrollen haben. ### Der Arbeitsstand übersteht Leerlauf Ein Auftrag muss mehr bewahren als seinen ersten Prompt. Zum Stand, der zum Weitermachen nötig ist, können das angestrebte Ergebnis gehören, erledigte Aktionen, Arbeitsergebnisse, Einschränkungen, das aktuelle Hindernis und der nächste gültige Schritt. Dieser Stand sollte dauerhaft genug sein, um gewöhnliche Unterbrechungen zu überstehen: einen geschlossenen Browser, einen Computer im Ruhezustand, ein ausgerolltes Update, einen Neustart des Workers oder mehrere vergangene Tage. Ein Protokoll kann helfen, das Geschehene zu rekonstruieren, aber Rekonstruktion ist nicht dasselbe wie Wiederherstellung. Ein glaubwürdiges System weiß, welcher Stand maßgeblich ist, statt bei jedem Aufwachen ein Modell die Wahrheit aus einem langen Gespräch erschließen zu lassen. Der tiefere Mechanismus, um einen Auftrag über Abhängigkeiten hinweg zu tragen, ist eine andere Frage als die Definition der Kategorie. Auf dieser Ebene ist der Test einfacher: Kann das System genug gültigen Stand bewahren, um ohne neues Briefing weiterzumachen? ### Zeit und Ereignisse finden wieder ins System Arbeit in der Außenwelt kommt nicht nur voran, wenn ein Nutzer eine Nachricht schickt. Fristen laufen ab. Dateien ändern sich. Antworten treffen ein. Ein Gerät kommt wieder online. Eine Freigabe wird in einer anderen Anwendung erfasst. Ein Always-on-Agent braucht deshalb mehr als ein interaktives Eingabefeld. Er braucht einen Weg, auf dem ein Timer oder ein externes Ereignis die Verantwortung erreicht, die es betrifft. Dieser Weg kann ein Webhook sein, eine Nachrichtenwarteschlange, ein Zeitplan, ein Connector oder ein eng begrenzter Überwachungsprozess. Entscheidend ist, dass sich das Ereignis dem richtigen Agenten und dem richtigen Stand zuordnen lässt. Das heißt nicht, dass jedes Ereignis einen vollständigen Durchlauf des Schlussfolgerns verdient. Ereignisgesteuerter Betrieb ist gerade deshalb wertvoll, weil der größte Teil des Systems still bleiben kann, bis es Arbeit zu bewerten gibt. Zu entscheiden, ob ein bestimmtes Ereignis den Hauptagenten wecken sollte – und ob dieses Aufwachen einen Menschen unterbrechen sollte –, ist eine eigene Frage der Richtlinien, getrennt von der Definition des Always-on-Systems selbst. ### Beim Weitermachen ist eine Ausführungsumgebung verfügbar Sich an den nächsten Schritt zu erinnern, reicht nicht, wenn der Agent keinen Ort hat, ihn auszuführen. Manche Arbeit lässt sich über eine API erledigen. Andere braucht einen Browser, einen Cloud-Computer, einen lokalen Rechner oder eine spezialisierte Agenten-Laufzeitumgebung. Die Umgebung muss verfügbar sein, wenn die Verantwortung wieder aktiv wird, mit den Dateien, Werkzeugen und Rechten, die der nächste Schritt verlangt. „Verfügbar“ heißt nicht, dass sie ständig läuft. Ein Cloud-Computer kann schlafen, während sein Speicher erhalten bleibt, und bei Bedarf aufwachen. Ein lokaler Rechner kann getrennt bleiben, bis eine Aufgabe ihn braucht. Entscheidend ist, dass der Agent die benötigte Umgebung erkennt und ehrlich damit umgeht, wenn sie fehlt. Die Grenzen der Umgebung gehören auch zur Korrektheit. Die [Gerätedokumentation](https://comma.surf/de/docs/salix/devices) von Comma hält fest, dass Salix Arbeit nicht stillschweigend von einem Offline-Gerät auf einen anderen Computer verlagert. Die Anfrage kann scheitern und wiederholt werden, sobald das Gerät zurück ist. Das ist weniger magisch, als so zu tun, als wäre jeder Computer austauschbar, bewahrt aber Ort, Zugriff und Ausführungsbedingungen, von denen die Arbeit abhängt. ### Wiederherstellung gehört zum normalen Betrieb Ein Always-on-System wird irgendwann auf einen Neustart treffen, auf ein doppeltes Ereignis, einen nicht verfügbaren Dienst, abgelaufene Zugangsdaten oder eine unterbrochene Verbindung. Zuverlässigkeit kann deshalb nicht davon abhängen, dass ein Prozess für immer fehlerfrei bleibt. Das System braucht einen Weg zur Wiederherstellung: dauerhaften Zustand, Checkpoints oder eine gleichwertige verlässliche Quelle; Wiederholungsversuche mit Obergrenze; einen Weg, eine externe Aktion nicht doppelt auszuführen; und einen sichtbaren Fehlerzustand, wenn eine automatische Wiederherstellung nicht mehr sicher ist. Ein Neustart, der stillschweigend vergisst, was bereits bestätigt war, ist keine Wiederherstellung. Eine endlose Wiederholungsschleife, die Ressourcen verbraucht, ohne das Ergebnis zu ändern, ebenso wenig. Die [Loops-Dokumentation](https://comma.surf/de/docs/salix/loops) von Comma liefert ein konkretes Beispiel. Ein Loop kann einen Checkpoint speichern und ihn beim nächsten Start zurückerhalten. Nach einem Fehler startet Salix ihn im Rahmen einer begrenzten Wiederholungsrichtlinie von diesem Checkpoint neu; wiederholtes Scheitern hält den Loop an und informiert den Agenten. Die vollständige Implementierung, einschließlich dauerhafter Ereignisse, Deduplizierung, Platzierung und Grenzen der Fähigkeiten, erklärt [Programmierbare Event-Loops für unser verteiltes Agent-Harness](https://comma.surf/de/blog/agent-programmable-event-loops). Bei der Bewertung eines Produkts lohnt die Prüfung, ob Unterbrechung und Wiederherstellung geplante Zustände sind und keine Überraschungen. ### Der Nutzer kann die Kontinuität sehen und begrenzen Beständigkeit macht Kontrolle wichtiger. Ein einmaliger Chat endet von selbst. Eine Verantwortung im Hintergrund braucht einen verständlichen Umfang, einen sichtbaren Status und einen Ausschalter, der wirklich funktioniert. Nutzer sollten erkennen können, wofür der Agent verantwortlich ist, welche Quellen er beobachtet, welche Umgebung er nutzen darf und welche Befugnis er dort hat. Sie sollten die Verantwortung pausieren oder beenden, Zugriff widerrufen und bereits erzeugte Arbeit zurückholen können. Das System sollte Fehler und folgenreiche Entscheidungen sichtbar machen, statt Stille als Beleg dafür zu nehmen, dass alles in Ordnung ist. Deshalb sind always-on und autonom auch keine Synonyme. Beständigkeit sagt, dass das System verfügbar bleiben kann. Autonomie beschreibt, welche Entscheidungen oder Handlungen es ohne Rückfrage treffen darf. Ein Agent kann sehr beständig und bewusst zurückhaltend sein: Er kann vorbereiten, prüfen, ordnen und warten und dabei externe Zusagen oder unumkehrbare Entscheidungen an den Nutzer zurückgeben. ## Vier Betriebsmodi statt eines endlosen Laufs Der Ausdruck „always-on“ legt eine einzige, ununterbrochene Tätigkeit nahe. In der Praxis wechselt ein nützlicher Agent zwischen verschiedenen Modi. Er kann **arbeiten**, während ein Modell und Werkzeuge einen Auftrag aktiv voranbringen. Er kann **warten**, weil ein Zeitpunkt, ein Ereignis, eine Umgebung oder eine menschliche Entscheidung noch nicht eingetroffen ist. Ein leichtgewichtiger Beobachter kann eine enge Bedingung **überwachen**, ohne den Hauptagenten zu wecken. Oder die Verantwortung kann **angehalten** sein, weil der Nutzer sie beendet hat oder ein Fehler die sichere Wiederherstellungsrichtlinie überschritten hat. Diese Modi sind für Kosten und Aufmerksamkeit genauso wichtig wie für Zuverlässigkeit. Modellinferenz, Cloud-Rechenleistung, Ereigniseingang, Speicher und Drittanbieter-APIs können unterschiedlich abgerechnet werden. Ein Produkt sollte sie nicht zu einer pauschalen Aussage wie „der Agent läuft 24/7“ zusammenfassen. Eine ruhige Hintergrundverantwortung kann Speicher und Überwachungsressourcen nutzen, ohne ein einziges Token eines großen Modells zu verbrauchen; ein aktiver Task kann sowohl Modell- als auch Rechenressourcen verbrauchen; eine angehaltene Verantwortung sollte über den gespeicherten Zustand hinaus keines von beiden verbrauchen. Comma bildet diese Trennung in der eigenen Laufzeitumgebung ab. [Salix](https://comma.surf/de/docs/salix) betreibt den Agenten außerhalb einer dauerhaft warmgehaltenen Sandbox. Wird Arbeit am Computer nötig, kann es eine virtuelle Maschine in der Cloud wecken, deren Speicher zwischen den Einsätzen erhalten bleibt. Für fortlaufende Aufmerksamkeit können kleine Loops Ereignisse beobachten, ohne die Hauptschleife des Agenten aktiv zu halten. Nur wenn ein Loop feststellt, dass der Agent gebraucht wird, läuft die Hauptschleife. Diese Architektur ist die Implementierung von Comma, keine allgemeingültige Definition. Ein anderes Produkt nutzt vielleicht dauerhafte Workflows, Warteschlangen, Serverless-Funktionen oder lang laufende Worker. Der Test ist, ob das gesamte System die Verantwortung über Leerlaufphasen hinweg bewahrt, nicht, ob es eine bestimmte Laufzeitumgebung verwendet. ## Always-on, geplant und lang laufend sind verschiedene Versprechen Eine geplante Automatisierung führt eine Anweisung zu einem bekannten Zeitpunkt aus. Sie kann äußerst nützlich sein, ohne eine fortlaufende Agentenidentität zu pflegen oder auf ungeplante Änderungen zu reagieren. Erstellt ein täglicher Job einen Bericht aus festen Eingaben, braucht das System vielleicht nur einen Zeitplan. Ein lang laufender Workflow kann seinen Zustand über mehrere Schritte bewahren und auf ein Signal warten. Agentisch wird er, wenn Modelle daran beteiligt sind, Informationen zu deuten, Werkzeuge zu wählen oder den Plan anzupassen. Always-on im eigentlichen Sinn wird er, wenn dieser dauerhafte Workflow zu einem fortlaufenden Agenten gehört, der neue relevante Ereignisse empfangen und innerhalb vom Nutzer gesteuerter Grenzen handeln kann. Auch ein Chatbot kann sich an frühere Gespräche erinnern und Erinnerungen anbieten. Solche Funktionen verbessern die Kontinuität für den Nutzer, beweisen für sich genommen aber nicht, dass Arbeit außerhalb des Chats fortbesteht. Die entscheidende Frage ist nicht, ob sich das System etwas über einen Menschen merkt. Sondern, ob eine aktive Verantwortung warten, weitermachen, sich erholen und eine freigegebene Umgebung erreichen kann, ohne von Hand neu angelegt zu werden. Diese Unterscheidung verhindert auch, zu viel zu bauen. Nicht jede Anfrage braucht einen Always-on-Agenten. Eine einmalige Erklärung, Umformulierung, Berechnung oder ein Brainstorming ist oft mit einem interaktiven Modell besser bedient. Always-on-Betrieb rechtfertigt seine Komplexität dann, wenn das Ergebnis von Zeit, äußeren Veränderungen, mehreren Arbeitsumgebungen oder einer Verantwortung abhängt, die nach dem aktuellen Gespräch offen bleibt. ## Ein praktischer Kontinuitätstest Um ein „Always-on“-Produkt zu bewerten, eignet sich eine realistische Verantwortung, die eine Wartezeit enthält. Das Produkt soll eine festgelegte Bedingung überwachen, den nächsten Schritt vorbereiten und vor einer folgenreichen Aktion anhalten. Dann lohnt der Blick darauf, was das Produkt zeigen kann. Wo wird der Auftrag gespeichert, wenn die Oberfläche geschlossen ist? Welche Bedingung genau setzt ihn wieder in Gang? Weiß es, welche Umgebung das Arbeitsmaterial enthält? Kann es nach einem Neustart weitermachen, ohne erledigte Aktionen zu wiederholen? Was passiert, wenn das Ereignis doppelt eintrifft oder das benötigte Gerät offline ist? Lässt sich die Überwachung pausieren, der Zugriff widerrufen oder der Auftrag beenden, ohne den gesamten Verlauf zu löschen? Schließlich zählt, was beim Menschen ankommt. Ein System, das jedes Ereignis weiterleitet, hat eine Benachrichtigungspipeline gebaut, nicht unbedingt einen Agenten. Ein System, das auf jedes Ereignis reagiert, verwechselt Verfügbarkeit mit Befugnis. Ein nützlicher Always-on-Agent verknüpft eine Änderung mit einer bestehenden Verantwortung, erledigt die bereits erlaubte Arbeit und bittet nur dann um Aufmerksamkeit, wenn diese Aufmerksamkeit das Ergebnis verändert. ## Wie Comma verfügbar bleibt, ohne laut zu werden [Comma](https://comma.surf/de/) ist ein kostenloser Open-Source-Agent für persönliche Arbeit, gebaut um einen einzigen fortlaufenden Agenten über Gespräche und Geräte hinweg. Kurze Fragen können im Chat bleiben, größere Verantwortungen werden zu Tasks. Comma kann in verbundenen Apps und Dateien arbeiten, auf einem angebundenen Mac oder Linux-Gerät oder auf einem Cloud-Computer, der bei Bedarf aufwacht. Die Always-on-Schicht ist Salix. Ein Comma-Agent kann einen Loop anlegen, der eine begrenzte Quelle beobachtet, etwa ein Postfach, ein Repository, einen Feed, eine API oder einen Webhook. Der Loop läuft getrennt von der Hauptschleife des Schlussfolgerns, kann einen kleinen Checkpoint pflegen und den Agenten benachrichtigen, wenn Arbeit ansteht. Weil der Hauptagent nicht jede ruhige Phase prüfen muss, wird aus „immer verfügbar“ nicht „verbraucht ständig Modell-Tokens“. Ein Loop kann trotzdem ein schnelles Entscheidungsmodell oder einen anderen Dienst aufrufen, Hintergrundarbeit ist also nicht automatisch kostenlos; die Kosten hängen davon ab, was der Loop tatsächlich tut. Dieselbe Kontinuität bleibt der Kontrolle des Nutzers unterworfen. Angebundene Computer starten nur lesend, bis der Nutzer Aktionen erlaubt, und der Gerätezugriff lässt sich widerrufen. Loops haben Grenzen für Fähigkeiten und Aufwachen. Ein größerer Task kann auf **Prüfung nötig** zurückgehen, wenn eine Entscheidung beim Menschen liegt. Comma lässt sich auch [selbst hosten](https://comma.surf/de/self-host), dann ist allerdings der Betreiber für Verfügbarkeit, Upgrades, Backups, Modellkonfiguration und die übrige Infrastruktur zuständig, die diese Instanz am Laufen hält. Der Ansatz von Comma ist eine Antwort auf das Kernproblem der Kategorie: die Verantwortung fortbestehen zu lassen, während teure Rechenleistung, Modelle und die Aufmerksamkeit des Nutzers ruhen dürfen, bis sie tatsächlich gebraucht werden. ## Häufige Fragen ### Lässt ein Always-on-KI-Agent ein Modell rund um die Uhr laufen? Nein. Ein gut gestaltetes System kann seinen Zustand bewahren und auf Timer oder Ereignisse warten, während das Hauptmodell inaktiv ist. Das Modell läuft, wenn das System schlussfolgern oder etwas erzeugen muss. Leichtgewichtige Überwachung, Speicher und externe Dienste können trotzdem Ressourcen verbrauchen, während der Agent wartet. ### Ist ein Always-on-Agent dasselbe wie ein autonomer Agent? Nein. Always-on beschreibt Kontinuität und Verfügbarkeit über die Zeit. Autonomie beschreibt, was der Agent ohne menschliche Zustimmung entscheiden oder tun darf. Ein Always-on-Agent kann mit eng gefasster Befugnis arbeiten und folgenreiche Entscheidungen an den Nutzer zurückgeben. ### Ist eine geplante KI-Aufgabe ein Always-on-Agent? Nicht unbedingt. Ein Zeitplan kann zu einer festen Zeit einen zustandslosen Prompt starten. Ein Always-on-Agent bewahrt zusätzlich die Verantwortung und den relevanten Stand, kann auf passende externe Ereignisse reagieren, erholt sich von Unterbrechungen und arbeitet innerhalb dauerhafter Nutzerkontrollen weiter. ### Muss der Computer des Agenten eingeschaltet bleiben? Das hängt von der benötigten Umgebung ab. Arbeit in der Cloud oder auf dem Server kann weiterlaufen, während ein persönlicher Laptop zugeklappt ist. Arbeit, die von Dateien oder Anwendungen abhängt, die nur auf einem bestimmten lokalen Gerät verfügbar sind, muss auf dieses Gerät warten. Manche Cloud-Umgebungen können zwischen Aktionen schlafen und ihren Speicher behalten. ### Was passiert, wenn ein Always-on-Agent ausfällt? Das System sollte von einem bekannten Checkpoint oder dauerhaften Zustand aus weitermachen, bereits erledigte externe Aktionen nicht wiederholen und Wiederholungsversuche begrenzen. Kann es sich nicht sicher erholen, sollte es sichtbar anhalten und dem Agenten oder Nutzer mitteilen, was fehlgeschlagen ist, statt endlos zu wiederholen oder die Verantwortung stillschweigend aufzugeben. ### Lässt sich ein Always-on-Agent abschalten? Eine Hintergrundverantwortung sollte sich pausieren oder beenden lassen, und der Zugriff, den sie nutzt, sollte sich widerrufen lassen. „Always-on“ sollte heißen: verfügbar, wenn freigegeben, nicht unmöglich anzuhalten. In Comma lassen sich [Loops pausieren oder löschen](https://comma.surf/de/agent), und der Zugriff auf verbundene Geräte lässt sich widerrufen. ## Der Agent darf schlafen; die Verantwortung darf nicht verschwinden Ein Always-on-KI-Agent definiert sich nicht durch ununterbrochene Modellaktivität. Er definiert sich durch eine ununterbrochene Kette der Verantwortung: einen stabilen Verantwortlichen, dauerhaften Zustand, einen Weg, auf dem Zeit und Ereignisse zählen, eine verfügbare Ausführungsumgebung, wiederherstellbaren Betrieb und Kontrollen, die beim Nutzer bleiben. Wenn diese Teile vorhanden sind, kann der größte Teil des Systems die meiste Zeit still sein. Das Modell kann anhalten. Der Cloud-Computer kann schlafen. Der Nutzer kann die App schließen. Die Arbeit geht weiter, weil die Verantwortung noch intakt ist – nicht, weil jemand daran gedacht hat, „weiter“ zu tippen. [So betreibt Comma einen einzigen fortlaufenden persönlichen Agenten über Tasks, Geräte und Loops im Hintergrund](https://comma.surf/de/docs/agent). Persönliche Agenten [Zurück zum Blog](https://comma.surf/de/blog) Teilen ## Ähnliche Beiträge 27. Oktober 2026 ### [Persönlicher Agent oder KI-Assistent: Was ist der Unterschied?](https://comma.surf/de/blog/personal-agent-vs-ai-assistant) 26. Oktober 2026 ### [Was ist ein persönlicher Agent? Die KI, die weiterarbeitet](https://comma.surf/de/blog/what-is-a-personal-agent) 28. Oktober 2026 ### [iPhone-Fotos bleiben lokal, Comma findet sie](https://comma.surf/de/blog/local-iphone-photo-search) ## Try Comma, Now. [Loslegen](https://app.comma.surf/)