Zum Hauptinhalt springen

Conway-Zeitleiste: Wie Anthropic Always-On-Agents aufbaut

· 9 Minuten Lesezeit
Claude Dev
Claude Dev
Claude Dev

Das Wichtigste zu Conway ist:

Conway ist kein offiziell gestartetes Anthropic-Produkt.

Was heute existiert, ist eine Kombination aus:

  • offiziellen Anthropic-Launches rund um Cowork, Dispatch, computer use, scheduled tasks und auto mode
  • aktueller Hilfedokumentation, die zeigt, wie diese Teile zusammenarbeiten
  • einem Drittanbieterbericht vom 1. April 2026, der eine unveröffentlichte interne Umgebung namens Conway beschreibt

Wer nur den Leak betrachtet, verpasst die Architektur. Wer nur die offiziellen Launches betrachtet, verpasst die Richtung.

Die technische Geschichte liegt in der Kombination aus beidem.

Kurzfassung​

Aus Systemsicht bewegt sich Anthropic klar auf ein Always-On-Agent-Modell zu.

Nicht weil Conway angekündigt wurde, sondern weil der bereits ausgelieferte Produkt-Stack die meisten nötigen Bausteine schon enthält:

  • einen persistent thread über Geräte hinweg
  • eine desktop runtime mit lokalem Dateizugriff
  • scheduled execution
  • computer use, wenn direkte Integrationen fehlen
  • sub-agent coordination
  • einen sichereren long-running permission mode
  • Aufgabenübergabe von Mobilgerät zu Desktop über Dispatch

Conway ist wichtig, weil es so aussieht, als würde Anthropic diese Ideen in eine explizitere always-on agent environment bündeln.

Was bestätigt ist und was nicht​

Von Anthropic bestätigt​

Anthropic hat offiziell ausgeliefert oder dokumentiert:

  • Cowork als Desktop-Agent-Umgebung auf Basis der agentischen Architektur von Claude Code
  • persistente Aufgabenübergabe zwischen Telefon und Desktop über Dispatch
  • scheduled tasks und wiederkehrende Routinen
  • computer use in Cowork und Claude Code
  • auto mode für länger laufende Claude-Code-Sessions

In den aktuellen Anthropic-Dokumenten bestätigt, aber nicht als einzelner Launch​

Die aktuellen Hilfedokumente beschreiben inzwischen einen Workflow, in dem:

  • ein durchgehender Thread erhalten bleibt
  • Claude Entwicklungsarbeit nach Claude Code routet
  • Claude Wissensarbeit nach Cowork routet
  • Ergebnisse in denselben persistenten Thread zurückfließen
  • scheduled tasks automatisch laufen können
  • computer use Apps auf dem Desktop bedienen kann

Das kommt einer always-on agent runtime bereits sehr nahe, auch wenn Anthropic es nicht so nennt.

Berichtet, aber nicht offiziell angekündigt​

Der Name Conway stammt aus einem Drittanbieterbericht vom 1. April 2026. Dem Bericht zufolge scheint Conway zu bieten:

  • eine dedizierte Conway instance
  • eine Sidebar mit Search, Chat und System
  • extensions
  • webhooks
  • direkte Verbindung zu Claude in Chrome
  • notifications

Das ist derzeit das stärkste Signal dafür, dass Anthropic an einer expliziteren always-on agent environment arbeitet.

Die Zeitleiste​

12. Januar 2026: Cowork research preview startet​

Anthropic stellte Cowork als „Claude Code for the rest of your work“ vor.

Wichtig war dabei nicht die UI, sondern das Runtime-Modell:

  • Claude arbeitet direkt in Ordnern auf dem Computer
  • Claude kann mehrstufige Aufgaben bearbeiten
  • Cowork basiert auf denselben agentic foundations wie Claude Code
  • Nutzer können Aufgaben einreihen und Claude eher wie einen Mitarbeiter als wie einen Chat nutzen

Das war das erste öffentliche Signal für eine breitere Desktop-Agent-Runtime jenseits des Terminal-Coding-Tools.

Januar bis Februar 2026: Cowork erweitert sich über Pläne und auf Windows​

Anthropic weitete Cowork auf weitere Bezahlpläne und anschließend auf Windows aus.

Technisch wichtig ist daran, dass Cowork offenbar nicht als Nischenexperiment gedacht war, sondern als Runtime, die für breiteren Einsatz gehärtet wird.

Bis Ende März 2026: Cowork-Dokumente beschreiben die vollständige lokale Agent-Runtime​

Die aktuellen Cowork-Dokumente zeichnen ein klareres Architektur-Bild als der ursprüngliche Blogpost.

