Bei Verksum beschäftigt mich gerade eine Frage, die zunächst ziemlich technisch klingt: Wo arbeitet ein Agent eigentlich? Auf meinem Rechner, in der Cloud, in Codex, in Claude Code, in Antigravity, oder irgendwann in einer ganz anderen Runtime? Lange hätte ich wahrscheinlich versucht, diese Frage möglichst früh zu beantworten. Inzwischen glaube ich, dass genau das falsch ist: Der Arbeitsauftrag sollte überhaupt nicht davon abhängen, wo er später ausgeführt wird. Auf diesen Gedanken hat mich Cloudroom gebracht.
Verksum läuft heute lokal – und das finde ich gut
Ich sehe gerade keinen Grund, warum eine persönliche Version von Verksum zwingend in der Cloud laufen müsste. Ich kann eine App auf meinem Rechner haben, dort liegen meine Agenten, meine Teams, meine Aufgaben und meine Arbeitsumgebung. Solange mein Rechner läuft, können dort auch Agenten arbeiten, und das ist für viele Aufgaben völlig ausreichend. Natürlich gibt es einen offensichtlichen Nachteil: Wenn der Rechner aus ist, arbeitet auch niemand weiter. Deshalb finde ich eine Cloud-Anbindung trotzdem interessant, aber ich möchte daraus keine Grundvoraussetzung machen. Für mich wäre viel logischer: Verksum funktioniert lokal, und wenn ich möchte, kann ich zusätzliche Ausführungskapazität in der Cloud dazunehmen. Dann bezahle ich vielleicht für genau diese Möglichkeit – nicht dafür, dass meine komplette Arbeitsumgebung zwangsläufig irgendwo anders laufen muss.
Cloudroom hat bei mir an einer anderen Stelle geklickt
Beim Beschäftigen mit Cloudroom fand ich weniger die konkrete technische Umsetzung interessant als die Trennung dahinter: Ein Arbeitsauftrag hat eine eigene Identität, und diese Identität hängt nicht daran, auf welchem Rechner oder in welcher Runtime er gerade bearbeitet wird. Das klingt zunächst banal, ist für Verksum aber ziemlich wichtig. Angenommen, ich gebe meinem digitalen Mitarbeiter den Auftrag, einen Blogartikel zu überarbeiten und zur Veröffentlichung vorzubereiten. Dieser Auftrag sollte in Verksum existieren – mit seinem Ziel, seinen Eingaben, seinen Regeln, seinem Status, seinen bisherigen Ergebnissen. Und dann kann Verksum entscheiden, wo dieser Auftrag sinnvoll ausgeführt werden kann: vielleicht lokal auf meinem Mac, vielleicht über Antigravity, vielleicht in einer Cloud-Runtime. Der Auftrag bleibt trotzdem derselbe.
Das Was und das Wo sind zwei verschiedene Dinge
Daraus hat sich eine Trennung ergeben, die ich inzwischen sehr hilfreich finde. Ein Work Contract beschreibt, was geschehen soll und was geschehen darf: Welche Aufgabe soll erledigt werden, welche Daten gehören dazu, welche Ergebnisse werden erwartet, welche Aktionen sind erlaubt, wo braucht es eine Freigabe, wann gilt die Arbeit als abgeschlossen. Davon getrennt steht die Frage, welche Umgebung diesen Auftrag überhaupt ausführen kann. Dafür denke ich inzwischen in Capabilities: Eine Runtime kann beispielsweise Dateien lesen, Dateien schreiben, Terminalbefehle ausführen, auf bestimmte APIs zugreifen, einen Browser verwenden oder ein bestimmtes Modell aufrufen. Eine andere Runtime kann vielleicht nur einen Teil davon. Dann muss Verksum nicht hoffen, dass es schon irgendwie funktionieren wird – es kann vorher feststellen, ob eine Ausführungsumgebung die benötigten Fähigkeiten besitzt, oder eben nicht. Das ist für mich viel sauberer, als Agenten fest an bestimmte technische Umgebungen zu koppeln.
Ein Builder ist kein Codex
Diese Trennung taucht bei mir inzwischen immer wieder auf. Wenn ich in Verksum einen digitalen Mitarbeiter mit der Rolle Builder habe, dann ist dieser Builder nicht automatisch Codex. Er ist auch nicht Claude Code oder Antigravity. Builder ist seine Rolle – darin steht, was ich von ihm erwarte, welche Aufgaben er übernehmen darf, welche Regeln gelten, welche Ergebnisse er liefern soll. Darunter liegt eine Ausführungsumgebung: Heute kann das Antigravity mit einem Gemini-Modell sein, bei einer komplexeren Aufgabe vielleicht Codex, an anderer Stelle Claude Code. Damit wird die Runtime austauschbar, ohne dass ich meinen digitalen Mitarbeiter neu erfinden muss.
Dazu brauche ich noch eine dritte Ebene
Nur weil eine Runtime etwas technisch kann, bedeutet das noch nicht, dass sie es auch tun darf. Deshalb reicht mir die Trennung zwischen Auftrag und Capability nicht. Es braucht zusätzlich eine Instanz, die kontrolliert, welche tatsächliche Wirkung erlaubt ist. Ich denke dabei inzwischen in drei Ebenen: Der Work Contract legt fest, was der Auftrag ist und was innerhalb dieses Auftrags erlaubt ist. Der Capability Contract beschreibt, welche Fähigkeiten die konkrete Ausführungsumgebung besitzt. Und der Execution Guard entscheidet, welche Aktion in dieser Situation tatsächlich ausgeführt werden darf. Das wird spätestens dann wichtig, wenn Agenten nicht mehr nur Text erzeugen. Eine Runtime kann vielleicht Dateien löschen – das bedeutet nicht, dass mein Agent Dateien löschen darf. Ein Browser kann theoretisch einen Button drücken – das bedeutet nicht, dass Verksum ohne Freigabe einen Vertrag abschließen sollte. Ein Coding-Harness kann ein Repository verändern – das bedeutet nicht, dass es automatisch in Produktion deployen darf. Die technische Fähigkeit und die erteilte Berechtigung sind zwei verschiedene Dinge.
Damit könnte Arbeit sogar den Ort wechseln
Besonders interessant finde ich die Vorstellung, dass ein Auftrag nicht dauerhaft an seinem ursprünglichen Ausführungsort hängen muss. Ich beginne vielleicht morgens lokal auf meinem Rechner, ein Agent arbeitet an einer Aufgabe, später schließe ich meinen Laptop. Wenn der Auftrag dafür geeignet ist und ich Cloud-Ausführung freigegeben habe, könnte dieselbe Arbeit an anderer Stelle fortgesetzt werden – nicht als neuer Auftrag, nicht mit einem neuen Agenten, sondern als Fortsetzung derselben Arbeit in einer anderen Execution Runtime. Für mich ist das ein wesentlich interessanteres Cloud-Modell als “Alles muss von Anfang an in unserer Cloud laufen”. Die Cloud wird damit zu einer Ausführungsoption, nicht zum Produkt selbst.
Das passt auch besser zu unterschiedlichen Nutzern: Vielleicht möchte jemand Verksum vollständig lokal verwenden, dann kann er das tun. Ein anderer möchte, dass bestimmte Arbeiten auch nachts weiterlaufen, dann benötigt er Cloud-Kapazität. Ein Unternehmen möchte vielleicht eine eigene kontrollierte Runtime betreiben – auch das sollte möglich sein. Die Arbeitsweise darüber muss sich dadurch nicht verändern. Der Nutzer führt weiterhin dieselben digitalen Mitarbeiter, arbeitet mit denselben Teams, vergibt dieselben Tasks. Welche technische Infrastruktur diese Arbeit am Ende ausführt, muss nicht sein Problem sein.
Dabei muss Verksum auch ehrlich bleiben
Ein Detail finde ich in solchen verteilten Systemen besonders wichtig: Nicht jeder technische Fehler bedeutet automatisch, dass die Aktion nicht passiert ist. Wenn eine Runtime abstürzt, nachdem sie bereits eine externe Wirkung ausgelöst hat, kann der Zustand auch schlicht unbekannt sein. Vielleicht wurde eine Datei geschrieben, vielleicht wurde eine Anfrage versendet, vielleicht hat ein externes System eine Aktion angenommen. Dann darf Verksum nicht einfach behaupten, fehlgeschlagen bedeute automatisch, dass nichts passiert ist. Manchmal muss der Status lauten: unknown. Das ist weniger komfortabel, aber ehrlicher. Und bei einem System, das irgendwann echte Arbeit erledigen soll, ist mir ein ehrliches “Ich weiß es nicht sicher” lieber als eine erfundene Gewissheit.
Für Verksum verändert das mein Cloud-Bild. Ich habe vorher stärker darüber nachgedacht, wann ich Verksum irgendwann “in die Cloud bringen” muss. Inzwischen halte ich diese Frage für zu grob. Vielleicht muss Verksum gar nicht als Ganzes irgendwohin gebracht werden. Vielleicht brauche ich vielmehr unterschiedliche Orte, an denen Arbeit ausgeführt werden kann – lokal, Cloud, Unternehmensinfrastruktur, verschiedene Harnesses. Verksum bleibt darüber die Ebene, die weiß, welche Arbeit existiert, wer sie erledigen soll, was erlaubt ist und welches Ergebnis dabei entstanden ist. Der Auftrag gehört Verksum. Der Ort, an dem er ausgeführt wird, ist Infrastruktur.