CLS

CLS steht für Closed-Loop System. Nova behandelt Browser-Aktionen damit als prüfbare Zustandsübergänge: Eine Handlung ist nicht verlässlich, nur weil ein Klick, eine Eingabe oder ein Submit abgeschickt wurde.

CLS gehört zu Momenten, in denen ein Agent Seitenzustand verändert. Nova kann Voraussetzungen prüfen, die Handlung ausführen, das Ergebnis beobachten und melden, ob die erwartete Nachbedingung bestätigt, widerlegt oder noch unklar ist.

Das verhindert falschen Erfolg. Wenn die Seite das gewünschte Ergebnis bestätigt, kann der Agent vom neuen Zustand aus weiterarbeiten. Wenn ein Fehler sichtbar wird, das Ergebnis unklar bleibt oder die Handlung die Seite nie erreicht hat, muss der nächste Schritt reparieren, erneut beobachten oder sicher stoppen.

CLS verbindet Ausführung mit Gedächtnis. TOB liefert beobachtete Evidenz, OK liefert aktuelle Dienstfakten, PKS kann aus verifizierten Erfolgen und Fehlschlägen lernen, und ETM kann das Ergebnis nutzen, wenn ein Aufgabenlauf wirklich abgeschlossen werden soll.

Kurz gesagt

• Dispatch ist kein Beweis, dass eine Browser-Aktion erfolgreich war.
• Commit-Point-Handlungen brauchen Voraussetzungen und Nachbedingungen, wenn sie senden, absenden, einloggen, Zustand wechseln oder einen Dienst verändern.
• CLS trennt Pre-Dispatch-Blocks von Unklarheit nach Dispatch, damit Agenten riskante Handlungen nicht blind wiederholen.
• Verifizierte Ergebnisse können Aufgabenfortschritt, PKS-Health, ALP-Prüfung und spätere Orientierung stützen.
• CLS erteilt keine Erlaubnis von allein; Nova-Sicherheitsgates und Nutzerkontrolle gelten weiter.

Was CLS prüft

CLS prüft die Teile einer Handlung, die leicht verwechselt werden, wenn ein Agent nur den Werkzeugerfolg sieht.

1. Voraussetzungen Vor Dispatch muss die aktuelle Seite noch zum erwarteten Ausgangszustand passen. Wenn die Voraussetzung nicht stimmt, soll die Handlung nicht laufen.
2. Dispatch Nova meldet, ob die Handlung die Seite wirklich erreicht hat. Ein Block vor Dispatch ist etwas anderes als ein Klick, der ausgelöst wurde, aber nicht das erwartete Ergebnis erzeugt hat.
3. Nachbedingungen Nach Dispatch prüft Nova Erfolgs-, Fehler- und Ambiguitätssignale. Hier wird aus „gesendet“ entweder „bestätigt“, „fehlgeschlagen“ oder „unklar“.
4. Retry-Sicherheit CLS sagt dem Agenten, ob er wiederholen darf, nicht wiederholen soll oder zuerst die Nachbedingung prüfen muss, weil eine Wiederholung die Handlung doppeln könnte.
5. Ziel-Resume Wenn ein Closed-Loop-Ziel aktiv ist, kann Nova den aktuellen Schritt anzeigen, damit ein Agent nach Kontextkompression nicht raten muss, wo er stand.
6. Lernfeedback Verifizierte Ergebnisse sind stärkere Evidenz für Aufgabenabschluss, PKS-Health und späteres Lernen als ein roher Werkzeugerfolg.

Wann brauche ich CLS?

Nutze CLS für Handlungen, bei denen das Ergebnis Zustand verändert und ein blinder Retry riskant wäre: Nachricht senden, Formular abschicken, Login bestätigen, Modell oder Workspace wechseln, ein zugangsrelevantes Overlay entfernen oder einen Aufgabenschritt abschließen, der nur nach sichtbarem Nachweis zählen soll.

CLS-Modell für Agenten

Für einen Agenten beantwortet CLS vier Fragen: Welches Ziel ist aktiv, welcher Zustand muss vor der Handlung gelten, welches Ergebnis beweist Erfolg oder Fehlschlag, und was passiert, wenn das Ergebnis unklar ist?

Ziel

Ein dauerhaftes Arbeitsziel auf einem Target. Es kann geordnete Schritte enthalten und erscheint bei aktiver Arbeit als goalContext.

Schritt

Eine Handlung innerhalb eines Ziels. Ein Schritt kann geplant, ausgelöst, in Prüfung, erledigt, unklar, fehlgeschlagen, blockiert oder abgebrochen sein.

Transition Contract

Der strukturierte Vertrag für eine bedeutsame Handlung: Voraussetzungen, Aktionsart, Nachbedingungen, Retry-Policy und Ambiguitäts-Policy.

Assertion

