Claude Duet prüfen: ein Prüfplan für Agent-Ankündigungen

Das Problem

Claude Duet ist seit dem 21. Oktober 2026 als Research Preview verfügbar — für Pro- und Max-Abonnenten in den Vereinigten Staaten, per Warteliste. Wer in Europa oder Asien arbeitet, kann das Produkt nicht ausprobieren und muss trotzdem entscheiden, ob die Architektur für eigene Agenten taugt. Ankündigungen sind dafür eine schlechte Grundlage: Sie beschreiben Absichten, nicht Verhalten.

Der Ausweg ist unspektakulär. Man behandelt die Veröffentlichung wie ein Prüfobjekt und trennt drei Sorten von Aussagen: was der Hersteller über sein Produkt behauptet, was von außen nachvollziehbar ist, und was sich ohne Zugang nicht klären lässt. Dieser Prüfplan ist in etwa einer Stunde machbar und liefert mehr als jede Demo.

Die Umgebung: vier Quellen, vier Zuständigkeiten

Anthropic veröffentlicht zu Duet vier Dokumente, und sie beantworten unterschiedliche Fragen. Es lohnt sich, sie getrennt zu lesen, statt sie als ein Paket zu behandeln.

• Ankündigung: Positionierung, Fähigkeiten, Zeitplan, erste Nutzer. Hier stehen die Versprechen.
• Sicherheits- und Datenschutzdokument: Freigaberegeln, Verbote, Datenflüsse, Testverfahren. Hier steht, was das System nicht darf.
• Produktseite: Oberflächen, App-Formen, Funktionsliste. Hier steht, wie es sich anfühlt, ohne dass man es benutzt.
• Hilfezentrum: Grenzen, Kontingent, Zugangsvoraussetzungen. Hier steht, was fehlt — und genau diese Seite wird am seltensten gelesen.

Die Quellen wurden am 26. Oktober 2026 abgerufen. Die Vorschau ist auf eingeladene Pro- und Max-Abonnenten in den USA begrenzt; die folgenden Produktangaben stammen aus diesen offiziellen Dokumenten.

Der Prüfplan in sechs Schritten

Schritt 1: Ankündigung gegen Hilfezentrum stellen. Widersprüche sind der billigste Fund. Die Ankündigung spricht von einem Agenten, der selbstständig arbeitet; das Hilfezentrum präzisiert, dass er verbundene Apps in festen Abständen prüft, nicht kontinuierlich. Beides kann gleichzeitig wahr sein, aber nur die zweite Formulierung beschreibt ein System, das man betreiben kann.

Schritt 2: Jede Behauptung einer Klasse zuordnen. Drei Klassen reichen: Herstellerangabe, extern nachvollziehbar, ohne Zugang unprüfbar. Die Zuordnung ist die eigentliche Arbeit, weil sie sichtbar macht, wie viel des Artikels auf der ersten Klasse beruht.

Schritt 3: Zuerst die Grenzen lesen. Die Liste im Hilfezentrum ist ungewöhnlich offen: keine Modellwahl, feste Prüfintervalle, kein Einblick in den Browser, keine Übernahme durch den Menschen, kein Zugriff auf lokale Dateien, eingeschränkte Konnektoren, kein Microsoft 365, keine Telefonate. Wer diese Liste zuerst liest, spart sich die Enttäuschung, sie später zu entdecken.

Schritt 4: Das Testprogramm einordnen. Die Veröffentlichung nennt drei Varianten (normal, eingeschleuste Anweisungen, erzwungene Überschreitung), Shadow-Traffic, Red Teams, ein externes Penetrationstesting mit Quellcode und ein Bug-Bounty-Programm. Das ist mehr als üblich — und trotzdem kein Beleg für den Alltag. Ein Red Team prüft bekannte Angriffsklassen, nicht die Frage, ob jemand um sieben Uhr morgens eine Freigabekarte überfliegt.

Schritt 5: Das Kostenmodell prüfen. Duet teilt ein Kontingent mit der übrigen Claude-Nutzung, und die Hintergrundprüfungen zählen mit. Das ist keine Fußnote: Es erklärt, warum das Intervall so gewählt wurde, wie es gewählt wurde. Wer ein ähnliches System baut, entscheidet mit dem Intervall über Betriebskosten, nicht über Aktualität.