Cowork wird beschrieben als:

  • Übertragung der agentic capabilities von Claude Code in Claude Desktop
  • direct local file access
  • Koordination mehrerer Sub-Agents parallel
  • Ausführung länger laufender Aufgaben
  • Unterstützung von scheduled tasks
  • Unterstützung von projects mit Dateien, Anweisungen und Memory
  • Ausführung von Arbeit in einer virtual machine (VM) environment

Das ist keine Chatbot-Featureliste, sondern eine Agent-Runtime.

23. März 2026: Dispatch und computer use landen über Cowork und Code hinweg​

Das ist der bisher wichtigste öffentliche Meilenstein.

Anthropic beschrieb einen Produktzustand, in dem Claude:

  • eine Konversation von Telefon zu Desktop weiterführen kann
  • den Computer benutzen kann
  • Kontext über Sitzungen hinweg behält
  • Aufgaben nach Zeitplan ausführen kann
  • sowohl in Cowork als auch Claude Code arbeiten kann

Spätestens hier wird die Always-On-Richtung deutlich.

Ein Always-On-Agent braucht vor allem zwei Dinge:

  1. Persistenz
  2. die Fähigkeit zu handeln, wenn niemand aktiv auf die Session schaut

Dispatch plus computer use liefern genau diese Kombination.

Ende März 2026: Dispatch-Dokumente ergänzen das Routing-Modell​

Die Dispatch-Support-Dokumentation ergänzt ein besonders wichtiges Detail:

  • es gibt einen durchgehenden persistenten Thread
  • Claude entscheidet beim Zuweisen einer Aufgabe, um welche Art Arbeit es sich handelt
  • Entwicklungsaufgaben laufen in Claude Code
  • Wissensarbeit läuft in Cowork

Das ist ein starkes Architektur-Signal.

Anthropic präsentiert Code und Cowork nicht mehr als isolierte Produkte, sondern als spezialisierte Ausführungsflächen unter einem einzigen Task-Thread.

24. März 2026: Auto Mode gibt Claude Code einen sichereren Pfad für lange Läufe​

Einen Tag später startete Anthropic auto mode für Claude Code.

Das ist wichtiger, als es zunächst klingt.

Always-On-Agents bringen wenig, wenn sie alle paar Minuten wegen einer Berechtigung stoppen. Vollständig offene Berechtigungen sind aber unsicher. Auto Mode ist Anthropics Mittelschicht:

  • Claude kann einige permission decisions selbst treffen
  • ein Klassifikator prüft tool calls vorab
  • sichere Aktionen laufen automatisch
  • riskante Aktionen werden blockiert oder eskaliert

Das ist ein fehlendes Infrastrukturstück für unattended oder semi-unattended Arbeit.

1. April 2026: Drittanbieterbericht macht Conway sichtbar​

TestingCatalog berichtete, Anthropic teste eine interne always-on agent environment namens Conway.

Die gemeldeten Details passen auffällig gut zu der Richtung, die Anthropic bereits öffentlich aufbaut:

  • eine standalone instance
  • extension-Installation einschließlich .cnw.zip
  • connectors and tools
  • direkte Claude in Chrome-Verbindung
  • webhooks mit öffentlichen URLs, die die Instance aufwecken können
  • notifications

Wenn das stimmt, ist Conway kein Zufallsprojekt, sondern eher die nächste Verpackungsschicht über einer Runtime, die Anthropic bereits öffentlich ausrollt.

Warum Conway technisch Sinn ergibt​

Wenn man die Produktnamen entfernt, hat Anthropic bereits die meisten Bausteine für ein always-on agent system.

1. Ein persistenter Kontroll-Thread​

Dispatch stellt den user-facing Thread bereit, der Gerätewechsel überlebt.

Er ist wichtig, weil er zur stabilen control surface wird:

  • dort formuliert der Nutzer Ziele
  • dorthin kommen Ergebnisse zurück
  • dort können Freigaben stattfinden
  • dort kann Memory anwachsen

Ohne diesen Thread wäre jede Aufgabe nur ein frischer Spawn.

2. Spezialisierte Runtimes​

Anthropic hat zwei verschiedene execution surfaces:

  • Claude Code für Entwicklungsarbeit
  • Cowork für breitere Desktop-Wissensarbeit

Das ist bereits eine scheduler-freundliche Architektur.

3. Trigger jenseits des Vordergrund-Chats​

Scheduled tasks und Dispatch schieben das Modell über reaktiven Chat hinaus.

Ein Always-On-Agent braucht externe Trigger:

  • zeitbasierte Trigger
  • Nachrichten von einem anderen Gerät
  • möglicherweise service-getriggerte Events

Gerade deshalb sind die im Conway-Bericht erwähnten webhooks so interessant.

4. Computer Use als Fallback-Aktor​

Direkte Integrationen sind immer besser als Bildschirmsteuerung. Anthropic sagt das in den Computer-Use-Dokumenten selbst: zuerst connectors, dann Browser-Automatisierung, dann direkte Bildschirminteraktion.

