Backlog & Lifecycle

Arbeit kommt bei covey nicht aus einem Chat-Fenster, sondern aus einem Backlog. Das ist keine Geschmacksfrage: Eine Aufgabe, die ein eigenes Objekt ist, hat einen Zustand, einen Verantwortlichen, eine Historie und ein Ende — ein Chat-Verlauf hat nichts davon.

Die Zustände

• open — angelegt, wartet auf Bearbeitung
• in_progress — der Agent arbeitet gerade daran
• blocked — wartet auf eine Antwort von außen
• done, failed, cancelled — abgeschlossen, gescheitert, zurückgezogen

Auf dem Board sind die Spalten frei konfigurierbar; darunter bleiben es diese Zustände.

Der Lauf

Geweckt wird ein Agent von einer neuen Aufgabe, einem Webhook, einem Heartbeat oder von Hand. Dann läuft immer dieselbe Kette: Sandbox hoch → Aufgabe aufnehmen (dabei im Gedächtnis nachschlagen) → arbeiten → Ergebnis festhalten und ins Gedächtnis ablegen → Sandbox runter, Agent schläft.

Die Kette ist bewusst kurz. Was länger dauert als ein Lauf, wird nicht durch Warten gelöst, sondern durch blocked.

Warum blocked der interessante Zustand ist

Ein Agent, der auf eine Kundenantwort wartet, darf keine Rechenzeit verbrauchen — und er darf die Antwort auch nicht verpassen. Also wird die Aufgabe geparkt und mit einem Korrelationsschlüssel versehen, etwa zammad:ticket:4711.

Trifft später ein Ereignis mit demselben Schlüssel ein, weckt es genau diese Aufgabe wieder, mit ihrem Kontext. Zwischen Frage und Antwort können Minuten liegen oder drei Tage; die Kosten dafür sind null.

Weckquellen

• Webhook — das Zielsystem ruft covey, wenn dort etwas passiert. Der schnellste Weg, und der einzige ohne Leerlauf.
• Heartbeat — ein Takt aus der HEARTBEAT.md, etwa - alle: 30m titel: Posteingang aufgabe: Neue Tickets sichten. Mit nur-wenn: fragt die Control Plane vorher billig nach, ob es überhaupt etwas zu tun gibt, und lässt den Agenten sonst schlafen.
• Von Hand — „Wecken" in der Oberfläche, oder ein API-Aufruf.

Nachrichten im Team-Chat

Eine Nachricht an einen Agenten im Team-Chat muss keine Aufgabe werden. Ist unter Administration → Antworten oder Aufgabe die Triage eingeschaltet, entscheidet ein billiger Zug in der Control Plane — ohne Sandbox, ohne Zielsystem, nur mit dem Organigramm, dem eigenen Backlog des Agenten und dem Gespräch: gleich antworten („ist das gestern rausgegangen?", ein Gruß, ein Dank), eine Notiz an eine Aufgabe schreiben, die schon läuft, oder für echte Arbeit eine Aufgabe eröffnen. In einer Gruppe nimmt der Agent nur Nachrichten an, die ihn erwähnen.

Eine Aufgabe aus einem Gespräch erfährt, dass ihr Ergebnis dort vorgelesen wird; der Lauf schreibt also die Antwort selbst hinein und keine Zusammenfassung für die Akte. Ein zweiter billiger Zug erzählt sie in ein paar Sätzen Chat nach, das volle Ergebnis bleibt einen Tipp entfernt.

Wie Agenten dort reden — du oder Sie, locker oder förmlich, wie viele Emoji, dazu eine Zeile freier Text —, steht an der Stimme (Stimmen → Im Team-Chat) und, als Vorgabe für alles, was eine Stimme offenlässt, unter Administration → Umgangston im Team-Chat. Welche Stimme das ist, hängt davon ab, wer schreibt: die Chat-Stimme seiner Abteilung, sonst die des Agenten, sonst die der Organisation, dazu die Zeile „So sprechen Sie mit uns“ der Abteilung (Stimmen). Der Ton wirkt nur in diesen beiden Zügen, nicht in dem, was ein Lauf in ein Zielsystem schreibt.

Turn-Limit und Budget

Ein Lauf hat eine Obergrenze an Schritten (max_turns). Wird sie erreicht, bricht der Lauf kontrolliert ab, statt sich im Kreis zu drehen — meist ein Zeichen, dass die Aufgabe zu groß geschnitten ist. Häufige Abbrüche dieser Art meldet auch die Konfigurationsprüfung.

Weiter

• Zielsysteme & Plugins — woher die Weckereignisse kommen
• Das Agenten-Modell — was zwischen zwei Läufen bleibt
• Guard-Rails & Kontrolle — wo ein Lauf anhält