Was hat mein KI-Agent gemacht? Vier Fragen, die du mit Belegen beantworten solltest

Um zu wissen, was dein KI-Agent getan hat, fang nicht mit seiner Zusammenfassung an. Prüf vier Dinge: welche Verbindung die Arbeit gemacht hat, was sich geändert hat (belegt durch etwas, das du selbst öffnen kannst), was liegen geblieben ist und was entschieden wurde und warum. Wenn eins der vier nur auf dem Wort des Agenten beruht, hast du eine Erzählung, keinen Nachweis.

Wir entwickeln Weft. Angaben zu anderen Produkten stammen von deren offiziellen Seiten, geprüft am 27. Oktober 2026.

Warum reicht ein Kommentar „erledigt“ nicht?

Ein Kommentar ist der Agent, der seine eigene Arbeit beschreibt. Er kann durchaus stimmen, aber der Kommentar kann das nicht zeigen, denn der Verfasser ist genau die Partei, die du prüfen willst. Zu wissen, dass ein Agent eine Aufgabe angefasst hat, beantwortet das Wer. Es beantwortet nicht, ob die Arbeit das ist, wofür du sie hältst.

Der Artikel von Hypertask zur Zuordnung von KI-Arbeit macht einen berechtigten Punkt: Arbeit von Agenten sollte auf demselben Board landen wie die von Menschen, nicht in einem Terminal-Log, das niemand liest. Hypertask gibt Agenten außerdem eine eigene Identität als Dienstkonten, sodass Änderungen dem Agenten zugeschrieben werden statt dir, und es hat Belege und Leases für Aufgaben, wobei seine Doku sagt, dass das bewusst nur REST-Endpunkte sind, keine MCP-Tools. Wo wir uns unterscheiden, ist, was der Nachweis enthalten sollte. Ein Kommentar-Thread mit der Ausgabe des Agenten ist ein Protokoll dessen, was der Agent gesagt hat. Wir wollen, dass der Nachweis Belege enthält.

In diesem Leitfaden gibt es keine Umfragezahlen. Du kannst die vier Fragen heute Nachmittag an deinem eigenen Board testen, und das sagt dir mehr als ein Branchendurchschnitt.

Was sind die vier Fragen?

Nimm irgendeine Aufgabe, die ein Agent letzte Woche abgeschlossen hat. Du solltest jede dieser Fragen in unter einer Minute beantworten können, ohne den Agenten zu fragen oder seinen Chat zu öffnen:

1. Wer hat es gemacht? Welcher Client über welche Verbindung die Aufgabe übernommen und abgeschlossen hat.
2. Was hat sich geändert? Das Ergebnis plus Artefakte, die du prüfen kannst, ohne dem Agenten zu vertrauen: ein Commit-Hash, eine URL, eine Datei, eine Nachrichten-ID.
3. Was wurde nicht gemacht? Die Teile, die er ausgelassen hat, und die Dinge, bei denen er unsicher war.
4. Was wurde entschieden, und warum? Jede Wahl unterwegs mit den abgewogenen Optionen, und jedes Mal, wenn du die Arbeit zurückgegeben hast.

Woher weiß ich, welcher Agent es war?

Weft verbindet sich mit KI-Clients über das Model Context Protocol an einem Endpunkt, https://letsweft.com/api/mcp. Jeder OAuth-Client und jedes persönliche Zugriffstoken ist ein eigener Akteur. Eine Aufgabe hält fest, welcher Client sie angelegt hat, und das Board zeigt den Namen, mit dem sich der Client bei der Anmeldung registriert hat, samt Symbol. Jedes Ereignis im Journal der Aufgabe speichert, ob es von einem Menschen oder über MCP kam und welcher Client es geschickt hat.

Das vollständige Journal (get_task_history im Modus full) zeigt für jedes Ereignis die rohe Client-ID: eine OAuth-Client-ID oder mcp-token gefolgt von der ID des Tokens. Das ist kein freundlicher Name, aber es ist exakt, und es unterscheidet zwei Verbindungen, selbst wenn sie aus demselben Produkt kommen.

Auch die Zuständigkeit während der Arbeit ist eindeutig. Ein Agent ruft start_task auf, was die Aufgabe mit einem Lease von 20 Minuten übernimmt und nach Doing schiebt. report_progress verlängert das Lease. Ein zweiter Agent, der dieselbe Aufgabe versucht, bekommt already_claimed, und ein abgelaufenes Lease gibt die Aufgabe für jemand anderen frei. Der Leitfaden zum Übernahme-Kreislauf erklärt das Schritt für Schritt, und mehrere Agenten auf einem Board behandelt den Fall mit mehreren Clients.

Eine praktische Regel: Gib jedem Tool eine eigene Verbindung. Wenn sich zwei Clients ein Zugriffstoken teilen, sieht das Board einen Akteur, und die Frage nach dem Wer verliert ihre Antwort.

Was hat sich geändert, und kann ich es prüfen, ohne den Agenten zu fragen?

