Ein ständig aktiver persönlicher Agent sollte sich nicht wie ein Benachrichtigungsstrom mit besserer Grammatik verhalten. Seine Aufgabe ist nicht, auf jede neue E-Mail, jedes Issue, jede Preisänderung, jede Dokumentbearbeitung oder jede Kalenderänderung sichtbar zu reagieren. Seine Aufgabe ist, Wache zu halten, während der Nutzer anderswo ist, den kleinen Teil der Änderungen zu erkennen, der verändert, was als Nächstes geschehen sollte, und die richtige Arbeit zur richtigen Zeit und auf der richtigen Ebene wieder in den Blick zu rücken.
Damit wird „Wann sollte der Agent aufwachen?“ zu einer Designfrage, nicht bloß zu einer Frage der Leistung. Wacht er zu oft auf, wird der Agent zu einer weiteren Lärmquelle. Bleibt er zu konsequent still, verpasst er genau den Grund, aus dem er überhaupt Wache halten sollte. Handelt er ohne klare Grenze, wird aus einem nützlichen Hintergrundsystem ein Problem der Befugnisse.
Die richtige Antwort ist eine Abfolge von Entscheidungen. Ein neues Ereignis verdient vielleicht gar keine Reaktion, eine spätere Prüfung, einen Durchgang des Hauptagenten oder das direkte Urteil des Nutzers. Das sind verschiedene Ergebnisse, und ein vertrauenswürdiger Agent sollte sie nicht zu einem einzigen zusammenziehen.
Ständig aktiv sollte Kontinuität bedeuten, nicht Unterbrechung
„Ständig aktiv“ ist wertvoll, weil sich die Welt nicht in Chatsitzungen organisiert. Ein Pull Request kann fehlschlagen, nachdem der Laptop zugeklappt wurde. Ein Lieferant kann während eines Meetings einen Liefertermin verschieben. Ein Vertrag kann drei Tage nach dem letzten Gespräch darüber unterschrieben werden. Der Agent braucht Kontinuität über diese Lücken hinweg, wenn er eine fortlaufende Verantwortung tragen soll.
Kontinuität erfordert kein ständiges Nachdenken. Die meisten Ereignisse sind Duplikate, routinemäßige Bestätigungen, irrelevante Änderungen oder Informationen, die auch später noch nützlich sind. Für jedes Ereignis ein großes Modell zu wecken, verschwendet Rechenleistung, doch die größeren Kosten liegen im Verhalten: Wird jedes Aufwachen zu einer Nachricht, verbraucht der Agent die Aufmerksamkeit des Nutzers, als wäre sie kostenlos.
Forschung zu Benachrichtigungen am Arbeitsplatz stößt seit Langem auf dieselbe Spannung. Menschen schätzen es, passiv informiert zu sein, doch Benachrichtigungen stören die Aufgabe, auf die sie sich gerade konzentrieren. Forschung zum begrenzten Aufschub zeigt auch, warum „jetzt oder nie“ die falsche Wahl ist: Eine Benachrichtigung lässt sich innerhalb einer bekannten Grenze verzögern, sodass die Information erhalten bleibt, ohne jedes Eintreffen als dringend zu behandeln.
Ein ständig aktiver Agent sollte daher drei Uhren getrennt halten:
den Zeitpunkt, zu dem ein Ereignis eintrifft;
den Zeitpunkt, zu dem der Agent darüber nachdenken muss;
den Zeitpunkt, zu dem der Nutzer davon wissen oder entscheiden muss.
Manchmal fallen alle drei auf jetzt. Meistens nicht.
Aufwachen ist keine Benachrichtigung, und eine Benachrichtigung ist keine Erlaubnis
Die wichtigste Grenze wird leicht übersehen. Ein Ereignis erkennen, den Hauptagenten wecken, den Nutzer benachrichtigen und nach außen handeln sind vier getrennte Schritte.
Angenommen, Comma verfolgt einen Pull Request. Ein neuer Review-Kommentar trifft ein. Der Überwachungsprozess kann zuerst entscheiden, ob der Kommentar etwas Relevantes ändert. Wenn ja, kann der Hauptagent aufwachen und den Pull Request, die Diskussion drumherum und den Task, zu dem er gehört, prüfen. Vielleicht kann der Agent einen Entwurf aktualisieren oder eine Korrektur vorbereiten, ohne den Nutzer zu unterbrechen. Vielleicht muss er melden, dass das Fenster für den Merge gefährdet ist. Oder er stößt auf eine Entscheidung – etwa ob ein Sicherheitskompromiss akzeptiert wird –, die dem Nutzer zusteht.
Keine dieser Schlussfolgerungen ergibt sich allein aus dem Eintreffen des Kommentars.
Nach dieser Trennung soll die Architektur von Comma arbeiten. Ein leichtgewichtiger Loop hält Wache und weckt den Hauptagenten nur bei Bedarf; der Hauptagent übernimmt dann die Arbeit, die Kontext erfordert. Die technischen Details, darunter wie Loops Ereignisse filtern, doppeltes Aufwecken vermeiden und mit Kontingenten arbeiten, beschreibt Programmierbare Event-Loops für unser verteiltes Agent-Harness. Das Prinzip für Leser ist einfacher: Ein Ereignis ist ein Beleg, keine Anweisung, und ein Aufwachen ist eine Bitte, etwas zu untersuchen, keine Erlaubnis zu handeln.
Die vier Tests für das Wecken des Hauptagenten
Eine nützliche Weckregel lässt sich in vier Tests fassen. Sie sind keine Punktetabelle, bei der eine hohe Summe automatisch gewinnt. Jeder Test schließt eine andere Art von Fehlalarm aus.
1. Hat sich etwas wesentlich geändert?
Der erste Test betrifft den Zustand, nicht die Aktivität. Eine neue Nachricht ist Aktivität. Eine vorgezogene Frist, ein auftauchendes Hindernis, eine eingehende Freigabe oder eine zugesagte Bedingung, die eintritt, ist eine Zustandsänderung.
Der Agent sollte still bleiben, wenn das neue Ereignis wiederholt, was er schon weiß, eine Nachricht nur bestätigt, ohne den Plan zu ändern, oder außerhalb der Verantwortung liegt, die er überwachen soll. Stabile Kennungen und Deduplizierung helfen auf Systemebene, doch semantische Wiederholung braucht weiterhin Urteilsvermögen: Zwei verschiedene Nachrichten können dasselbe „nichts Neues“ mitteilen.
Dieser Test verhindert, dass Bewegung als Fortschritt durchgeht.
2. Berührt die Änderung ein aktives Ziel oder eine aktive Einschränkung?
Was wesentlich ist, hängt von der Person ab. Ein sinkender Flugpreis ist für sich genommen nicht wichtig; er zählt, wenn er unter das Budget fällt, das der Nutzer für eine Reise festgelegt hat, die er weiterhin antreten will. Ein fehlgeschlagener Build bedeutet auf einem aufgegebenen Branch, einem explorativen Branch und einem Release-Kandidaten jeweils etwas anderes.
Der Agent braucht das Ziel, den aktuellen Plan, die relevanten Einschränkungen und genug Herkunftsangaben, um zu wissen, woher diese Fakten stammen. Ohne diesen Kontext bedeutet „wichtig“ meist allgemein dramatisch statt konkret nützlich.
Hier schützt auch der Rahmen das Vertrauen. Ein Loop, der ein Repository verfolgt, sollte eine beiläufige Erwähnung eines anderen Projekts nicht in einen neuen Auftrag verwandeln. Eingehende Inhalte können die überwachte Verantwortung informieren; sie können sie nicht stillschweigend erweitern.
3. Gibt es ein Zeitfenster zum Handeln?
Manche Änderungen sind wichtig, verlangen aber nicht sofort Nachdenken. Ein Bericht, der am Freitag geprüft wird, kann in einer Zusammenfassung warten. Eine verspätete Lieferung wird vielleicht erst relevant, wenn sie ein davon abhängiges Ereignis gefährdet. Dagegen kann eine Meeting-Absage, die ein knappes Buchungsfenster freigibt, oder eine Regression in der Produktion, die immer mehr Nutzer trifft, mit jeder Minute Verzögerung an Wert verlieren.
Die Frage ist nicht einfach „Ist das dringend?“. Sie lautet: Würde Nachdenken jetzt eine bessere Option schaffen als Nachdenken später?
Wenn ja, wird der Hauptagent geweckt. Bleibt die Information später genauso brauchbar, wird sie auf einen natürlichen Kontrollpunkt verschoben oder mit verwandten Updates gebündelt. Ist keine Handlung möglich und ändert sich kein Plan, wird sie festgehalten, und der Agent bleibt still.
4. Wem gehört die nächste Entscheidung?
Hat der Hauptagent den Kontext gesammelt, sollte er bestimmen, wer die Befugnis für den nächsten Schritt hat.
Routinemäßige, umkehrbare Arbeit im Rahmen der Anweisungen des Nutzers kann oft ohne Unterbrechung weitergehen. Der Agent kann seine Task-Notizen aktualisieren, einen Vergleich vorbereiten oder eine Antwort entwerfen. Eine folgenreiche, mehrdeutige oder von Vorlieben abhängige Entscheidung sollte an den Nutzer zurückgehen. In Comma kann Arbeit, die eine menschliche Entscheidung braucht, in Prüfung nötig warten, statt erraten oder als erledigt markiert zu werden.
Gute Eskalation ist konkret. Sie sagt, was sich geändert hat, warum das den Plan ändert, was der Agent bereits geprüft hat, welche Entscheidung nötig ist und ab wann sie nicht mehr nützt. „Was soll ich tun?“ ist keine Übergabe, sondern eine unfertige Analyse.
Vier legitime Ergebnisse – nicht nur wach oder schlafend
Nach den Tests hat der Agent vier nützliche Reaktionen.
Still bleiben. Nichts Relevantes hat sich geändert, das Ereignis ist ein Duplikat, oder es liegt außerhalb der Überwachung. Stille sollte eine bewusste Schlussfolgerung mit genug interner Spur zur Fehleranalyse sein – nicht das Ausbleiben jeder Verarbeitung.
Aufschieben oder bündeln. Die Änderung ist relevant, ihr Wert übersteht aber eine Verzögerung. Sie kommt in den nächsten Task-Kontrollpunkt, ein Briefing oder eine kompakte Zusammenfassung. Aufschub braucht eine Grenze: „Später“ sollte einen bekannten Zeitpunkt oder eine bekannte Bedingung meinen, keinen herrenlosen Rückstau.
Den Hauptagenten wecken. Das Ereignis könnte den Plan ändern, braucht breiteren Kontext oder ist für den leichtgewichtigen Filter zu unsicher. Aufwecken ist auch dann angemessen, wenn das Endergebnis Stille ist; der Hauptagent kann nachforschen und zu dem Schluss kommen, dass keine Nachricht an den Nutzer nötig ist.
Die Kontrolle an den Nutzer zurückgeben. Der Agent ist bei einer Entscheidung angekommen, die Befugnis, Risiko, Geschmack oder eine Abwägung betrifft, die nur der Nutzer treffen kann. Er sollte die bereits geleistete Arbeit bewahren und die kleinste Entscheidung vorlegen, die den Fortschritt freigibt.
Dieses Modell mit vier Ausgängen macht Unsicherheit handhabbar. Ein Überwachungsprozess muss keine Gewissheit vortäuschen, wenn die Belege schwach sind. Er kann den Hauptagenten für eine gründlichere Prüfung wecken. Der Hauptagent wiederum muss keine Autonomie erfinden, wenn eine Entscheidung dem Nutzer gehört.
Konfidenz sollte den Weg ändern, nicht das Ereignis verstecken
Ein ständig aktives System wird sich manchmal irren. Der gefährliche Fehler ist nicht bloß ein Fehlalarm, sondern ein mit Gewissheit unterdrücktes Ereignis, das der Nutzer nie mehr zurückholen kann.
Die Grundhaltung von Comma spiegelt diese Asymmetrie wider. Wenn Loops mit Jev einen verfolgten Pull Request, ein Issue oder einen Thread prüfen, erfordert „still bleiben“ hohe Konfidenz. Unsicherheit und Fehler gehen an den Hauptagenten, der angewiesen ist, die Quelle zu prüfen, bevor er dem Nutzer schreibt. Jev kann klassifizieren; es kann keine Nachrichten senden, keinen externen Zustand ändern und sich keinen weiteren Zugriff verschaffen. Das aktuelle Verhalten und die Grenzen sind in Salix, das Agent-Harness von Comma und in der Loops-Dokumentation beschrieben.
Dieses Design beseitigt keine Fehler. Eine selbstsichere, aber falsche Entscheidung zum Stillbleiben kann weiterhin ein Update verbergen. Es legt Unsicherheit jedoch auf den sichereren Weg: gründlichere Prüfung statt stilles Verwerfen. Nutzer sollten außerdem eine Überwachung pausieren oder löschen, ihren Rahmen einengen und operativen Zugriff zurücknehmen können. Ein Agent verdient sich das Recht, im Hintergrund präsent zu sein, indem er diese Präsenz überprüfbar und umkehrbar macht.
Eine gute Unterbrechung kommt mit bereits erledigter Arbeit
Der Wert eines ständig aktiven persönlichen Agenten liegt nicht darin, etwas früher zu bemerken. Das leisten Monitoring-Werkzeuge längst. Der Wert liegt darin, die Änderung mit einer aktiven Verantwortung zu verbinden und den Aufwand für den Nutzer zu verringern.
Eine nützliche Unterbrechung könnte inhaltlich so lauten:
Der Reviewer hat eine Änderung am Authentifizierungsablauf verlangt. Das blockiert das Release-Kriterium für Donnerstag. Der aktuelle Branch ist geprüft und das Problem reproduziert. Patch und Tests liegen bereit; die einzige Entscheidung, die vor dem Anwenden noch fehlt, ist die Freigabe des Kompatibilitätskompromisses.
Diese Nachricht enthält Kontext, Folgen, abgeschlossene Untersuchung, einen vorgeschlagenen nächsten Schritt und eine klare Entscheidungsgrenze. Sie verlangt nicht, selbst zu rekonstruieren, warum das Ereignis wichtig ist. Sie verwechselt auch keinen plausiblen nächsten Schritt mit der Befugnis, ihn auszuführen.
Derselbe Maßstab gilt, wenn der Agent sich entscheidet, nicht zu unterbrechen. Ein aufgeschobenes Update sollte am zugesagten Kontrollpunkt wieder auftauchen. Eine Entscheidung zum Stillbleiben sollte nachvollziehbar bleiben. Ein Task, der ein Urteil braucht, sollte sichtbar warten und nicht in einer endlosen Unterhaltung verschwinden.
Das Ziel ist ruhige Kontinuität
Ein ständig aktiver Agent sollte Kontinuität schaffen, ohne ständige Aufmerksamkeit zu verlangen. Das äußere System überwacht kostengünstig und eng begrenzt. Der Hauptagent wacht auf, wenn eine Änderung den Plan verändern könnte. Er untersucht, bevor er unterbricht. Routinemäßige, umkehrbare Arbeit setzt er fort, wenn der Nutzer die Befugnis bereits erteilt hat, und folgenreiche Entscheidungen gibt er mit der relevanten Arbeit zurück.
Das Ergebnis ist kein Agent, der mehr redet. Es ist ein Agent, der verantwortlich bleiben kann, während er still ist – und genau weiß, wann Stille nicht mehr nützt.
Häufige Fragen
Was läuft, bevor der Hauptagent aufwacht?
In Comma überwacht ein leichtgewichtiger Loop den gewählten Posteingang, das Repository, den Feed, die API oder den Webhook. Sein Programm kann deterministische Regeln anwenden und Jev um eine schnelle, typisierte Entscheidung bitten. Der Hauptagent und sein größerer Kontext laufen nur, wenn der Loop zum Aufwachen für eine tiefere Untersuchung oder Handlung auffordert.
Sollte jedes Aufwachen des Agenten zu einer Benachrichtigung werden?
Nein. Das Aufwachen erlaubt dem Hauptagenten, den Kontext zu prüfen und zu entscheiden, was das Ereignis ändert. Er kann die Arbeit im Hintergrund fortsetzen, ein Update aufschieben oder zu dem Schluss kommen, dass der Nutzer nicht unterbrochen werden muss. Die Aufmerksamkeit des Nutzers sollte nur beansprucht werden, wenn Information oder Entscheidung zeitkritisch ist.
Was sollte passieren, wenn der Agent unsicher ist?
Unsicherheit sollte das Ereignis an eine fähigere Entscheidungsinstanz weitergeben. Ein leichtgewichtiger Filter kann den Hauptagenten wecken; der Hauptagent kann die Quelle prüfen, Kontext sammeln und entweder im Rahmen seiner Befugnis weitermachen oder den Nutzer fragen. Unsicherheit sollte weder in eine selbstsichere Entscheidung zum Stillbleiben noch in eine nicht autorisierte Handlung umgewandelt werden.
Wie lässt sich eine ständige Überwachung stoppen?
Comma lässt sich bitten, einen Loop zu pausieren oder zu löschen. Der Zugriff auf verbundene Computer lässt sich durch das Deaktivieren von Operationen auch wieder auf schreibgeschützt setzen. Eine ständige Verantwortung sollte immer einen verständlichen Rahmen, einen sichtbaren Zustand und einen praktischen Ausschalter haben.
Aus einem Signal einen nützlichen nächsten Schritt machen
Am besten mit einer einzigen Ereignisquelle beginnen und festhalten, was den eigenen Plan wesentlich ändern würde, wie lange das Zeitfenster zum Handeln offen bleibt und welche Entscheidung beim Menschen bleiben muss. Der Agent von Comma zeigt, wie proaktive Aufmerksamkeit mit Tasks und Prüfung zusammenhängt; die Loops-Dokumentation beschreibt das aktuelle Überwachungsmodell und seine Grenzen.