Das ist wichtig, weil es zeigt, dass computer use kein Gimmick ist, sondern der last-resort actuator in einem breiteren Aktions-Stack.

5. Governance für lang laufende Arbeit​

Auto Mode ist das erste sichtbare Signal dafür, dass Anthropic versteht: Ein Always-On-Agent braucht eine andere permission architecture als ein Vordergrund-Assistent.

Wenn Conway real ist, braucht es fast sicher stärkere Formen von:

  • policy checks
  • event filtering
  • webhook-level trust boundaries
  • extension sandboxing
  • auditability
  • wake / sleep semantics

Die wichtigsten Conway-Signale​

Standalone instance​

Die Formulierung „Conway instance“ deutet darauf hin, dass Anthropic in Richtung eines persistent agent container denkt, nicht bloß an einen Chat-Tab.

Das wirft klassische Always-On-Fragen auf:

  • Wann wacht die Instance auf?
  • Wie lange bleibt sie aktiv?
  • Was persistiert?
  • Was wird beim Neustart zurückgesetzt?
  • Was darf sie extern triggern?

Extensions​

Falls der Bericht korrekt ist, bewegt sich Conway in Richtung eines extension model mit:

  • tools
  • UI tabs
  • context handlers

Das spricht für eine echte Plugin-Architektur für persistente Agents.

Webhooks​

Das ist das stärkste Always-On-Signal im Bericht.

Ein Webhook bedeutet, dass der Agent nicht nur auf Vordergrund-Prompts wartet, sondern durch externe Systemereignisse geweckt werden kann.

Das ist der Übergang von:

  • „starte, wenn ich dich frage“

zu:

  • „starte, wenn sich die Welt ändert“

Chrome connection​

Anthropic hat bereits Claude for Chrome und browserbasierte Action Paths. Eine direkte Verbindung zwischen Conway und Chrome wäre architektonisch folgerichtig.

Notifications​

Notifications wirken klein, sind es aber nicht.

Ein Always-On-Agent braucht einen kompakten Signalkanal für:

  • task finished
  • approval needed
  • trigger failed
  • environment offline
  • schedule skipped

Die eigentliche technische Lesart​

Meine Einschätzung lautet:

Conway ist wahrscheinlich keine komplett neue Architektur, sondern der Versuch, mehrere bereits ausgelieferte Subsysteme in eine explizitere persistent-agent environment zu bündeln.

Diese Subsysteme sind bereits sichtbar:

  • Cowork runtime
  • Claude Code runtime
  • Dispatch thread
  • scheduled tasks
  • computer use
  • mobile handoff
  • safer long-running permissions

Falls Conway veröffentlicht wird, dürfte es diese Teile in ein klareres Instance-Modell überführen mit:

  • durable identity
  • event triggers
  • extension points
  • external wake-up paths
  • unified notifications

Dann ginge es nicht mehr nur um „Claude arbeitet weiter, während ich kurz weg bin“, sondern um:

Claude bleibt als Softwaresystem resident.

Was Anthropic noch lösen muss​

Always-On-Agents sind nicht nur ein UX-Problem, sondern vor allem ein System- und Sicherheitsproblem.

1. Trigger Trust​

Webhook-triggered agents schaffen Angriffsflächen:

  • forged events
  • replayed events
  • poisoned payloads
  • Eskalation über externe Dienste

2. Extension Isolation​

Ein Erweiterungsmodell ist nur dann sinnvoll, wenn Drittlogik die Instance nicht still kompromittieren kann.

3. State Hygiene​

Persistente Agents sammeln Kontext an, und angesammelter Kontext altert schlecht.

4. Human Control​

Je persistenter der Agent, desto wichtiger wird ein schneller, verlässlicher Stop.

5. Execution Visibility​

Foreground-Chat macht Handlungen gut sichtbar. Always-On-Ausführung nicht. Daher werden Audit-Logs, Summaries, Traces und Event-Historien viel wichtiger.

Fazit​

Wenn man fragt: „Hat Anthropic Conway offiziell gestartet?“, lautet die Antwort nein.

Wenn man fragt: „Baut Anthropic klar in Richtung einer always-on agent architecture?“, lautet die Antwort ja.

Die offizielle Produktspur ist bereits deutlich:

  • Cowork etablierte die Desktop-Agent-Runtime
  • Dispatch etablierte den persistierenden Thread über Geräte hinweg
  • scheduled tasks etablierten zeitbasierte Automatisierung
  • computer use etablierte die Fallback-Aktorschicht
  • auto mode etablierte sicherere Langläufer-Ausführung
  • das berichtete Conway ergänzt die Sprache von instances, webhooks, extensions und notifications

Das ist die eigentliche technische Geschichte.

Sources (checked April 3, 2026)​