Wenn ein Agent fertig ist, ruft er complete_task auf. Nur die ID der Aufgabe ist Pflicht; alles andere ist optional, und der Aufruf scheitert nie an fehlenden Belegen. Das ist Absicht: Fertige Arbeit zu verlieren ist schlimmer, als sie ungeprüft festzuhalten. Was ein Beleg enthalten kann:

• outcome: bis zu 1.000 Zeichen dazu, was getan wurde und wo das Ergebnis liegt.
• artifacts: bis zu 20 Einträge, jeder mit einer Art (url, file, message, commit und so weiter), einem Ort und optional einem sha256-Hash.
• claims: was der Agent zu haben behauptet, gespeichert als Behauptungen statt als geprüfte Fakten.
• notDone und unknowns: im nächsten Abschnitt.
• nextStep: was der Agent als Nächstes tun würde, wenn du annimmst.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Die Zeile outcome ist immer noch Erzählung. Die Artefakte sind der Teil, den du prüfen kannst. Ein Commit-Hash existiert in deinem Repository oder nicht. Eine URL lädt oder nicht. Der sha256 einer Datei stimmt oder nicht. Wenn ein Beleg ein Ergebnis hat, aber keine Artefakte, behandle ihn als vom Agenten gemeldete Arbeit, denn genau das ist er. Im Web zeigen Done-Karten, ob eine Aufgabe Verifiziert ist oder nur Laut Agent erledigt.

Was hat der Agent nicht gemacht?

Das ist die Frage, die die meisten Nachweise auslassen, und die, die dich zwei Wochen später einholt. complete_task hat dafür zwei Listen mit je bis zu 20 Einträgen à 500 Zeichen: notDone für das, was der Agent absichtlich weggelassen hat, und unknowns für das, wobei er unsicher ist. Die Beschreibung des Tools selbst bittet Agenten, ausdrücklich zu sagen, was sie nicht getan haben. Genau das trennt ein Ergebnis, auf das du dich verlassen kannst, von einem, das du selbst nachvollziehen musst.

Lies diese Listen zuerst. „Tests gegen die Staging-Datenbank nicht ausgeführt“ ändert, was du als Nächstes tust. Ein Beleg ohne notDone-Einträge bei einer großen Aufgabe ist selbst eine Nachfrage wert.

Was wurde entschieden, und warum?

Entscheidungen im Chat verschwinden, wenn der Chat weggescrollt ist. record_decision hält sie auf zwei Arten fest:

• Ein eigenständiger Entscheidungsdatensatz: ein Titel, das Ergebnis, der Kontext, die tatsächlich abgewogenen Optionen, die Folgen und die Bedingung, unter der neu bewertet wird. Datensätze sind unveränderlich; einen zu ändern heißt, eine neue Entscheidung festzuhalten, die ihn ablöst, und der alte bleibt, als abgelöst markiert.
• Ein weitergegebenes Urteil: Wenn du einem Agenten im Gespräch sagst „angenommen“, „mach es mit X neu“, „verwerfen“ oder „nicht jetzt“, hält er dieses Urteil mit deiner Notiz an der Aufgabe fest.

get_task_history liest das in drei Modi zurück: summary (die Karte, ihr letzter Beleg und Zählungen), decisions (jede Entscheidung zur Aufgabe, einschließlich des Grundes, warum sie zurückgegeben wurde, der auch ein späteres Annehmen überdauert) und full (das rohe Journal, begrenzt auf 100 Ereignisse). get_context übergibt die gültigen Entscheidungen innerhalb eines Token-Budgets an den nächsten Agenten, sodass der nächste Lauf bei dem anfängt, was entschieden wurde, statt bei null. Mehr dazu unter warum Entscheidungen in KI-Chats verloren gehen.

Wo prüfe ich das, und worauf klicke ich?

Standardmäßig geht eine abgeschlossene Aufgabe direkt nach Done. Sie hält in deiner Inbox an, wenn die Aufgabe eine Prüfung braucht oder ein Verifizierungscheck fehlschlägt. Dort siehst du den Beleg und vier Buttons: Annehmen, Überarbeiten, Später und Verwerfen. Überarbeiten verlangt eine Notiz, und diese Notiz geht an den Agenten zurück.

Wenn der Agent einen nextStep mitgegeben hat, steht er über dem Annehmen-Button, und Annehmen genehmigt genau diesen Schritt. Die Genehmigung gilt 72 Stunden und kommt über get_my_work oder start_task als der eine nächste Schritt zum Agenten zurück. Fragen, die ein Agent mit request_input stellt, landen in derselben Inbox, im Web und in den Apps für iOS und Android, mit einer Push-Nachricht aufs Handy.

Die Inbox hat absichtlich eine Grenze: 5 wartende Einträge in einem Ein-Personen-Workspace, 10 im Team oder 45 Minuten geschätzte Prüfzeit, je nachdem, was zuerst eintritt. Wenn sie voll ist, lehnt start_task mit attention_queue_full ab, sodass Agenten Arbeit abschließen oder klären, statt dir noch mehr zum Prüfen aufzuhäufen.

Welche Belege sollte ich je nach Art der Aufgabe verlangen?

Schreib das in die Aufgabenbeschreibung, damit der Agent weiß, welchen Nachweis du erwartest:

• Code: Commit-Hash und PR-URL als Artefakte. notDone sollte nicht ausgeführte Tests, nicht angewandte Migrationen und absichtlich unberührte Dateien nennen.
• Inhalte: die veröffentlichte URL oder, wenn noch nicht live, die Entwurfsdatei mit ihrem sha256. unknowns sollte Fakten auflisten, die der Agent nicht bestätigen konnte.
• Recherche: eine Quell-URL für jede zentrale Aussage und die Notizdatei. unknowns sollte trennen, was eine Quelle sagt und was der Agent gefolgert hat.
• Kontaktaufnahme: die Nachrichten-ID jeder gesendeten Nachricht und die Empfängerliste als Datei. notDone sollte auflisten, wer nicht kontaktiert wurde und warum.

Wie steuere ich überhaupt, was ein Agent tun darf?

Zuordnung im Nachhinein funktioniert am besten mit Grenzen im Vorhinein. In Weft hat jede OAuth-Verbindung eine von drei Berechtigungsstufen, festgelegt auf dem Zustimmungsbildschirm oder später unter Einstellungen, Verbundene KI-Clients:

• full (Standard): alle 32 Tools.
• write: alles außer den drei destruktiven Tools (trash_task, archive_done_tasks, complete_sprint).
• read: nur die 11 lesenden Tools.

Die Prüfung läuft bei jedem Aufruf. Trennen widerruft die Refresh-Tokens der Verbindung und lehnt beim nächsten Aufruf jedes Token ab, das vor dem Schnitt ausgestellt wurde. Persönliche Zugriffstokens für Clients ohne OAuth haben keine Berechtigungsstufen: Ein Token erreicht alle 32 Tools, und ein Widerruf wirkt ab dem nächsten Aufruf. Agenten können Aufgaben in einen Papierkorb für 30 Tage verschieben, aber nicht endgültig löschen; Wiederherstellen aus dem Papierkorb ist eine Pro-Funktion.

Was macht Weft hier nicht?

• Es hat keine Integration mit GitHub oder Slack, Weft schlägt deine Commits oder Nachrichten also nicht für dich nach. Das Artefakt öffnest du selbst.
• Es hat keine öffentliche REST-API, keine Webhooks und keine CLI, um Belege in andere Systeme zu schieben. Es gibt einen Export als JSON und Markdown.
• Es verfolgt keine Modellschritte. Tools, die Prompts, Tokens und Latenz auf Modellebene protokollieren, machen einen anderen Job, und vielleicht willst du zusätzlich eins davon.
• Agenten schreiben ihre Belege selbst. Weft macht die Lücke zwischen Behauptung und Beleg sichtbar; ehrlich machen kann es einen Agenten nicht.

Wenn du Agenten als Dienstkonten über eine REST-API verwalten willst, eine CLI für CI-Skripte oder eingebaute KI-Funktionen wie Aufgaben schreiben und Triage, passt Hypertask dafür besser. Unsere Seite Hypertask-Alternative vergleicht die beiden direkt.

Reicht die Git-Historie nicht, um zu wissen, was mein Agent getan hat?

Git zeigt, was sich im Code geändert hat. Es zeigt nicht, was der Agent ausgelassen hat, wobei er unsicher war oder wofür er sich zwischen zwei Optionen entschieden hat. Nutze den Commit-Hash als Artefakt an der Aufgabe, und halte den Rest im Beleg und im Entscheidungsdatensatz fest.

Kann ein Agent nicht einfach ein Artefakt erfinden?

Er kann jeden beliebigen String schicken. Der Sinn eines Artefakts ist, dass du es öffnen kannst: ein Hash, den du nachschlagen kannst, eine URL, die du laden kannst, eine Nachrichten-ID, die du findest. Ein erfundenes scheitert in dem Moment, in dem du prüfst, was bei einem Kommentar nie passiert. Wenn eine Aufgabe einen Verifizierungscheck hat und ein blockierender Check fehlschlägt, bleibt die Aufgabe aus Done heraus.

Wartet jede fertige Aufgabe auf meine Prüfung?

Nein. Standardmäßig geht eine abgeschlossene Aufgabe nach Done. Sie wartet nur dann in deiner Inbox auf Annehmen, Überarbeiten, Später oder Verwerfen, wenn die Aufgabe eine Prüfung braucht oder ein Verifizierungscheck fehlschlägt.

Welche KI-Clients können Belege in Weft schreiben?

Jeder MCP-Client. In ChatGPT ist Weft ein veröffentlichtes Plugin in jedem Tarif, auch in Free. Claude Code verbindet sich mit claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai und Claude Desktop nutzen einen eigenen Connector. Es gibt Einrichtungsseiten für 33 Clients, etwa Claude Code, ChatGPT, Cursor und Codex.

Was kostet das?

Free umfasst 50 Aufgaben und 200 KI-Aufrufe im Monat. Pro kostet € 7,74 pro Platz und Monat oder € 65,45 pro Platz und Jahr. Weft hat keine KI-Credits: Das Denken passiert in deinem eigenen KI-Client. Siehe Preise.