Schritt 6: Den Zugang prüfen. Pro oder Max, ein Konto in den USA, eine Einladung von der Warteliste, keine Team- oder Enterprise-Tarife in der Vorschau. Ein Detail, das regelmäßig übersehen wird: Die E-Mail der Warteliste muss zum Konto passen, mit dem man sich anmeldet, sonst landet der Zugang an einer Stelle, an der man ihn nicht nutzen kann.

Was der Prüfplan nicht leistet

Der Plan sortiert Aussagen und macht Lücken sichtbar. Er beantwortet aber nicht die Frage, ob das Produkt im Alltag taugt. Dafür fehlen drei Dinge, die kein Dokument liefert: wie sich eine Freigabekarte anfühlt, wenn sie zum fünften Mal am Vormittag auftaucht; wie gut die Morgenübersicht zwischen wichtig und laut unterscheidet; und wie das System reagiert, wenn eine verbundene App tagelang nicht antwortet.

Ein zweiter Punkt wird oft übersehen: Ein Prüfplan für Ankündigungen ist kein Prüfplan für Architektur. Aus der Beschreibung lässt sich ableiten, welche Bausteine vorhanden sind — eine Sandbox, eine feste Befehlsliste, ein Freigabeschritt, ein geteiltes Kontingent. Ob diese Bausteine sauber getrennt sind, zeigt sich erst im Betrieb, an der Zahl der Vorfälle und an der Zeit, die eine Aufarbeitung braucht.

Wer den Plan auf ein eigenes System anwendet, führt deshalb zwei Spalten: eine für das, was dokumentiert ist, und eine für das, was erst nach vier Wochen echter Nutzung beantwortbar wird. Die zweite Spalte bleibt zunächst leer. Das ist kein Mangel des Plans, sondern sein Ergebnis.

Prüfen und Fehlersuche

Bei der Durchführung gehen vier Dinge schief, und alle vier sind vermeidbar.

• Quellen antworten nicht. Eine Seite liefert 403 oder läuft in einen Timeout. Ergebnis festhalten, mit Datum, und nicht aus dem Gedächtnis ergänzen. Ein „laut Hersteller" ohne Datum ist wertlos.
• Screenshots ohne Kontext. Ein Bild ohne Aufnahmedatum und ohne Quellenangabe ist kein Beleg, sondern Dekoration.
• Zahlen aus zweiter Hand. Weiterleitungen und Zusammenfassungen verändern Beträge und Zeiträume. Wenn eine Zahl nicht in der Primärquelle steht, gehört sie nicht in den Text.
• Vermischte Versionsstände. Ankündigung und Hilfezentrum werden zu unterschiedlichen Zeitpunkten aktualisiert. Wer beides zitiert, sollte das Datum jeder Quelle nennen.

Wer diese vier Punkte einhält, bekommt einen Text, der auch dann noch stimmt, wenn das Produkt sich ändert. Das ist bei Research Previews der Unterschied zwischen einer Momentaufnahme und einem Artikel.

Austausch

Der Prüfplan deckt ab, was in Dokumenten steht. Er deckt nicht ab, wie sich Freigabekarten im Betrieb anfühlen, wie gut die Morgenübersicht ist und wie oft das System etwas meldet, das man schon weiß. Genau diese drei Punkte entscheiden aber, ob ein proaktiver Agent genutzt oder stillgelegt wird.

Wenn Sie Zugang haben: Wie viele Freigaben pro Tag sind es bei Ihnen, und wie viele davon lesen Sie wirklich? Und wenn Sie selbst einen Agenten bauen — welche Prüfung fehlt in dieser Liste?

Wer mehrere Modellanbieter hinter einem Produkt bündelt, zieht Schlüssel, Modellnamen und Abrechnung üblicherweise in ein Gateway statt in den Anwendungscode; Crazyrouter dokumentiert seine Endpunkte und Preise als eine solche Möglichkeit. Ob das passt, hängt von Aufrufvolumen und Compliance ab.

Quellen: Ankündigung, Sicherheits- und Datenschutzdokument, Produktseite und Hilfezentrum von Anthropic, alle am 26. Oktober 2026 abgerufen.