Eine maschinenprüfbare Bedingung, zum Beispiel ob ein Fakt existiert, einem Wert entspricht, sich geändert hat oder verschwunden ist. Assertions können als all, any oder forbidden gruppiert werden.

Guarded Commit

Das Ergebnisobjekt, das dem Agenten sagt, was CLS getan hat: Dispatch-Status, Verifikationsstatus, Retry-Hinweis, fehlgeschlagene Assertions und Timing.

Action Dispatch

Der Punkt, an dem die Seite wirklich berührt wurde. Wenn actionDispatched true ist, kann ein Retry einen Submit, Send oder Zustandswechsel doppeln.

Postcondition-first Retry

Eine Wiederherstellungsregel für nicht-idempotente Handlungen: erst das Ergebnis prüfen, dann entscheiden, ob ein weiterer Dispatch sicher ist.

So nutzen Agenten CLS-Infos

CLS gibt Agenten einen Prüfkreislauf um wichtige Handlungen. Der Agent liest die Seite, bindet oder übernimmt das Ziel, nutzt eine geschützte Handlung und lässt danach den zurückgegebenen Zustand über den nächsten Schritt entscheiden.

1. Seite und Zielkontext lesen Der Agent startet mit nova.perceive. Wenn goalContext vorhanden ist, liest er den aktiven Schritt vor der Handlung.
2. Ziel erstellen oder abfragen, wenn Arbeit mehrere Schritte hat Für mehrstufige Arbeit kann nova.goal_register das aktive Closed-Loop-Ziel erstellen, abfragen, schließen oder annotieren.
3. Guarded Commit Tool für bedeutsame Handlungen nutzen Für typische Commit Points bevorzugt der Agent nova.guarded_send_message, nova.guarded_submit_form, nova.guarded_login, nova.guarded_switch_model oder nova.guarded_switch_sandbox.
4. Transition Contract liefern, wenn rohe Eingabewerkzeuge genutzt werden Wenn der Agent nova.click_selector oder nova.type_selector für einen Commit Point nutzt, sendet er transitionContract mit Voraussetzungen und Nachbedingungen.
5. Dispatch und Verifikation getrennt lesen Der Agent prüft actionDispatched, guardedCommit.dispatchStatus, guardedCommit.verificationStatus und guardedCommit.retryAdvice.
6. Nur von verifiziertem Zustand aus fortsetzen Verifizierter Erfolg kann weiterlaufen. Verifizierter Fehlschlag, blockierte Voraussetzung oder unklarer Ausgang verlangen Reparatur, weitere Beobachtung oder sicheren Stopp.

Wann CLS-Zustand gilt

CLS-Zustand ist nur im aktuellen Target- und Handlungskontext belastbar. Ein früheres Ergebnis ist keine Erlaubnis, denselben Seitenzustand nach Navigation, Reload, Nutzerinteraktion oder einer anderen Agentenhandlung weiter anzunehmen.

Fehler- und Guard-Bedingungen

Diese harten Kanten sollten Agenten und Integrationen vom CLS-Vertrag erwarten.

Agentenbeispiel

Das Beispiel zeigt CLS als Vertrag: Der Agent beschreibt das Handlungsziel, Nova prüft die Nachbedingung, und die Antwort sagt, ob der nächste Schritt fortsetzen darf.

Guarded-Action-Request

{
  "tool": "nova.guarded_send_message",
  "arguments": {
    "targetId": "active",
    "text": "Please summarize the selected article.",
    "transitionContract": {
      "postconditions": {
        "success": {
          "any": [
            {
              "factKey": "chat.streamActive.started",
              "operator": "eq",
              "expected": true
            },
            {
              "factKey": "chat.assistantTurnCreated",
              "operator": "eq",
              "expected": true
            }
          ]
        }
      }
    }
  }
}

Relevante Antwortfelder

{
  "structuredContent": {
    "ok": true,
    "status": "ok",
    "actionDispatched": true,
    "guardedCommit": {
      "dispatchStatus": "dispatched",
      "verificationStatus": "verified_success",
      "retryAdvice": "do_not_retry",
      "outcomeVerdict": "satisfied"
    }
  }
}

Agenteninterpretation

{
  "treatAs": "verified action outcome",
  "mayContinue": true,
  "doNotRepeat": "actionDispatched is true and the send is non-idempotent",
  "memorySignal": "success can support task progress and future learning"
}

MCP-Vertrag

Das ist die nüchterne Schicht unter der Erklärung. Sie beschreibt CLS-Felder, die Agenten und Integratoren als Vertragssignale lesen sollen, nicht als freien Beschreibungstext.

Ausführungsregel: Keine Commit-Point-Handlung ist abgeschlossen, bevor ihre aktuelle Nachbedingung beobachtet wurde oder Unsicherheit explizit sichtbar ist.