Als vor einem Jahr die ersten Cloud Agents starteten, galten sie noch als logische Erweiterung lokaler Assistenten. Mittlerweile hat sich das Bild fundamental gewandelt: Die intelligenten Helfer arbeiten heute auf dedizierten virtuellen Maschinen mit eigenen Umgebungen, Abhängigkeiten und Netzwerkzugriff. Sie agieren parallel, laufen unbeaufsichtigt und übernehmen Aufgaben, die Stunden statt Minuten dauern. Doch genau diese Fähigkeiten werfen neue Fragen zu Infrastruktur, Zuverlässigkeit und Orchestrierung auf.

Die Entwicklungsumgebung als Qualitätsgarant

Das wichtigste Erkenntnis des vergangenen Jahres ist simpel, aber folgenreich: Ohne eine vollständige Entwicklungsumgebung bleiben Cloud Agents weit unter ihren Möglichkeiten. Lokale Agents erben die Arbeitsumgebung vom Entwicklerrechner quasi automatisch. In der Cloud muss diese erst mühsam rekonstruiert werden – und die Fehler zeigen sich selten als Crash, sondern als subtile Qualitätsverluste.

Die Konsequenz: Moderne Cloud Agent Plattformen benötigen eine überraschend komplexe Infrastruktur. Dazu gehören bessere Tools zum Aufbau der Agent-Umgebung, effiziente Mechanismen zum Ruhenlegen und Wiederaufwecken von VMs, sowie Pipelines für Checkpoints und Forks von VM-Images. Hinzu kommen sichere Netzwerkrichtlinien, Secret-Masking und Credential-Management – kurzum: eine komplette Enterprise-IT für Agenten.

Zuverlässigkeit über Tage und Wochen

Cloud Agents laufen isoliert in eigenen VMs. Das ermöglicht parallele Langzeitaufgaben, macht das System aber anfällig für Störungen wie Provider-Ausfälle oder absteigende Nodes. Die erste Architektur basierte auf einem Work-Stealing-Prinzip, das lokale Konzepte eins zu eins in die Cloud übertrug – mit dem Ergebnis von mageren zehn Prozent Verfügbarkeit.

Die Lösung lag in der Migration zu Temporal, einer Plattform für durable Execution. Statt alles selbst zu bauen, werden Retries, Scheduling und Fehlertoleranz nun industriestandard-gerecht abgebildet. Das aktuelle System übersteht Ausfälle von Inferenzprovidern, versetzte Pods und Laufräume über mehrere Tage oder Wochen. Intern stammen mittlerweile über 40 Prozent aller Pull Requests von Cloud Agents.

Entkopplung schafft Flexibilität

Ein Cloud Agent ist längst keine monolithische Schleife auf einem einzelnen Rechner mehr. Stattdessen startet er lokal, delegiert an die Cloud oder spannt asynchrone Subagents über mehrere Maschinen auf. Um das zu ermöglichen, wurden drei Komponenten streng voneinander getrennt: die Agent-Schleife, der Maschinen-Zustand und der Konversations-Zustand.

Da die eigentliche Agent-Logik in Temporal statt auf der VM selbst lebt, lassen sich Pod-Lebenszyklen unabhängig verwalten. Für die Kommunikation wurde eine eigene Storage- und Streaming-Schicht entwickelt, die Konversations-Updates effizient an Web- und Desktop-Clients sendet. Selbst Retries nach einem Teilabriss werden sauber abgebildet, sodass Clients den Stream zurückspulen und aktualisierte Daten anzeigen können.

Mehr Vertrauen, weniger Vorgaben

Ein zentrales Spannungsfeld beim Bau von Cloud Agents ist die Frage, wie viel Verhalten fest verdrahtet werden soll und wie viel dem Agent selbst überlassen bleibt. In der Frühzeit prüfte das Harness jeden Arbeitsschritt, erzwang Commits und Pushes. Mit leistungsfähigeren Modellen wanderte diese Logik zunehmend in vom Agent kontrollierte Tools.

Das gleiche Muster zeigte sich beim CI Autofix: Wo früher das Harness Fehlerlogs holte und in die VM schrieb, erhält der Agent heute direkten Zugriff auf die passenden Kommandozeilenwerkzeuge. Ein besonderes Augenmerk liegt auf der höheren Autonomie von Cloud Agents, da der Kostenfaktor einer blockierenden Rückfrage in der Cloud deutlich höher ist als am lokalen Rechner.

Der Weg zu selbstheilenden Systemen

Die nächste Generation von Cloud Agents zielt darauf ab, die Balance zwischen enger Kontrolle und völliger Freiheit neu zu definieren. Das Modell der Zukunft vergibt dem Agent Werkzeuge, um das System um sich herum zu verstehen. Fehlende Secrets, blockierter Netzwerkzugriff oder fehlerhafte Umgebungen sollen nicht mehr zum Stillstand führen, sondern automatisch gemeldet und behoben werden.

Der Ansatz namens Autoinstall zeigt einen möglichen Pfad in diese Richtung. Denn die Entwicklung der letzten Monate macht eines deutlich: Cloud Agents werden nicht langsamer entwickelt – im Gegenteil. Teams, die auf bewährte Plattformen setzen, können diese rasante Entwicklung nutzen, ohne die gesamte Infrastruktur selbst zu betreiben.

Quelle: Cursor Blog – What we’ve learned building cloud agents