Lomo Agent: Architektur und Engineering eines kreativen, kontinuierlich kollaborierenden Agenten

Wer einen kurzen Produktfilm produziert, durchläuft meist Anforderungsgespräche, das Sammeln von Referenzmaterial, Storyboard, Bildgenerierung, Videogenerierung und unzählige Überarbeitungen. Manche dieser Arbeiten sind in Sekunden erledigt, für andere wartet man Minuten; manches kann man dem Modell überlassen, anderes muss der Nutzer bestätigen. Und wenn die erste Version fertig ist, ist die Arbeit noch lange nicht vorbei.

Seit das KI-Zeitalter angebrochen ist, habe ich kaum noch technische Artikel geschrieben. Den Großteil meiner Zeit habe ich damit verbracht, KI in ganz unterschiedlichen Anwendungsszenarien zu erproben.

Viele halten Produktmanager (PMs) für die größten Gewinner des KI-Zeitalters, weil der Weg von der Idee zur Umsetzung dramatisch kürzer geworden ist. Ich glaube allerdings, dass KI Entwicklerinnen und Entwickler womöglich noch tiefgreifender stärkt. Sie löst nach und nach die Fesseln, die die technische Umsetzung der Kreativität bisher angelegt hat, und gibt Technikern die Chance, sich von Code und Engineering-Details zu lösen und das Wesen von Produkten, Architektur und sogar der Mensch-Maschine-Interaktion neu zu betrachten.

Früher haben wir enorm viel Zeit darauf verwendet, Maschinen dazu zu bringen, Anweisungen korrekt auszuführen. Heute können wir endlich mehr Energie in eine deutlich spannendere Frage stecken: Wie bringt man Maschinen dazu, menschliche Absichten wirklich zu verstehen und auf natürlichere Weise mit Menschen zusammenzuarbeiten?

Vor Kurzem haben wir auf Lomote AI den Lomo Agent veröffentlicht. Bei dieser Gelegenheit möchte ich einige Überlegungen, Architekturentscheidungen und Engineering-Praktiken teilen, die ihn von der Idee bis in die Produktion begleitet haben.

Der Artikel behandelt Aufgabenorganisation, Nachrichten-Routing, Durable Execution, asynchrone Jobs, Context Engineering, Langzeitgedächtnis, autonomes Vorantreiben von Arbeit und den gemeinsamen kreativen Workspace. Manche dieser Designs sind bereits umgesetzt, andere werden noch erforscht und validiert. Dabei beziehe ich mich auch auf hervorragende Produkte und technische Arbeiten wie DeepSeek, Manus und Claude Code und erläutere, wie ich zwischen verschiedenen Ansätzen abgewogen habe.

Lomote AI und Lomo Agent

Lomote AI ist die All-in-one-Plattform für KI-gestützte Kreativarbeit, die wir aufbauen. Interessanterweise habe ich in diesem Projekt vor allem die Rolle des Produktmanagers (PM) übernommen und gleichzeitig am Design und Aufbau der zugrunde liegenden Infrastruktur mitgewirkt. Das gab mir die Gelegenheit, aus Produkt- und aus Technikperspektive neu darüber nachzudenken, welche Form und welches Erlebnis ein KI-Kreativwerkzeug bieten sollte.

Derzeit integriert Lomote AI eine Reihe von Modellen zur Generierung und Verbesserung von Bildern, Videos und 3D-Inhalten und bietet eine Asset-Bibliothek, Moodboards sowie visuelle Workflows mit Flows. Unser Ziel ist, dass Kreative in einem einheitlichen Workspace Assets verwalten, Modelle kombinieren und kreative Abläufe orchestrieren können – damit sich KI-Kreativarbeit von verstreuten Modellaufrufen zu einem vollständigen, zusammenhängenden Erlebnis entwickelt.

Diese Fähigkeiten lösen das Problem zersplitterter KI-Kreativwerkzeuge zu einem großen Teil. Mit zunehmender Nutzung wurde uns jedoch klar, dass die Integration der Werkzeuge nur der erste Schritt ist. Die eigentlich spannende Frage lautet, wie man sie so zusammenspielen lässt, dass sie die Produktivität der Nutzer wirklich freisetzen.

In klassischen KI-Kreativabläufen müssen Nutzer die Schritte immer noch selbst planen, Modelle auswählen, Assets organisieren und Kontext sowie Zwischenergebnisse wiederholt zwischen verschiedenen Aufgaben hin- und herreichen. Je komplexer der Ablauf wird, desto mehr Aufwand fließt allein in die Koordination der einzelnen Schritte.

Vor diesem Hintergrund ist Lomo Agent entstanden. Ich möchte, dass sich KI von einem reinen Kreativwerkzeug zu einem Agenten entwickelt, der Absichten versteht, Aufgaben plant und kontinuierlich mitarbeitet. Der Nutzer beschreibt nur das Ziel; der Agent ruft die auf der Plattform vorhandenen Modelle und Werkzeuge auf, organisiert den kreativen Ablauf und passt die Ausführung laufend an das Feedback des Nutzers an.

Für ein solches Erlebnis reichen klassische Tool-Aufrufe in einer einzelnen Runde offensichtlich nicht aus. Wie Aufgaben organisiert werden, wie Kontext verwaltet wird, wie asynchrone Ausführung koordiniert wird und wie der Agent die Arbeit weiter vorantreibt, nachdem der Nutzer gegangen ist – all das wurde zu Architekturproblemen, die wir lösen mussten.

Zum Vergrößern klicken

Zum Vergrößern klicken

Ausgangspunkt: eine kreative Aufgabe, die immer wieder überarbeitet wird

Angenommen, ein Nutzer sagt am Montag: „Mach mir eine Reihe von Markenplakaten im Retro-Stil.“ Der Agent ordnet die Anforderungen und beginnt, Referenzbilder zu generieren. Zwischendurch schiebt der Nutzer eine weitere Aufgabe ein: „Mach übrigens aus dem Katzenbild von gestern ein fünfsekündiges Video.“ Am Mittwoch greift der Nutzer das Thema erneut auf: „Die Plakate von neulich bitte noch etwas wärmer, und die Position des Textes auch anpassen.“

In der alltäglichen Zusammenarbeit zwischen Menschen ist das völlig normal. Für einen Agenten steckt dahinter jedoch die parallele Verwaltung mehrerer Aufgaben, asynchrone Generierung, das Verknüpfen von Kontext und das Wiederauffinden früherer Assets. Je weiter die Arbeit voranschreitet, desto mehr kommen Abbrüche, Wiederholungsversuche, Budgetkontrolle, sich ändernde Nutzerpräferenzen und geräteübergreifende Zusammenarbeit hinzu.

Vor etwa einem Monat begann ich, mir eine Frage zu stellen: Warum muss ein Agent eigentlich um Sitzungen (Sessions) herum aufgebaut sein?

Die meisten Agent-Produkte folgen nach wie vor dem Interaktionsparadigma von Chatbots: Nutzer müssen Sitzungen aktiv anlegen, suchen und pflegen. Bei intensiver Nutzung häufen sich die Sitzungen, und die Kontextverwaltung, die eigentlich die KI übernehmen sollte, wird zur Last für den Nutzer.

Im echten Leben pflegt niemand bewusst „Sitzungen“. Wir wechseln jederzeit das Thema und können Tage später ganz selbstverständlich dort weitermachen, wo wir aufgehört haben. Ein idealer Agent sollte das vielleicht auch können.

Deshalb haben wir in Lomo Agent versucht, das Sitzungskonzept auf Nutzerseite in den Hintergrund zu rücken und Aufgabenerkennung, Kontextisolation und die Verknüpfung mit der Historie dem System zu überlassen. Das ist natürlich nur ein Baustein der Gesamtarchitektur. Um kontinuierliche Kreativarbeit wirklich zu tragen, muss eine ganze Reihe weiterer technischer Probleme gelöst werden: Wiederaufnahme der Ausführung, asynchrones Scheduling, Langzeitgedächtnis, Budgetfreigaben und die Verwaltung gemeinsamer Ergebnisse.

Während ich an der Demo arbeitete, las ich zufällig die Architekturvision des DeepSeek-Teams für einen Super-agent. Interessanterweise waren sie bei Aufgabenorganisation und Kontextverwaltung auf ganz ähnliche Probleme gestoßen. Die Aufgabenteilung zwischen Router und Worker in ihrem Artikel „Super-agent-Design erkunden: auf dem Weg zu autonomeren Agentensystemen“ sowie das spätere Design des Nachrichten-Routings haben mich stark inspiriert und mir geholfen, die Gesamtarchitektur von Lomo Agent weiter zu verfeinern.

Im Folgenden gehe ich anhand des tatsächlichen Designs und der Implementierung auf meine Überlegungen und Abwägungen zu einigen dieser Fragen ein.

1. Aufgabenorganisation: von der Nutzeranfrage zur kontinuierlich vorangetriebenen Aufgabe

Zurück zum Beispiel: Ein Nutzer kann innerhalb weniger Minuten zwischen mehreren Themen wechseln oder eine Aufgabe erst nach Tagen wieder aufgreifen. Für den Agenten ist der Empfang einer Nachricht nur der Anfang. Wichtiger ist zu verstehen, zu welchem Ziel die Nachricht gehört und wie sich der bisherige Fortschritt und die zugehörigen Assets wiederfinden lassen.

Damit stellt sich eine architektonische Abwägung: Teilen sich alle Aufgaben einen einzigen Kontext, stören sich Informationen verschiedener Ziele leicht gegenseitig, und das Kontextfenster des Modells wächst rasant. Isoliert man dagegen strikt nach Sitzungen, reißt man die historischen Verbindungen zwischen Aufgaben auseinander.

Deshalb haben wir in Lomo Agent Interaktionseinstieg, Ausführungskontext und Langzeitgedächtnis in drei relativ unabhängige Ebenen aufgeteilt:

Der Nutzer äußert seine Absicht einfach auf natürliche Weise über einen einheitlichen Einstieg. Das System erkennt, zu welcher Aufgabe eine Nachricht gehört, und legt für Arbeit, die kontinuierlich vorangetrieben werden muss, eine eigene Aufgabe an. Jede Aufgabe besitzt ihren eigenen Kontext, Ausführungsstatus und Verweise auf ihre Ergebnisse und kann bei Bedarf über kontrollierte Abruf- und Freigabemechanismen auf Informationen anderer Aufgaben zugreifen.

Für dieses Design haben wir uns auch angesehen, wie bestehende Produkte das Problem angehen.

ChatGPT etwa stärkt mit sitzungsübergreifendem Gedächtnis die Kontinuität zwischen verschiedenen Unterhaltungen; Claude ermöglicht es mit Mechanismen wie Projects, Wissen und Kontext rund um ein bestimmtes Projekt zu organisieren. Beide Ansätze haben ihre Stärken: Explizite Sitzungs- und Projektgrenzen sind leicht zu verstehen, zu verwalten und zu teilen und geben Nutzern direktere Kontrolle über den Umfang des Kontexts.

In kreativen Szenarien, in denen über lange Zeiträume häufig zwischen Aufgaben gewechselt wird, müssen Nutzer jedoch weiterhin einen Teil der Kontextorganisation selbst übernehmen. Sitzungsübergreifendes Gedächtnis hilft dem Agenten, die Präferenzen und die Historie des Nutzers zu kennen, kann aber eine laufende Aufgabe samt ihrem Fortschritt nicht vollständig abbilden.

Lomo Agent überlässt daher mehr von der Aufgabenorganisation dem System und befreit Nutzer so weit wie möglich von der alltäglichen Sitzungsverwaltung. Automatische Erkennung bedeutet natürlich auch, dass Aufgaben gelegentlich falsch zugeordnet werden können. Deshalb haben wir explizite Einstiege in Aufgaben und Korrekturmechanismen beibehalten und setzen bei eindeutigem Ziel bevorzugt auf deterministisches Routing, um unnötige Modellentscheidungen zu vermeiden.

flowchart TD
    U["Nutzer"] --> E["Einheitlicher Interaktionseinstieg"]
    E --> R["Aufgabenerkennung und Routing"]
    R --> A["Aufgabe A: Markenplakate"]
    R --> B["Aufgabe B: Videoproduktion"]
    R --> C["Einfache Anfrage: direkt im Hauptthread bearbeitet"]
    A <--> M["Langzeitgedächtnis"]
    B <--> M
    C <--> M
    A --> S["Gemeinsame Assets und Ergebnisse"]
    B --> S

Abb. 1: Das Aufgabenorganisationsmodell von Lomo Agent

2. Systemüberblick: Koordinationsschicht, Ausführungsschicht und gemeinsamer Workspace

Nachdem die Art der Aufgabenorganisation feststand, ging es im nächsten Schritt darum, diese Aufgaben tatsächlich zum Laufen zu bringen.

Ein Agent, der kontinuierlich mitarbeiten soll, muss gleichzeitig neue Nutzeranfragen bearbeiten, bestehende Aufgaben vorantreiben, auf externe Generierungsergebnisse warten und auf Änderungen des Nutzers an seinen Werken reagieren. Übernimmt das alles ein einziger Agent, wächst der Kontext rasant und Aufgaben stören sich gegenseitig; legt man dagegen für jede Anfrage einen eigenen Agenten an, entstehen zusätzliche Koordinationskosten.

Aus diesen Überlegungen heraus habe ich für Lomo Agent eine zweistufige Main/Task-Struktur entworfen und in der Ausführungsschicht eine Runtime mit Durable Execution eingeführt. So können verschiedene Aufgaben unabhängig voneinander vorankommen und zugleich über einen gemeinsamen Workspace auf kreative Ergebnisse zugreifen und sie bearbeiten.

2.1 Gesamtarchitektur

Das System gliedert sich in vier Hauptbestandteile:

• Main (Hauptthread): der Einstieg, über den der Nutzer fortlaufend interagiert. Er versteht neue Anfragen, verknüpft sie mit bestehenden Aufgaben, beantwortet einfache Fragen und koordiniert Ausführung und Rückmeldungen über die Aufgaben hinweg.

• Task (Aufgabe): ein unabhängiger Ausführungsraum für ein konkretes kreatives Ziel. Jede Aufgabe pflegt ihr eigenes Briefing, ihren Kontext, ihren Ausführungsplan, ihre Nachrichten-Inbox und ihren Laufzeitstatus.

• Agent Runtime (Laufzeitumgebung): verwaltet Modellinferenz, Tool-Aufrufe, asynchrones Warten, Zustandspersistenz und die Wiederaufnahme der Ausführung und prüft bei jedem Schritt Budget, Berechtigungen und Abbruchbedingungen.

• Shared Workspace (gemeinsamer Workspace): speichert kreative Ergebnisse wie Bilder, Videos, 3D-Modelle, Dokumente, Asset-Sammlungen und Flows-Workflows und erlaubt Nutzern und verschiedenen Aufgaben, im Rahmen ihrer Berechtigungen gemeinsam darauf zuzugreifen und sie zu bearbeiten.

Bei der Aufteilung der Zuständigkeiten übernimmt Main vor allem die Rolle des Routers, während innerhalb eines Task ein Worker die konkrete Arbeit vorantreibt. Router und Worker sind logische Laufzeitrollen und setzen keine unterschiedlichen Basismodelle voraus.

flowchart TB
    U["Nutzer: natürliche Sprache / Kartenaktionen / Bearbeitungen im Workspace"] --> UI["Einheitliche Kollaborationsoberfläche"]
    UI --> GW["Zugangsschicht: interne API / offene API / Echtzeit-Events"]
    GW --> CMD["Annahme von Befehlen und Nachrichten"]

    subgraph CORE["Agent Core"]
      ROUTER["Main / Router: Verstehen und Koordinieren"]
      ROUTING["Zielzuordnung und deterministisches Routing"]
      W1["Task A / Worker: Plakatserie"]
      W2["Task B / Worker: Kurzvideo"]
      CTX["Kontext-Orchestrierung / Komprimierung / Tools nach Bedarf"]
      RT["Durable-Execution-Engine"]
      GUARD["Autorisierung / Budget / Selbstständigkeit"]
    end

    CMD --> ROUTING
    ROUTING --> ROUTER
    ROUTING --> W1
    ROUTING --> W2
    ROUTER --> RT
    W1 --> RT
    W2 --> RT
    RT --> CTX
    RT --> GUARD
    RT --> TOOLS["Kreativwerkzeuge: Bild / Video / Audio / 3D / Canvas / Assets"]
    RT <--> DB[("Persistente Datenbank: Ausführungsfakten und Zustand")]
    RT <--> M["Langzeitgedächtnis: Profil / Fakten / episodische Zusammenfassungen"]
    TOOLS --> ASSET["Gemeinsame Ergebnisse und Workspace"]
    ASSET --> UI
    DB --> EVENTS["Queues / Event-Publishing / Echtzeit-Push"]
    EVENTS --> UI

Abb. 2: Die geschichtete Gesamtarchitektur von Lomo Agent

Ein wesentliches Merkmal dieser Architektur ist, dass Aufgabenausführung und kreative Ergebnisse jeweils einen eigenen, unabhängigen Lebenszyklus haben.

Startet ein Nutzer zum Beispiel im Hauptthread die Arbeit an Plakaten, legt das System dafür eine eigene Aufgabe an. Spätere Referenzbilder, Generierungsprotokolle und der Änderungsverlauf werden von dieser Aufgabe verwaltet, die finalen Ergebnisse dagegen im gemeinsamen Workspace gespeichert. Selbst wenn der Nutzer zu einer anderen Aufgabe wechselt, kann die Plakat-Aufgabe weiter auf Generierungsergebnisse warten und die Ausführung bei Bedarf fortsetzen.

Der Hauptthread muss nur eine Zusammenfassung und den aktuellen Status jeder Aufgabe vorhalten, nicht aber den vollständigen Ablauf jedes Modellaufrufs und jeder Tool-Ausführung dauerhaft speichern. So wird verhindert, dass der Kontext des Hauptthreads mit der Nutzungsdauer unbegrenzt anwächst.

Was wir aus DeepSeeks Super-agent mitgenommen haben

Beim Design hat uns die Super-agent-Architekturvision des DeepSeek-Teams vielfach inspiriert.

Auch sie trennt Koordination und Ausführung, organisiert verschiedene Ziele über eine Router/Worker-Aufteilung und hält die Aufgabenzugehörigkeit mit Mechanismen wie Ticket/Executor fest. Dieses Design eignet sich besonders für Agenten, die lange laufen und immer wieder neue Anweisungen erhalten.

Der von DeepSeek veröffentlichte Forschungsprototyp zielt allerdings vor allem auf Code-Repositories. Repository-Aufgaben haben meist einen relativ klaren Arbeitsumfang, klare Dateiänderungen und klare Lieferergebnisse, während die Grenzen kreativer KI-Aufgaben deutlich unschärfer sind.

So dauert eine einfache Bildgenerierung vielleicht nur einige Dutzend Sekunden, doch ein paar nachträgliche Änderungswünsche des Nutzers können daraus nach und nach ein langfristiges Kreativprojekt machen. Zugleich kann dasselbe Asset von mehreren Aufgaben referenziert und bearbeitet werden.

Deshalb haben wir die grundlegende Arbeitsteilung zwischen Router und Worker beibehalten und für kreative Szenarien Designs wie leichtgewichtige Aufgaben, eine gemeinsame Identität von Ergebnissen und asynchrones Warten ergänzt.

Dieser Ansatz bringt auch neue Komplexität mit sich, etwa bei der Zuordnung von Aufgaben, bei Berechtigungen für gemeinsame Objekte und bei der aufgabenübergreifenden Zustandssynchronisation. Darauf gehen wir in den folgenden Abschnitten jeweils ein.

2.2 Nicht jede Anfrage braucht einen eigenen Worker

Multi-Agent-Architekturen verleiten leicht zu einem Trugschluss: Wenn sich Aufgaben schon aufteilen lassen, dann sollte man doch möglichst alles einem eigenen Agenten übergeben.

Ein unabhängiger Ausführungsraum hat aber seinen Preis. Jeder zusätzliche Worker bedeutet zusätzlichen Kontext, zusätzlichen Laufzeitstatus und zusätzliche Routing-Beziehungen, die gepflegt werden müssen, und auch der Aufwand für Modellaufrufe und Koordination kann dadurch steigen.

Nehmen wir die kreativen Szenarien von Lomo Agent als Beispiel:

Fragt ein Nutzer „Welche Auflösungen unterstützt dieses Videomodell?“, kann Main das direkt beantworten;

bittet er darum, „ein Bild einer roten Tigerkatze zu generieren“, genügt womöglich ein einziger Generierungsauftrag;

„Eine Reihe von Markenplakaten in einheitlichem Stil erstellen“ dagegen umfasst Planung, Asset-Verwaltung, mehrere Generierungsrunden und spätere Überarbeitungen und ist daher besser in einer eigenen Aufgabe aufgehoben.

Deshalb unterscheiden wir bei der Ausführung zusätzlich zwischen leichtgewichtigen Aufgaben (Lightweight Task) und persistenten Aufgaben (Persistent Task).

Leichtgewichtige Aufgaben tragen vor allem eine einzelne Generierung, ihren Ausführungsstatus und die Ergebniskarte, ohne dauerhaft einen Platz in der Aufgabenliste des Nutzers zu belegen. Überarbeitet der Nutzer das Ergebnis immer weiter oder entwickelt sich die Arbeit allmählich zu einem komplexen kreativen Ziel, kann das System sie zu einer persistenten Aufgabe hochstufen und dabei den Kontext und die Ausführungsprotokolle für die weitere Zusammenarbeit erhalten.

Persistente Aufgaben haben einen vergleichsweise vollständigen Lebenszyklus: Sie können fortlaufend Nachrichten empfangen, Pläne ausführen, auf externe Jobs warten und die Arbeit über Tage oder noch längere Zeiträume hinweg wieder aufnehmen.

Diese Unterscheidung ergänzt auch den sitzungslosen Ansatz. Wir wollen den Aufwand für die Sitzungsverwaltung verringern – und ihn natürlich nicht einfach durch eine andere Aufgabenliste ersetzen, die ständig aufgeräumt werden muss.

2.3 Wie eine Zusammenarbeit abläuft

Zurück zum Beispiel mit den Markenplakaten und dem Katzenvideo.

Der Nutzer startet die Plakatproduktion zunächst in Main. Der Router erkennt, dass es sich um ein Ziel handelt, das kontinuierlich vorangetrieben werden muss, legt eine entsprechende Aufgabe an, und ein Worker übernimmt die weitere Planung und Generierung.

Während an den Plakaten gearbeitet wird, bittet der Nutzer darum, aus dem früheren Katzenbild ein Video zu machen. Das System erkennt das als eigenständige Arbeit und legt dafür einen neuen Ausführungsraum an. Beide Aufgaben pflegen ihren eigenen Kontext und können je nach ihrem Status unabhängig voneinander vorankommen.

Sobald ein Plakatentwurf bestätigt werden muss, präsentiert der Agent dem Nutzer die Kandidaten über eine Aufgabenkarte. Der Nutzer wählt direkt auf der Karte aus, und die Nachricht wird anhand der eindeutigen Aufgabenidentität an den zuständigen Worker zurückgeleitet – ohne erneute semantische Bewertung.

Ein paar Tage später sagt der Nutzer im Hauptthread: „Die Plakate von neulich bitte noch etwas wärmer.“ Der Router verknüpft diese neue Anweisung anhand des Aufgabenindex und der Historie mit der ursprünglichen Plakat-Aufgabe.

sequenceDiagram
    participant U as Nutzer
    participant R as Main / Router
    participant A as Task A / Plakate
    participant B as Task B / Video
    U->>R: Erstelle eine Serie von Markenplakaten
    R->>A: Aufgabe und Briefing anlegen
    R-->>U: Aufgabenkarte im Hauptthread anzeigen
    U->>R: Mach übrigens aus der Katze von gestern ein Video
    R->>B: Weitere Aufgabe anlegen
    Note over A,B: Getrennte Kontexte, parallel vorangetrieben
    A-->>U: Plakatentwürfe warten auf Bestätigung
    U->>A: Auf der Karte Entwurf B wählen
    B-->>U: Videogenerierung abgeschlossen
    U->>R: Die Plakate vom letzten Mal etwas wärmer
    R->>A: Rückfrage an die bestehende Aufgabe weiterleiten

Abb. 3: Sequenzdiagramm der Zusammenarbeit mehrerer Aufgaben zwischen Main und Task

Ein Designdetail verdient hier besondere Beachtung: Die Zuordnung einer Nachricht und ihre Ausführung sind zwei verschiedene Phasen.

Der Router kann eine Nachricht der zuständigen Aufgabe zuweisen, doch der Worker verarbeitet sie nicht unbedingt sofort. Vielleicht wartet er gerade auf eine Videogenerierung oder pausiert an einem Punkt, an dem eine Bestätigung des Nutzers aussteht. Neue Nachrichten landen daher zunächst in einer persistenten Inbox, und die Runtime plant ihre Verarbeitung anhand des aktuellen Zustands ein.

Das heißt auch: Die Aufgabenorganisation ist nur der erste Schritt. Mit wachsender Zahl von Aufgaben werden die korrekte Erkennung von Folgeabsichten des Nutzers, die Vermeidung von Fehlrouting und der Umgang mit Nachrichten, die während der Ausführung eintreffen, zu zentralen Fragen der gesamten Architektur.

3. Nachrichten-Routing: Jede Nachricht findet die richtige Ausführungseinheit

Ein einheitlicher Interaktionseinstieg erlaubt Nutzern, ganz natürlich zwischen Aufgaben zu wechseln, überträgt dem System aber auch eine Arbeit, die früher der Nutzer erledigt hat: zu entscheiden, wer jede neue Nachricht bearbeiten soll.

Beispiel: Der Nutzer hat gerade ein Bild generiert und sagt plötzlich: „Mach das von eben blau.“

„Das von eben“ kann sich auf das zuletzt generierte Bild beziehen – oder auf ein Asset aus einer früheren Plakat-Aufgabe.

Liegt die Zuordnung daneben, entsteht im harmlosen Fall eine doppelte Aufgabe, im schlimmsten Fall bearbeitet der Agent das falsche Werk.

Die Genauigkeit des Nachrichten-Routings wirkt sich daher direkt auf die Zuverlässigkeit des gesamten Systems aus. Wir wollten nicht, dass die Zuordnung jeder Nachricht erneut vom Modell erraten wird, sondern folgen einem relativ einfachen Prinzip: Was sich über eindeutige Beziehungen bestimmen lässt, erledigt der Code direkt; nur wenn eine eindeutige Zuordnung fehlt, entscheidet das Modell semantisch.

3.1 Deterministisches und semantisches Routing

Die Annahme von Nachrichten in Lomo Agent verläuft grob in drei Stufen.

Stufe 1: direktes Routing bei eindeutigem Ziel.

Antwortet der Nutzer im Panel einer Aufgabe, klickt er auf eine Aktionsschaltfläche einer Aufgabenkarte oder stößt er eine Änderung an einem eindeutig verknüpften Werk an, weiß das System bereits, zu welchem Ziel die Nachricht gehört, und kann sie direkt anhand der Task-ID oder der Objektbeziehung zustellen.

In diesem Fall würde ein zusätzlicher Modellaufruf zur Zuordnung nur Latenz und das Risiko von Fehlentscheidungen erhöhen.

Stufe 2: semantische Entscheidung durch den Router.

Bei Nachrichten aus dem Hauptthread ohne eindeutige Zielzuordnung muss der Router die aktuelle Anfrage, die jüngsten Interaktionen und den Index bestehender Aufgaben gemeinsam bewerten.

Mögliche Ergebnisse sind:

• eine einfache Anfrage, die Main direkt bearbeitet;

• eine leichtgewichtige Aufgabe, die nur eine einzige Generierung erfordert;

• eine Folgeanweisung, die sich einer bestehenden Aufgabe zuordnen lässt;

• ein neues Ziel, für das eine persistente Aufgabe angelegt werden muss;

• eine offensichtlich mehrdeutige Zuordnung, die eine weitere Bestätigung durch den Nutzer erfordert.

Ein leicht übersehener Punkt: Der Router muss nicht die vollständige Historie aller Aufgaben lesen. In der Regel genügen Ziel, Zusammenfassung, jüngster Status und relevante Objektverweise jeder Aufgabe; erst wenn ein Kandidat erkannt ist, werden die konkreten Details bei Bedarf nachgeladen.

So wird verhindert, dass das Routing mit wachsender Aufgabenzahl selbst zu einem weiteren, stetig anschwellenden Kontext wird.

Derzeit stellen wir bevorzugt einige der zuletzt aktiven Aufgaben mit Indexinformationen wie Ziel, Zusammenfassung und Status bereit. Greift der Nutzer frühere Arbeit auf, wird über Schlüsselwörter und die Vektorähnlichkeit der Zusammenfassungen gesucht, und eine kleine Zahl relevanter Kandidaten wird dem Router zur Entscheidung übergeben. Eine wachsende Zahl von Aufgaben wirkt sich so vor allem auf den Suchraum aus, nicht auf die Kontextlänge, die jede Inferenz mitführen muss.

Ein weiterer häufiger Fehler besteht darin, Arbeit, die der Nutzer eigentlich fortsetzen wollte, als neues Ziel zu behandeln. Deshalb führt das System vor dem Anlegen einer persistenten Aufgabe zusätzlich einen Ähnlichkeitsabgleich mit den 50 jüngsten laufenden Aufgaben durch. Findet es ein möglicherweise doppeltes Ziel, übergibt es die ähnlichsten Kandidaten dem Modell, das entscheidet, ob eine bestehende Aufgabe weitergeführt oder die neue Aufgabe bestätigt angelegt wird. Eine solche Prüfung fängt einen Teil der doppelten Anlagen ab, ersetzt aber nicht die Klärung jeder semantischen Mehrdeutigkeit. Reichen die Anhaltspunkte nicht aus, muss der Nutzer weiterhin ausdrücklich wählen.

Stufe 3: Prüfung von Zuordnung und Status vor der Ausführung.

Auch wenn das Ziel einer Nachricht feststeht, muss das System noch prüfen, ob die Aufgabe gültig ist, ob sie die aktuelle Operation annehmen darf und ob die betroffenen Objekte noch zugänglich sind.

So könnte der Nutzer etwa auf eine bereits archivierte Aufgabe verweisen oder ein bereits gelöschtes Asset bearbeiten wollen. Dass der Router die semantische Zuordnung richtig trifft, heißt nicht, dass die nachfolgende Operation auch tatsächlich ausgeführt werden kann.

flowchart TD
    M["Nutzernachricht oder Interaktionsereignis empfangen"] --> A{"Eindeutige Aufgabenidentität vorhanden?"}
    A -->|Ja| V["Bestehendes Ziel und Zugriffsrechte prüfen"]
    A -->|Nein| B{"Eindeutige Objektbeziehung vorhanden?"}
    B -->|Ja| V
    B -->|Nein| R["Semantische Entscheidung durch den Router"]

    R --> Q["Einfache Anfrage: direkt von Main bearbeitet"]
    R --> L["Einzelne Generierung: leichtgewichtige Aufgabe anlegen"]
    R --> E["Bestehendes Ziel: mit bestehender Aufgabe verknüpfen"]
    R --> N["Eigenständiges Ziel: Anlage einer persistenten Aufgabe vorbereiten"]
    R --> C["Mehrdeutig: Bestätigung beim Nutzer anfragen"]
    N --> S{"Treffer beim Duplikatabgleich mit laufenden Aufgaben?"}
    S -->|Ja| H["Ähnliche Kandidaten bereitstellen, Modell entscheidet"]
    H -->|Mit bestehender Aufgabe verknüpfen| E
    H -->|Neuanlage bestätigt| CREATE["Persistente Aufgabe anlegen"]
    S -->|Nein| CREATE
    CREATE --> NV["Neue Aufgabe und Ausführungsrechte prüfen"]
    L --> NV
    NV --> I["Ausführungsstatus anlegen und Eingabe zustellen"]

    E --> V
    V --> D{"Status des bestehenden Ziels gültig?"}
    D -->|Ja| T["In die Inbox der zuständigen Aufgabe schreiben"]
    D -->|Nein| F["Nutzer informieren oder Ziel neu wählen"]
    C --> U["Nach Antwort des Nutzers neu entscheiden"]
    U --> R

Abb. 4: Der Ablauf des Nachrichten-Routings in Lomo Agent.

3.2 Zugestellt heißt nicht sofort ausgeführt

Beim Nachrichten-Routing gibt es noch ein leicht übersehenes Detail: Die Zuweisung einer Nachricht an einen Worker und der Moment, in dem der Worker sie tatsächlich verarbeitet, können zeitlich auseinanderfallen.

Ein Beispiel: Der Agent führt gerade eine Videogenerierung aus, und der Nutzer ergänzt plötzlich: „Hintergrund bitte in einen Innenraum ändern.“

Zu diesem Zeitpunkt ist die Generierungsanfrage womöglich bereits an den Upstream-Dienst übermittelt und lässt sich nicht sofort ändern. Das System muss die neue Anweisung zunächst speichern und, sobald der Worker eine geeignete Ausführungsgrenze erreicht, anhand des aktuellen Fortschritts über den nächsten Schritt entscheiden.

Deshalb führen wir für jede Aufgabe eine persistente Nachrichten-Inbox. Der Router ist dafür zuständig, Nachrichten in die richtige Inbox zuzustellen; die Runtime entscheidet, wann sie gelesen werden, wie sie in den Kontext einfließen und ob der bestehende Plan angepasst werden muss.

Dabei sind mehrere Fälle zu unterscheiden:

• Nachrichten, die der Worker noch nicht verarbeitet hat, können unter bestimmten Bedingungen zurückgezogen oder ersetzt werden;

• Nachrichten, die bereits in die Modellinferenz eingeflossen sind, müssen die aktuelle Ausführungsgrenze abwarten;

• bereits übermittelte externe Generierungsanfragen lassen sich derzeit nicht direkt zurückziehen. Neue Anweisungen müssen warten, bis der Worker eine geeignete Ausführungsgrenze erreicht; dann wird anhand des Fortschritts entschieden, ob neu generiert wird oder die neuen Vorgaben in späteren Schritten angewendet werden.

Diese Trennung bildet auch die Grundlage für die spätere Wiederaufnahme nach Unterbrechungen, asynchrone Jobs und jederzeitige Eingriffe des Nutzers.

3.3 Was wir uns bei der Nachrichtenzuordnung von Kollaborationstools abgeschaut haben

Beim Interaktionsdesign haben wir uns auch an der Nachrichtenorganisation von Kollaborationstools wie Slack und Feishu orientiert.

Nehmen wir Threads (Antworten zu einem Thema): Antwortet ein Nutzer innerhalb eines bestimmten Threads, weiß das System von vornherein, zu welcher Diskussion die Nachricht gehört, und muss nicht den gesamten Chatverlauf erneut analysieren. Der Vorteil solcher expliziten Verknüpfungen: Sie sind stabil, vorhersehbar und verursachen nahezu keine zusätzlichen Kosten für semantische Erkennung.

Die Interaktionsszenarien von Lomo Agent sind allerdings flexibler. Nutzer antworten vielleicht direkt auf einer Aufgabenkarte – oder kehren in den Hauptthread zurück und erwähnen beiläufig eine Arbeit von vor ein paar Tagen.

Deshalb haben wir beide Wege beibehalten: Eindeutige Aktionen an Aufgaben werden direkt über die strukturierte Identität geroutet; natürliche Sprache im Hauptthread ordnet der Router anhand früherer Aufgaben zu.

Diese hybride Strategie verringert, wie oft das Modell am Routing beteiligt ist, kann Mehrdeutigkeiten aber nicht vollständig beseitigen. Hat ein Nutzer etwa zwei Plakatserien parallel angelegt und sagt nur „Ändere die von letztem Mal“, fehlen dem System womöglich die Anhaltspunkte, um das Ziel zu bestimmen. Dann ist aktives Nachfragen meist zuverlässiger, als eigenmächtig die scheinbar relevanteste Aufgabe zu wählen.

Wie sich mit wachsender Aufgabenzahl Recall, Routing-Genauigkeit und Interaktionsaufwand ausbalancieren lassen, muss weiterhin anhand der realen Nutzung optimiert werden.

Die Zuordnungsentscheidung ist allerdings nicht die letzte Prüfung in der gesamten Kette. Eine überzählige Aufgabe lässt sich meist noch zusammenführen oder schließen; wird eine Nachricht dagegen fälschlich mit der Änderung eines Werks, dem Löschen eines Assets oder einer kostenpflichtigen Generierung verknüpft, kann der Schaden deutlich größer sein. Deshalb trennen wir das Nachrichten-Routing von der eigentlichen Ausführungsautorisierung: Ersteres entscheidet, welcher Aufgabe die Arbeit übergeben wird; Letztere prüft Berechtigungen und Kostengrenzen weiterhin unabhängig davon.

So erfordern nicht widerrufbare Operationen wie das Löschen von Assets oder das Vergessen von Erinnerungen jedes Mal eine Bestätigung durch den Nutzer. Bei kostenpflichtigen Generierungen wird zunächst ein Preis genannt; erst wenn der bestätigungsfreie Betrag, das tägliche bestätigungsfreie Limit oder das genehmigte Planbudget überschritten wird, muss der Nutzer bestätigen. Kostenpflichtige Operationen über die offene API werden ebenfalls einzeln bestätigt. Selbst wenn der Router die richtige Aufgabe bestimmt hat, erhält er dadurch keine Ausführungsrechte über den vom Nutzer autorisierten Rahmen hinaus.

Auch wenn eine Nachricht in der richtigen Aufgabe angekommen ist, kann sich die Ausführung über Minuten oder sogar Tage erstrecken und dabei auf Prozessneustarts, Netzwerk-Timeouts oder Abbrüche durch den Nutzer treffen. Für die zuverlässige Wiederaufnahme ist der Mechanismus der Durable Execution zuständig.

4. Durable Execution: Wiederaufnahme nach Unterbrechungen, Retries und Nebenläufigkeitskontrolle

Nachdem eine Nachricht korrekt an eine Aufgabe geroutet wurde, geht es als Nächstes um die Zuverlässigkeit der Ausführung.

Bei einer gewöhnlichen Chat Completion ist eine Anfrage meist nach wenigen bis einigen Dutzend Sekunden abgeschlossen. Der Arbeitsablauf eines kreativen Agenten ist jedoch weit komplexer: Eine Videoproduktion kann mehrere Runden Modellinferenz, Dutzende Tool-Aufrufe und mehrere externe Generierungsjobs von jeweils einigen Minuten umfassen. Währenddessen kann der Nutzer jederzeit die Anforderungen ändern oder die Aufgabe selbst stoppen.

Ein ganz typisches Fehlerszenario: Der Agent schickt eine Anfrage an einen Videogenerierungsdienst, upstream wird der Job tatsächlich erfolgreich angelegt – doch der Dienstprozess startet genau in dem Moment neu, bevor er die Antwort erhält.

Wie geht man nach der Wiederherstellung damit um? Ein direkter Retry kann zu doppelter Generierung und doppelter Abrechnung führen; nimmt man dagegen an, die Anfrage sei erfolgreich gewesen, wartet man womöglich ewig auf einen Job, der in Wirklichkeit nie angelegt wurde.

Solche Probleme haben uns klargemacht, dass der Ausführungsprozess eines Agenten einen persistenten Zustand braucht, der unabhängig vom Modellkontext und vom Dienstprozess ist.

Deshalb habe ich in Lomo Agent einen Mechanismus für Durable Execution (dauerhafte, wiederaufnehmbare Ausführung) eingeführt. Die Datenbank hält zentrale Ausführungszustände, Modellentscheidungen und Ergebnisse von Tool-Aufrufen fest; die Job-Queue übernimmt Scheduling und Wiederaufnahme der Ausführung; Echtzeit-Events melden dem Nutzer den Fortschritt. Selbst wenn der ausführende Prozess unterbrochen wird, kann das System anhand der gespeicherten Fakten bestimmen, was als Nächstes zu tun ist.

Beim Design haben wir uns am Ansatz der Durable Execution von Temporal orientiert. Temporal lässt Geschäftsprozesse über Workflow-Historie, Task-Scheduling und Retry-Mechanismen die Lebensdauer einzelner Prozesse überdauern – ein Vorteil, der bei komplexen, lang laufenden Workflows besonders zum Tragen kommt.

Allgemeine Workflow-Engines bringen allerdings auch eigene Modellierungs- und Betriebskosten mit. Die Ausführung in Lomo Agent muss zusätzlich Modellinferenz, dynamische Tool-Aufrufe, kreative Zustände und Nutzerinteraktion verwalten. Deshalb haben wir rund um die eigenen Datenstrukturen des Agenten ein Ausführungsjournal und einen Mechanismus für ereignisbasiertes Scheduling implementiert. Übernommen haben wir die Engineering-Idee der Durable Execution – Temporal selbst setzen wir nicht ein.

4.1 Erst die Entscheidung persistieren, dann das Tool aufrufen

Ein klassischer Agent Loop folgt meist einem einfachen Ablauf:

Kontext lesen → Modellinferenz → Tool aufrufen → Ergebnis erhalten → weiter schlussfolgern.

Bei kurzen Aufgaben ist das relativ geradlinig umzusetzen. Erstreckt sich die Ausführung jedoch über mehrere Prozesse, externe Dienste und Abrechnungssysteme, kann eine Unterbrechung an jeder beliebigen Stelle zu inkonsistenten Zuständen führen.

Wir unterteilen die Ausführung in eine Folge von Steps. Ein Step kann eine Modellinferenz und eine vom Modell vorgeschlagene Gruppe von Tool-Aufrufen umfassen.

Bevor ein Tool ausgeführt wird, persistiert die Runtime zuerst die Entscheidung des Modells und die anstehenden Aufrufe. Jeder Tool-Aufruf hat eine stabile fachliche Kennung; Status, Eingaben und Ergebnis werden im Ausführungsjournal festgehalten.

Wird ein Worker wieder aufgenommen, kann er so anhand des Journals erkennen, welche Operationen bereits abgeschlossen sind, welche wiederholt werden dürfen und bei welchen zunächst der externe Zustand abgeglichen werden muss – ohne das Modell erneut aufzurufen, um dieselbe Runde von Tool-Entscheidungen zu erzeugen.

flowchart TD
    S["Inbox und aktuellen Ausführungsstatus lesen"] --> L["Modellinferenz: Antwort und beabsichtigte Tool-Aufrufe erzeugen"]
    L --> P["Modellergebnis und anstehende Aufrufe atomar committen"]
    P --> X{"Liegt für den Aufruf bereits ein persistiertes Ergebnis vor?"}
    X -->|Ja| REUSE["Vorhandenes Ergebnis wiederverwenden"]
    X -->|Nein| K{"Könnte er bereits ausgeführt worden sein?"}
    K -->|Nein| EXEC["Tool-Aufruf absetzen"]
    K -->|Ja| I{"Idempotenter Retry möglich?"}
    I -->|Ja| EXEC
    I -->|Nein| UNKNOWN["Ergebnis als unbekannt markieren, an das Modell zurückgeben"]
    EXEC --> SAVE["Tool-Ergebnis und fachlichen Zustand persistieren"]
    REUSE --> NEXT["Weiter mit dem nächsten Aufruf oder Step"]
    SAVE --> NEXT
    UNKNOWN --> CHECK["Erst aktuellen Zustand abfragen, dann über Retry entscheiden"]
    CHECK --> NEXT

Abb. 5: Der Ablauf der Durable Execution eines Agenten.

Hier kommt ein zentrales Konzept ins Spiel: Idempotenz.

Angenommen, der Nutzer genehmigt die Generierung eines Videos, und das System übermittelt dieselbe Anfrage wegen eines Netzwerk-Timeouts doppelt. Idealerweise sollten beide Übermittlungen demselben Generierungsauftrag entsprechen – es dürfen weder zwei identische Videos entstehen noch doppelt abgerechnet werden.

Bei Downstream-Diensten, die Idempotenzschlüssel unterstützen, lässt sich mit einer stabilen Aufrufkennung deduplizieren; für plattforminterne Bestell- und Abrechnungsprozesse sorgen Aufruf-ID, Bestell-ID und Unique Constraints dafür, dass wiederholte Anfragen keinen neuen fachlichen Effekt haben.

Unterstützt eine Upstream-Generierungsschnittstelle jedoch weder Idempotenzschlüssel noch eine Abfrage des Anfrageergebnisses, kann das System nach einem Netzwerk-Timeout faktisch nicht feststellen, ob der Job bereits angelegt wurde.

In diesem Fall kann Durable Execution keine Exactly-once-Garantie (genau einmalige Ausführung) aus dem Nichts herbeizaubern.

Hier unterscheiden wir zwei Fälle: Hat das Ausführungsjournal bei einem der wenigen nicht idempotenten Tools bereits started vermerkt, liegt aber nie ein Ergebnis vor, führt die Runtime den Aufruf nicht direkt erneut aus, sondern gibt dem Modell ein mit outcome_unknown markiertes Ergebnis zurück, damit es zuerst den aktuellen Zustand prüft und dann über das weitere Vorgehen entscheidet. Idempotente Aufrufe lassen sich dagegen mit der ursprünglichen Aufrufkennung erneut abspielen.

Eine weitere Ebene der Unsicherheit liegt zwischen dem Generierungsdienst und der Upstream-Schnittstelle. Hier verfolgen wir eine konservativere Strategie: Ist das Ergebnis einer Übermittlung unklar, wird sie als fehlgeschlagen gewertet, und es wird nicht automatisch erneut eine Anfrage an den Upstream-Dienst gestellt. Beide Fälle heißen scheinbar „Ergebnis unbekannt“, doch im einen geht es um die Wiederaufnahme von Tool-Aufrufen des Agenten, im anderen darum, keine doppelten, tatsächlich kostenpflichtigen Generierungsjobs anzulegen.

Temporal steht bei Retries von Activities vor demselben Problem. Eine Workflow-Engine kann Ausführungen zuverlässig einplanen und wiederholen, doch die Seiteneffekte externer APIs erfordern weiterhin fachliche Idempotenzmechanismen.

Bei kostenpflichtigen Generierungsdiensten ist diese Grenze besonders wichtig. Eine fehlgeschlagene Ausführung lässt sich wieder aufnehmen – eine doppelte Abrechnung lässt sich dagegen nicht unbedingt automatisch korrigieren.

4.2 Worker-Übernahme und Fencing Token

Durable Execution löst das Problem der Wiederaufnahme nach einem Prozessabbruch. Es gibt aber einen subtileren Fall: Der ursprüngliche Worker ist möglicherweise gar nicht wirklich beendet.

Beispiel: Worker A verliert während der Ausführung wegen Netzwerkschwankungen kurzzeitig die Verbindung. Das System erkennt den Timeout, und Worker B übernimmt die Aufgabe und führt sie weiter aus. Ein paar Sekunden später ist Worker A wieder verbunden und versucht, sein gerade fertiggestelltes Ergebnis zu committen.

Nun existieren im System womöglich zwei Worker, die sich beide für ausführungsberechtigt halten. Ohne Schutzmechanismus könnte der alte Worker den neuen Zustand überschreiben oder sogar eine bereits gestoppte Aufgabe wieder in die Ausführung bringen.

Deshalb verwenden wir einen Mechanismus von Ausführungsgenerationen, ähnlich einem Fencing Token.

Sobald eine Aufgabe von einem neuen Ausführenden übernommen wird, erhöht die Runtime die Ausführungsgeneration dieser Aufgabe. Ein Worker muss beim Committen von Zustandsänderungen die Generation, die er hält, mitliefern und prüfen lassen.

Ist die Generation in der Datenbank bereits höher, wird der Commit des alten Workers abgelehnt.

Man kann sich das so vorstellen: Das System erlaubt einem neuen Ausführenden, die Arbeit zu übernehmen, und entzieht dem alten zugleich das Recht, den internen Zustand weiter zu verändern.

Auch wenn der Nutzer eine Aufgabe selbst stoppt, verhindern die Prüfung des Laufzeitstatus und der Ausführungsgeneration, dass ein alter Worker nach seiner Rückkehr weitermacht.

Der Fencing Token schützt allerdings nur die Konsistenz des systemeigenen Zustands. Hat der alte Worker bereits eine Videogenerierung bei einer externen Plattform angestoßen, macht der Verlust des internen Ausführungsrechts diese entfernte Operation nicht automatisch rückgängig.

Selbst wenn der Nutzer eine Aufgabe bereits gestoppt hat, kann eine zuvor übermittelte externe Generierung daher weiterlaufen. Der Generierungsdienst verfolgt das Ergebnis des Jobs weiter und schließt die zugehörige Abrechnung ab; ein verspätet eintreffendes Abschlussereignis weckt die gestoppte Aufgabe jedoch nicht wieder auf und ändert auch den bereits abgebrochenen Ausführungsstatus nicht.

4.3 Wie neue Nachrichten des Nutzers während der Ausführung behandelt werden

Eine weitere Klasse von Problemen entsteht dadurch, dass Nutzer in Echtzeit eingreifen.

Angenommen, der Agent ruft gerade das Modell auf, um eine Reihe von Plakaten zu generieren. Da schreibt der Nutzer: „Kein weißer Hintergrund, lieber Dunkelblau.“

Diese Nachricht erreicht den Server womöglich noch vor dem Ende der Modellinferenz, doch die laufende Modellanfrage hat sie tatsächlich nicht gelesen.

Würde das System den Verlauf rein nach dem Erstellungszeitpunkt der Nachrichten zusammensetzen, entstünde ein verwirrender Zustand: Es sähe so aus, als hätte das Modell seine Entscheidung nach der Änderung durch den Nutzer getroffen, obwohl es von der neuen Anweisung in Wirklichkeit gar nichts wusste.

Um das zu lösen, behandeln wir den Empfang und die Verarbeitung von Nachrichten getrennt.

Neue Nachrichten landen zunächst in der persistenten Inbox der zuständigen Aufgabe. Der Worker liest diese Eingaben an der nächsten sicheren Ausführungsgrenze und bringt sie zusammen mit dem aktuellen Aufgabenstatus in den Modellkontext ein.

Das System hält fest, in welchem Step eine Nachricht tatsächlich verarbeitet wurde, statt die Reihenfolge allein am Sendezeitpunkt festzumachen.

So lassen sich die Phasen klar unterscheiden: Die Anweisung des Nutzers ist zugestellt, das Modell hat sie verstanden, und die zugehörige Operation wurde ausgeführt.

Ist eine Generierungsanfrage bereits an den Upstream-Dienst übermittelt, ändert eine spätere Änderung den gerade entstehenden Inhalt natürlich nicht automatisch. Die aktuelle Version kann solche Anfragen auch nicht zurückziehen; der Worker kann erst an der nächsten sicheren Ausführungsgrenze entscheiden, ob er neu generiert oder die neue Vorgabe in späteren Schritten anwendet. Hat der Nutzer die Aufgabe bereits gestoppt, führt eine danach abgeschlossene alte Generierung nicht dazu, dass die Aufgabe erneut ausgeführt wird.

Auch die Oberfläche muss diesen Zustand für den Nutzer korrekt wiedergeben, damit „Nachricht erhalten“ nicht als „Die laufende Generierung wurde bereits an die neue Vorgabe angepasst“ missverstanden wird.

Bei zeitaufwendigen Generierungen wie Video, Audio und 3D muss der Worker zudem während des Wartens auf externe Ergebnisse seine Ausführungsressourcen freigeben und nach Eintreffen des Ereignisses präzise fortsetzen.

4.4 Ausführungsjournal und Konsistenzgrenzen des Schedulings

Bisher ging es darum, wie Modellentscheidungen persistiert werden und wie Ausführungsgenerationen verhindern, dass ein alter Worker nach der Übernahme einer Aufgabe weiter den Zustand verändert. Im realen Betrieb gibt es jedoch noch ein leicht übersehenes Problem: Wie wird eine Aufgabe wieder aufgenommen, wenn die Datenbank anstehende Arbeit bereits verzeichnet hat, die Queue-Nachricht zum Aufwecken des Workers aber verloren gegangen ist?

In Lomo Agent pflegen wir den Ausführungszustand über Runden (Turns) und ein Journal der Tool-Aufrufe. Eine Runde hält Laufzeitstatus, Ausführungsgeneration, Lease und Checkpoint fest; Tool-Aufrufe tragen „Runde + Step-Nummer + Aufrufnummer“ als stabile Kennung. Nach der Antwort des Modells speichert die Runtime in derselben Transaktion das Entscheidungsergebnis, die anstehenden Aufrufe und die bereits verarbeiteten Inbox-Nachrichten; vor der Ausführung eines Tools wird started vermerkt, nach Abschluss wird das Ergebnis zusammen mit dem Status done gespeichert. So kann die Wiederaufnahme anhand der vorhandenen Einträge Ergebnisse wiederverwenden oder sicher wiederholen, ohne dass das Modell erneut erraten muss, was zuvor geschehen ist. Aufrufe, die sich nicht sicher wiederholen lassen, behalten den Zustand „Ergebnis unbekannt“ und werden der nachfolgenden Entscheidung überlassen.

Beim Scheduling haben wir für das Einreihen von Runden kein transaktionales Outbox eingeführt, sondern nutzen die Datenbank als Quelle der Ausführungsfakten; die Queue ist vor allem dafür da, Worker aufzuwecken. Die Scheduling-Nachricht wird erst nach dem Commit der Runde gesendet; schlägt das Einreihen fehl, entdeckt ein Watchdog im Hintergrund die Aufgabe anhand des Datenbankzustands erneut. Derzeit prüft der Watchdog alle 10 Sekunden und achtet vor allem auf abgelaufene Leases, lange Wartezeiten in der Queue sowie Aufgaben, für die unverarbeitete Nachrichten, aber keine aktive Runde existieren. Queue-Jobs werden über Runden-ID und Ausführungsgeneration gekennzeichnet, was doppeltes Einreihen derselben Generation reduziert; selbst bei doppeltem Scheduling verhindert die Runtime über Ausführungsstatus- und Generationsprüfung veraltete Schreibvorgänge. Wir nehmen damit eine begrenzte Wiederaufnahmeverzögerung in Kauf und erhalten dafür einen einfacheren Scheduling-Mechanismus; Event-Pushes an die Oberfläche und externe Generierungsjobs behalten jeweils ihre eigenen Mechanismen für zuverlässige Zustellung und Kompensation.

Ein weiteres Risiko entsteht durch die nebenläufige Ausführung von altem und neuem Worker. Ein Fencing Token kann verhindern, dass ein alter Worker den internen Zustand überschreibt, aber keine bereits abgesetzten externen Anfragen rückgängig machen. Deshalb legen wir den Idempotenzschlüssel kostenpflichtiger Generierungen fest auf „Runde + Step-Nummer + Aufrufnummer“, ohne die Ausführungsgeneration. Selbst wenn alter und neuer Worker denselben Aufruf doppelt übermitteln, verknüpft die Generierungsschicht der Plattform ihn über einen Unique Constraint auf „Workspace + Idempotenzschlüssel“ mit derselben Bestellung und dedupliziert die interne Abbuchung. Das begrenzt doppelte Bestellungen und Abrechnungen innerhalb der Plattform, bedeutet aber nicht, dass externe Upstream-Dienste von Haus aus eine Exactly-once-Garantie bieten. Fällt das System dagegen aus, bevor die Modellentscheidung persistiert ist, kann dieser Step erneut inferiert werden. Angesichts der aktuellen, von Mediengenerierung dominierten Kostenstruktur nehmen wir diese vergleichsweise begrenzten Kosten doppelter Inferenz in Kauf.

Schwieriger ist der Fall, dass das Ergebnis einer Upstream-Übermittlung unklar ist. Ein Timeout kann bedeuten, dass die Übermittlung fehlgeschlagen ist – oder dass der Upstream-Dienst den Job bereits angelegt hat, die Antwort aber nicht zurückkam. Um doppelte Generierungen zu vermeiden, übermittelt der Generierungsdienst solche Anfragen derzeit nicht automatisch erneut; sobald eine Upstream-Job-ID vorliegt, wird sie sofort persistiert, damit nach einer Unterbrechung weiter gepollt werden kann. Stürzt der Prozess jedoch genau zwischen dem Erhalt der ID und dem Speichern ab, lässt sich dieser Job derzeit nicht zurückverfolgen. Das System kann dann nur nach dem Timeout gemäß den Regeln eine Rückerstattung veranlassen, und die Plattform trägt die möglicherweise bereits angefallenen Upstream-Kosten.

Diese Designs beseitigen nicht alle Fehlerfenster, legen aber die Grenzen des Vorgehens in den verschiedenen Fällen klar fest: Was sich als abgeschlossen bestätigen lässt, wird direkt wiederverwendet; was sich sicher wiederholen lässt, wird weiter ausgeführt; was sich nicht bestätigen lässt, wird nicht blind erneut übermittelt. Für einen dauerhaft laufenden Agenten bedeutet Zuverlässigkeit nicht, dass kein Schritt je fehlschlägt, sondern dass das System nach einer Unterbrechung anhand der vorhandenen Fakten weiterhin kontrollierte Entscheidungen zur Wiederaufnahme treffen kann.

5. Asynchrone Generierung: Job-Lebenszyklus und ereignisgesteuertes Aufwecken

Die oben beschriebene Durable Execution löst vor allem, wie ein Agent während der Laufzeit Zustände festhält, mit Fehlern umgeht und die Ausführung wieder aufnimmt. In der KI-Kreativarbeit gibt es aber noch eine Eigenschaft, an der man nicht vorbeikommt: Viele Tool-Aufrufe sind von Natur aus asynchron.

Eine Bildgenerierung dauert vielleicht nur ein paar Sekunden, Video- und 3D-Jobs dagegen mehrere Minuten oder noch länger. Nach dem Absenden liefert der Upstream-Dienst meist nur eine Job-ID zurück; das eigentliche Ergebnis muss per Polling oder Callback abgeholt werden.

Ließe man den Worker dauerhaft auf das Ende externer Jobs warten, würde das nicht nur Ausführungsressourcen binden, sondern auch die Modellinferenz an die unkontrollierbare Dauer externer Generierungen koppeln.

Deshalb verwalten wir den Ausführungslebenszyklus des Agenten und den Lebenszyklus externer Generierungsjobs getrennt.

5.1 Absenden, warten und Ausführung fortsetzen

Ruft der Worker ein Generierungstool auf, übermittelt das Tool zunächst eine Anfrage an den zuständigen Dienst und gibt die Kennung des Generierungsjobs zurück. Anschließend speichert die Runtime die Verknüpfung zwischen dem Job und der aktuellen Aufgabe, einschließlich Job-ID, Wartestatus und der für die weitere Ausführung benötigten Informationen.

Nach dem Absenden kann der Worker die aktuelle Ausführung suspendieren: Er muss das Modell nicht fortlaufend aufrufen und auch keine lang laufende Inferenzanfrage offenhalten.

Während der Wartezeit können Fortschrittsänderungen des Generierungsdienstes direkt als fachliche Events an das Frontend gepusht und auf der Aufgabenkarte als aktueller Status angezeigt werden.

Ist der Job abgeschlossen, entscheidet die Runtime anhand dessen, ob die folgenden Schritte vom Generierungsergebnis abhängen, ob der Worker wieder aufgeweckt wird.

sequenceDiagram
    participant W as Task Worker
    participant G as Generierungsdienst
    participant S as Persistente Runtime
    participant UI as Aufgabenkarte

    W->>G: Generierungsanfrage absenden (stabile fachliche Kennung)
    G-->>W: Job-ID zurückgeben
    W->>S: Job-Verknüpfung und Wartestatus speichern
    Note over W,S: Oben der Normalpfad – Fehler beim Speichern nach der Übermittlung siehe 4.4
    S-->>UI: Status auf „wird generiert“ setzen

    Note over W: Worker suspendiert, Ausführungsressourcen freigegeben

    G-->>S: Fortschrittsereignis
    S-->>UI: Fortschritt aktualisieren (ohne Modellinferenz)

    G-->>S: Abschlussereignis
    S->>S: Job-Status aktualisieren und Ergebnis speichern
    S-->>UI: Generierungsergebnis anzeigen

    alt Folgeschritte hängen vom Ergebnis ab
        S->>W: Event zur Wiederaufnahme zustellen
        W->>W: Aktuellen Zustand lesen und weiter ausführen
    else Derzeit keine weitere Inferenz nötig
        Note over UI: Nur Ergebnis und Aufgabenstatus aktualisieren
    end

Abb. 6: Der Ausführungsablauf asynchroner Generierungsjobs (Normalpfad).

Der unmittelbare Nutzen dieses Designs ist eine bessere Ressourcenauslastung. In den Minuten, in denen auf eine Videogenerierung gewartet wird, muss das System nur den persistenten Zustand und die nötige Ereignisverarbeitung aufrechterhalten, ohne fortlaufend Inferenzressourcen des Agenten zu belegen.

Zugleich lassen sich Generierungsfortschritt und Benutzeroberfläche unabhängig voneinander aktualisieren. Nutzer sehen den Job-Status in Echtzeit, ohne darauf warten zu müssen, dass der Worker erneut das Modell aufruft.

5.2 Auch asynchrone Events brauchen zuverlässige Verarbeitung

Sind Generierungsjobs einmal ereignisgesteuert, muss man sich auch um die Zuverlässigkeit der Events selbst kümmern.

Ein Upstream-Dienst kann zum Beispiel wegen Netzwerkproblemen eine Abschlussmeldung mehrfach senden oder nach einem fehlgeschlagenen Callback nicht sofort erneut zustellen. Bei mehreren gleichzeitig laufenden Generierungsjobs können Fortschrittsereignisse zudem in falscher Reihenfolge eintreffen.

Die Ereignisverarbeitung lässt sich daher nicht einfach als „Callback erhalten, weiter ausführen“ verstehen.

Wir müssen Statusaktualisierungen von Generierungsjobs auf Grundlage des persistierten Job-Status vornehmen und sicherstellen, dass doppelte Events weder zu doppelten Schreibvorgängen noch zu doppelter Abrechnung oder doppeltem Aufwecken des Workers führen.

Bei Events, die in falscher Reihenfolge eintreffen können, darf ein veralteter Fortschritt außerdem kein Endergebnis überschreiben. Ist ein Job etwa bereits abgeschlossen und trifft danach verspätet eine Meldung „wird generiert“ ein, darf der Status nicht zurückfallen.

Hinzu kommt, dass externe Callbacks nicht unbedingt zuverlässig sind. Bei Jobs, für die lange kein Ergebnis eingetroffen ist, kann der Status anhand der Job-ID über die Abfrageschnittstelle des Upstream-Dienstes abgeglichen und der Fortschritt bei Bedarf per kompensierendem Polling wiederhergestellt werden.

Das greift mit der zuvor beschriebenen Durable Execution ineinander: Die Runtime pflegt einen vertrauenswürdigen Ausführungszustand, und das System für asynchrone Jobs übersetzt Veränderungen während der externen Generierung in wiederaufnehmbare fachliche Events.

5.3 Wann muss der Worker aufgeweckt werden?

Eine weitere Frage hängt direkt mit den Kosten für Modellaufrufe zusammen: Muss nach jedem abgeschlossenen Generierungsjob das Modell erneut aufgerufen werden?

Die Antwort hängt davon ab, ob für die Aufgabe noch Arbeit ansteht, die eine Entscheidung des Agenten erfordert.

Bittet der Nutzer etwa nur darum, „ein Katzenbild zu generieren“, genügt es, das Ergebnis nach Abschluss direkt anzuzeigen. Es gibt keinen Grund, den Worker erneut aufzuwecken, damit das Modell das bereits generierte Bild noch einmal beschreibt.

Verlangt der Nutzer dagegen „eine Reihe von Markenplakaten in einheitlichem Stil“, kann das aktuelle Generierungsergebnis zur Eingabe für spätere Schritte werden. Der Agent muss die vorhandenen Ergebnisse prüfen, die Ausführungs-Checkliste lesen und anhand des aktuellen Ziels entscheiden, ob er weiter generiert oder auf die Bestätigung des Nutzers wartet.

Deshalb behandeln wir das Abschlussereignis einer Generierung und die Entscheidung über das Weiterlaufen des Agenten getrennt.

Der Generierungsdienst meldet das Ergebnis; die Runtime entscheidet anhand von Aufgabenplan, Warteabhängigkeiten, Freigaben und aktuellem Ausführungsstatus, ob der Worker wieder aufgenommen werden muss.

So wird auch vermieden, dass eine Vielzahl von Fortschrittsereignissen direkt beim Modell landet. Ein mehrminütiger Videojob kann upstream zahlreiche Statuswechsel erzeugen, doch die allermeisten erfordern nur ein Update im Frontend und rechtfertigen keine neue Inferenz.

Dieses ereignisgesteuerte Design ähnelt den Mechanismen für asynchrones Warten in allgemeinen Workflow-Engines und Job-Queues. Bei Lomo Agent geht es uns darüber hinaus darum, es mit kreativen Zielen, Ausführungs-Checklisten und dem Review-Prozess des Nutzers zu verbinden.

Ist zum Beispiel eine Videoeinstellung fertig generiert und stehen noch weitere Einstellungen aus, für die der Nutzer die Fortsetzung bereits freigegeben hat, kann die Runtime die entsprechende Aufgabe wieder aufnehmen. Ist in der aktuellen Phase dagegen ein Review durch den Nutzer nötig, sollte sie im Zustand „wartet auf Bestätigung“ verharren.

Ein abgeschlossener Generierungsjob bedeutet nur, dass ein bestimmter Tool-Aufruf beendet ist. Ob die gesamte kreative Aufgabe weiterlaufen soll, muss zusätzlich anhand von Plan, Budget und Freigaben entschieden werden.

Das führt zum späteren Mechanismus des autonomen Vorantreibens: Wie erkennt das System, wenn der Agent eine Phase abschließt oder sogar die aktuelle Inferenzrunde beenden will, ob die Aufgabe wirklich erledigt ist und ob die Ausführung fortgesetzt werden sollte?

6. Context Engineering: gültigen Zustand in einem begrenzten Fenster halten

Sobald ein Agent lange, mehrphasige kreative Aufgaben bearbeitet, wird die Kontextverwaltung zu einem wichtigen Faktor für Ausführungsqualität und Kosten.

Eine kreative Aufgabe, die sich über mehrere Tage erstreckt, kann Hunderte Nachrichten, Dutzende Tool-Aufrufe sowie zahlreiche Bilder, Videos und Workflow-Zustände ansammeln. Auch wenn die Kontextfenster der Modelle immer größer werden, ist es nicht realistisch, all das in jede Inferenz zu packen.

Zum einen bedeutet ein langer Kontext höhere Token-Kosten und mehr Inferenzlatenz; zum anderen können zu viele historische Informationen das Urteil des Modells über das aktuelle Ziel stören. Gerade wenn der Nutzer seine Anforderungen mehrfach geändert hat, beeinflussen frühere, längst ungültige Vorgaben, die noch im Kontext stehen, leicht die weitere Generierung.

Deshalb betrachten wir die Kontextverwaltung als eigenständiges Engineering-Problem: Wie erhält das Modell bei jedem Inferenzschritt ausreichende, relevante und noch gültige Informationen?

6.1 Kontextschichten und Prompt Cache

Lomo Agent organisiert den Modellkontext in mehreren Schichten: ein relativ stabiles Systempräfix, komprimierte Historie, jüngste Interaktionen und der dynamische Zustand, den der aktuelle Ausführungsschritt benötigt.

flowchart LR
    A["Stabiles Präfix: Systemregeln / Kern-Tools / Profil-Snapshot"] --> B["Abschnittsweise Verlaufszusammenfassungen"]
    B --> C["Jüngste Nachrichten und wichtige Tool-Ergebnisse"]
    C --> D["Dynamisches Ende: Briefing / Checkliste / Budget / Objektänderungen"]
    D --> E["Eingaben dieses Schritts und bedarfsweiser Abruf"]

Abb. 7: Wie Lomo Agent den Kontext organisiert.

Ein Faktor hängt dabei eng mit den tatsächlichen Inferenzkosten zusammen: Prompt Caching. Mit „Prompt Cache“ ist im Folgenden die Prompt-Caching-Funktion gemeint, die Modellanbieter auf API-Ebene bereitstellen; wie sie konkret umgesetzt ist und was sich wiederverwenden lässt, legt der jeweilige Anbieter fest.

Modelldienste, die diese Funktion unterstützen, können Prompt-Präfixe wiederverwenden, die ihren Caching-Regeln entsprechen, und so die Kosten wiederholter Verarbeitung senken. Deshalb halten wir Systemregeln, Kern-Tools und relativ stabile Profilinformationen möglichst am Anfang des Kontexts und platzieren den Aufgabenzustand, der sich in jedem Schritt ändern kann, am Ende.

Würde man hochdynamische Informationen an den Anfang des Präfixes setzen, könnte auch der nachfolgende, eigentlich stabile Inhalt den Cache nicht mehr wirksam nutzen.

Die tatsächliche Trefferquote des Prompt Cache hängt allerdings auch vom Modellanbieter, vom Request-Routing und von der Caching-Strategie ab. Das Kontextlayout kann nur die Voraussetzungen für Cache-Wiederverwendung schaffen; der tatsächliche Nutzen muss anhand realer Aufrufdaten überprüft werden.

Ein stabiles Präfix bedeutet zudem nicht, dass das Profil lange nicht aktualisiert werden darf. Ändert ein Nutzer seine Präferenzen oder verlangt, dass bestimmte Informationen vergessen werden, muss der entsprechende Profil-Snapshot sofort ungültig werden, damit veraltete Informationen nicht über die Cache-Wiederverwendung weiter in die Inferenz einfließen.

6.2 Bedarfsgesteuertes Laden von Tools: Je mehr Fähigkeiten, desto teurer der Kontext

Lomote AI integriert zahlreiche kreative Modelle und Werkzeuge aus unterschiedlichen Bereichen: Bildgenerierung, Videogenerierung, 3D, Asset-Verwaltung, Dokumentbearbeitung und Flows-Workflows.

Würde man Namen, Parameter und Gebrauchsanweisungen aller Tools in jede Modellanfrage packen, stiege nicht nur der Token-Verbrauch; das Modell könnte sich auch zwischen vielen ähnlichen Tools falsch entscheiden.

Deshalb teilen wir Tools in zwei Kategorien ein: Kern-Tools, die dauerhaft sichtbar sein müssen, und Tools, die je nach Fähigkeitsbereich dynamisch geladen werden.

Plant der Agent beispielsweise gerade ein Storyboard, braucht er vielleicht nur Dokument- und Asset-Tools; erst in der Phase der Videoproduktion werden Videogenerierung und Workflow-Fähigkeiten nachgeladen.

Für Tool-Bereiche, die nicht mehr aktiv sind, können die ausführlichen Definitionen an einer Grenze der Kontextkomprimierung entfernt werden, damit irrelevante Informationen die weitere Inferenz weniger beeinflussen.

Auch dieses Design hat seinen Preis. Ändert sich die Menge der Tools, kann sich die Struktur des Modellkontexts mit ändern und die Trefferquote des Prompt Cache beeinträchtigen; zudem stimmen frühere Tool-Aufrufe im Verlauf möglicherweise nicht mehr vollständig mit den aktuell sichtbaren Tool-Definitionen überein.

In diesem Punkt lieferte uns die Context-Engineering-Praxis von Manus ein bedenkenswertes Gegenbeispiel.

Manus hält die Tool-Definitionen lieber stabil und senkt die Komplexität der Tool-Auswahl, indem es die jeweils verfügbaren Aktionen einschränkt. Das hilft, die durch geänderte Tool-Definitionen verursachte Invalidierung des Präfixes zu verringern, und erleichtert es, frühere Tool-Aufrufe und den aktuellen Kontext konsistent zu halten. Es geht hier um den Einfluss eines stabilen Kontexts auf die Wiederverwendung des Caches; Prompt Caching auf API-Ebene wird dabei nicht mit dem KV-Cache-Mechanismus innerhalb der Modellinferenz gleichgesetzt.

Dass Lomo Agent Tools nach Bereichen lädt, liegt vor allem daran, dass die Tool-Typen und Parameterstrukturen einer Kreativplattform recht umfangreich sind und das dauerhafte Vorhalten aller Tool-Definitionen einen hohen Kontext-Overhead verursachen kann.

Beide Strategien haben ihre Einsatzbedingungen: Eine stabile Tool-Menge begünstigt Caching und konsistentes Verhalten, dynamisches Laden kann dagegen die Token-Kosten und Auswahlstörungen durch irrelevante Tools verringern.

Wie gut unser Ansatz tatsächlich funktioniert, muss fortlaufend anhand von Tool-Wechselhäufigkeit, Cache-Trefferquote, Genauigkeit der Tool-Aufrufe und Gesamtkosten der Inferenz bewertet werden. Außerdem gilt: Ob ein Tool im Modellkontext auftaucht, bestimmt nur, was das Modell gerade auswählen kann. Die eigentliche Berechtigung zur Tool-Ausführung kontrolliert weiterhin der Server – die Sichtbarkeit von Tools im Prompt taugt nicht als Sicherheitsgrenze.

6.3 Verlaufskomprimierung: Über Zusammenfassungen hinaus nachlesen können

Bei lang laufender Ausführung wachsen Nachrichtenverlauf und Tool-Ergebnisse stetig an. Selbst mit einem großen Kontextfenster muss man in geeigneten Phasen komprimieren.

Üblich ist, das Modell die bisherige Historie fortlaufend zusammenfassen zu lassen und mit der jeweils neuesten Zusammenfassung weiterzuarbeiten. Dieser Ansatz hat jedoch ein Problem: Bei wiederholter Komprimierung gehen nach und nach Details verloren, und es kann sogar passieren, dass Vermutungen des Modells als historische Fakten festgeschrieben werden.

Deshalb setzen wir auf abschnittsweise Zusammenfassungen: Ältere Historie wird abschnittsweise komprimiert, während jüngere Interaktionen vollständig erhalten bleiben.

Neue Zusammenfassungen werden möglichst an die bestehende Folge von Zusammenfassungen angehängt, statt jedes Mal den gesamten Verlauf neu zu formulieren.

Bei umfangreichen Tool-Ausgaben – etwa Asset-Listen, Informationen zu Workflow-Knoten oder komplexen Generierungsergebnissen – kann das System im aktuellen Kontext nur eine notwendige Zusammenfassung behalten und den vollständigen Inhalt extern speichern.

Muss der Agent später einen bestimmten Parameter oder ein historisches Detail prüfen, stellt er die relevanten Informationen per Suche oder seitenweisem Lesen wieder her.

Das hat einiges gemeinsam mit dem von Manus propagierten Ansatz, das Dateisystem als externen Kontextspeicher zu nutzen. Das Modell muss nicht alle Informationen ständig mit sich führen, muss die verlässliche Originalquelle bei Bedarf aber wiederfinden können.

Ein Unterschied ist dabei wichtig: Zusammenfassungen sollen den Kontext der aktuellen Inferenz entlasten, dürfen aber nicht zur einzigen Quelle historischer Fakten werden. Gerade wenn der Nutzer eine Information korrigiert hat oder eine frühere Vorgabe nicht mehr gilt, muss das System die zugehörige Quelle finden können, damit alte Zusammenfassungen die weitere Ausführung nicht länger beeinflussen.

6.4 Die aktuelle Aufgabe immer im Blickfeld des Modells halten

Die Kontextkomprimierung löst das Problem eines zu langen Verlaufs. Ebenso wichtig ist jedoch eine andere Frage: Weiß der Agent mitten in der Ausführung noch, welches Ziel er gerade verfolgt?

Bei lang laufenden Aufgaben kann das Modell nach vielen Runden von Tool-Aufrufen allmählich vom ursprünglichen Ziel abdriften. Der Nutzer will etwa eine komplette Serie von Markenplakaten, doch der Agent steckt viel Energie in das wiederholte Optimieren eines einzelnen Referenzbilds und verliert das Gesamtergebnis aus den Augen.

Deshalb stellen wir im dynamischen Kontext des Workers fortlaufend das aktuelle Briefing, die Ausführungs-Checkliste, zentrale Vorgaben, den Wartestatus und die jüngsten Änderungen an den betroffenen Werken bereit.

Diese Zustände stammen aus der persistenten Runtime und nicht nur aus der Zusammenfassung, die das Modell aus dem bisherigen Chatverlauf erstellt hat.

Zum Beispiel:

• Das Briefing hält die vom Nutzer final freigegebene visuelle Richtung fest

• Die Ausführungs-Checkliste hält fest, welche Schritte erledigt sind und welche noch anstehen

• Der Workspace-Status teilt dem Modell mit, ob der Nutzer ein Asset ersetzt hat und in welcher Version ein Dokument gerade vorliegt.

Bearbeitet der Nutzer einen Flows-Workflow oder ein gemeinsames Dokument direkt, erhält auch die nächste Ausführungsrunde einen Hinweis auf die Objektänderung und kann bei Bedarf den aktuellen Inhalt lesen.

So kann der Agent auch dann auf Basis eines vertrauenswürdigen Aufgabenzustands weiterarbeiten, wenn Teile der Historie bereits komprimiert wurden.

Hier hat uns auch inspiriert, wie Manus durch fortlaufend präsentierte To-do-Listen die Aufmerksamkeit des Modells auf das Ziel lenkt. Lomo Agent verknüpft solche Listen zusätzlich mit dem Laufzeitzustand, sodass sie dem Modell nicht nur Kontext liefern, sondern auch das automatische Weiterlaufen und die Entscheidung über das Anhalten unterstützen. Darauf gehe ich im Kapitel über das autonome Vorantreiben ausführlich ein.

6.5 Die praktischen Abwägungen des Context Engineering

Insgesamt verfolgt das Context Engineering von Lomo Agent vor allem drei Ziele:

• irrelevante Informationen reduzieren

• Inferenzkosten kontrollieren

• sicherstellen, dass die Informationen, auf denen die aktuelle Entscheidung beruht, noch gültig sind

Diese Ziele stimmen aber nicht immer überein.

Aggressivere Komprimierung senkt den Token-Verbrauch, kann aber wichtige Details unterschlagen. Dynamisches Laden von Tools verkleinert den Auswahlraum, kann aber die Cache-Trefferquote beeinträchtigen. Ein dauerhaft vorgehaltenes, stabiles Profil stärkt die Kontinuität, erfordert aber den Umgang mit geänderten Präferenzen und widerrufenen Erinnerungen.

Kontextverwaltung lässt sich deshalb kaum mit einer einzigen festen Strategie lösen. Sie muss gemeinsam mit Aufgabenzustand, Gedächtnissystem, Tool-Berechtigungen und dem tatsächlichen Modellverhalten justiert werden.

Bei Lomo Agent kommt es uns vor allem darauf an, dass das Modell die richtigen Informationen findet, wenn es sie braucht, und auf Basis des aktuell gültigen Aufgabenzustands weiterarbeitet. Erstreckt sich die Zusammenarbeit aber über mehrere Aufgaben, mehrere Tage oder sogar Monate, reicht die Kontextverwaltung innerhalb einer Aufgabe nicht mehr aus. Langfristig entstandene Präferenzen des Nutzers, frühere Projekte und einmal getroffene Entscheidungen müssen von einem anderen Mechanismus organisiert und abgerufen werden.

7. Memory Engineering: Herkunft, Versionen und Widerrufbarkeit

Im vorigen Kapitel ging es darum, Informationen in einem begrenzten Kontextfenster zu organisieren. Für einen Agenten, der langfristig mitarbeiten soll, stellt sich jedoch eine tiefere Frage: Was sollte sich das System merken, wenn ein Gespräch den aktuellen Kontext längst verlassen hat oder die zugehörige Aufgabe sogar schon abgeschlossen ist?

In den kreativen Szenarien von Lomo Agent nutzen Nutzer die Plattform womöglich über Monate und entwickeln dabei relativ stabile visuelle Vorlieben, gewohnte kreative Abläufe und Markenrichtlinien. Diese Informationen sollten sie nicht jedes Mal neu beschreiben müssen.

Gleichzeitig ändern sich die Präferenzen von Nutzern. Ein vorübergehender Stil aus einem Projekt passt nicht unbedingt zu allen künftigen Arbeiten; eine früher gültige Markenrichtlinie kann nach einem Relaunch vollständig hinfällig sein.

Deshalb soll das Langzeitgedächtnis über Aufgaben und Zeit hinweg Kontinuität bieten und dabei die Herkunft und den Geltungsbereich von Fakten bewahren.

7.1 Vom Nachrichtenverlauf zum Langzeitgedächtnis

Das Erste, was ein Langzeitgedächtnis leisten muss, ist die Auswahl von Informationen.

Sagt ein Nutzer etwa „Ich mag normalerweise Farbpaletten mit geringer Sättigung“, ist das womöglich eine Präferenz, die langfristig gespeichert werden sollte. Sagt er dagegen „Probieren wir diesmal ein kräftig gesättigtes Rot“, handelt es sich eher um eine lokale Vorgabe für das aktuelle Werk.

Beide Sätze drehen sich um Farbe, haben aber einen unterschiedlichen Geltungsbereich. Würde das System alle Nutzernachrichten direkt in eine Vektordatenbank schreiben und sich beim Wiederbefüllen auf semantische Suche verlassen, wären langfristige Präferenzen, temporäre Vorgaben und längst ungültige historische Informationen schnell vermischt.

Deshalb haben wir das Gedächtnis von Lomo Agent in mehrere Schichten unterteilt:

Diese Schichten hängen miteinander zusammen, erfüllen aber unterschiedliche Funktionen.

Die ursprünglichen Nachrichten sind nachvollziehbare Belege. Das System kann daraus Kandidaten für Erinnerungen extrahieren und dann anhand von Herkunft, Zeitpunkt, Geltungsbereich und vorhandenen Einträgen entscheiden, ob gespeichert, ergänzt oder aktualisiert werden muss.

Episodische Zusammenfassungen konzentrieren sich darauf, was in einer Phase der Zusammenarbeit passiert ist. Etwa: Der Nutzer hat letzte Woche eine Reihe von Markenplakaten erstellt, sich am Ende für eine Variante in warmen Farben entschieden und die geplante Videoproduktion vorerst zurückgestellt. Nicht all das gehört ins langfristige Profil, kann aber nützlich sein, wenn der Nutzer das Projekt das nächste Mal erwähnt.

Beim Nutzerprofil ist mehr Zurückhaltung geboten. Es sollte nur wenige, relativ stabile Informationen enthalten, damit es mit der Nutzungsdauer nicht zu einem weiteren, stetig wachsenden Gesprächsverlauf wird.

Beim eigentlichen Abruf wählt das System dann anhand des Ziels und der Berechtigungen der aktuellen Aufgabe aus, welche Erinnerungen dem Modell bereitgestellt werden – ohne in jeder Runde den vollständigen Verlauf zu laden.

Dabei gilt ein wichtiges Prinzip: Das Gedächtnis muss zwischen Fakten, die der Nutzer ausdrücklich geäußert hat, und Vermutungen des Modells unterscheiden.

Schließt der Agent etwa daraus, dass ein Nutzer mehrere Cyberpunk-Bilder hintereinander generiert hat, auf eine dauerhafte Vorliebe für Cyberpunk, kann das als Kandidat gelten – aber nicht mit einer ausdrücklich geäußerten Präferenz gleichgesetzt werden.

Ebenso dürfen Webinhalte, Tool-Ergebnisse und vom Agenten selbst erstellte Zusammenfassungen nicht ohne verlässliche Grundlage in persönliche Fakten über den Nutzer umgedeutet werden.

7.2 Was wir aus bestehenden Gedächtnisarchitekturen gelernt haben

Beim Design des Langzeitgedächtnisses haben wir uns an mehreren technischen Ansätzen orientiert.

Die Gedächtnispraxis von OpenClaw setzt auf überprüfbare, wartbare Speicherformen und auf die Beziehung zwischen Erinnerungen und dem ursprünglichen Kontext. Ihr Vorteil ist eine hohe Transparenz: Nutzer oder Entwickler können leicht nachsehen, was gespeichert wurde. Wächst das Gedächtnis jedoch immer weiter, braucht es zusätzliche Mechanismen für Suche, Pflege und Konfliktbehandlung.

Mem0 konzentriert sich darauf, wertvolle Informationen aus Gesprächen zu extrahieren und relevante Erinnerungen in späteren Interaktionen per Suche wiederherzustellen. Das eignet sich für Agenten, die lange und themenübergreifend genutzt werden, doch die Qualität des Gedächtnisses hängt stark von der Extraktionsgenauigkeit und der Abrufstrategie ab. Wird eine temporäre Anweisung fälschlich als dauerhafte Präferenz eingestuft, kann spätere Suche den Fehler sogar immer weiter verstärken.

Zep / Graphiti verfolgen einen anderen Ansatz: Sie pflegen im Gedächtnis explizit Entitätsbeziehungen und zeitliche Informationen. Das ist besonders wertvoll für Fakten, die sich laufend ändern. Hat eine Marke früher etwa Blau als Hauptfarbe verwendet und später auf Grün umgestellt, widersprechen sich die beiden Einträge nicht zwangsläufig – sie können unterschiedlichen Gültigkeitszeiträumen entsprechen.

Temporale Beziehungen und Knowledge Graphs bringen allerdings auch höhere Wartungskomplexität mit sich, etwa bei Entitätsnormalisierung, Aktualisierung von Beziehungen, Konfliktbehandlung und Abrufkosten.

Mit Blick auf die kreativen Szenarien von Lomo Agent beschäftigen uns vor allem drei Fragen:

1. Haben Nutzerpräferenzen eine verlässliche Herkunft?

2. Sind historische Fakten noch gültig?

3. Werden die zugehörigen Erinnerungen mitaktualisiert, wenn der Nutzer Informationen korrigiert oder widerruft?

Deshalb pflegen wir für Erinnerungen über die übliche geschichtete Speicherung und semantische Suche hinaus auch Herkunft, Versionen und Ableitungsbeziehungen.

7.3 Warum „Vergessen“ schwieriger ist als „Merken“

Beim Langzeitgedächtnis gibt es noch ein leicht übersehenes Problem: Wie soll das System reagieren, wenn der Nutzer ausdrücklich verlangt, bestimmte Inhalte zu vergessen?

Angenommen, der Nutzer sagt zunächst: „Die Hauptfarbe unserer Marke ist Blau.“

Später ergänzt er: „Blau mit Cremeweiß kombiniert wirkt insgesamt weicher.“

Das Gedächtnissystem fasst die beiden Aussagen womöglich zu einer neuen Markenpräferenz zusammen:

„Die Marke bevorzugt die Kombination von Blau und Cremeweiß; der visuelle Gesamteindruck tendiert zu einem weichen Stil.“

Verlangt der Nutzer danach, die ursprüngliche Festlegung auf Blau zu vergessen, reicht es offensichtlich nicht, nur die erste atomare Erinnerung zu löschen, denn die zusammengeführte Version enthält die Information weiterhin.

Läuft das System weiter, kann diese Information außerdem in episodische Zusammenfassungen und das Nutzerprofil gelangen oder sogar in andere abgeleitete Erinnerungen einfließen.

Deshalb pflegen wir für Erinnerungen Herkunfts- und Ableitungsbeziehungen, die beschreiben, aus welchen historischen Belegen und älteren Versionen eine Erinnerung hervorgegangen ist.

flowchart TD
    U["Nutzer gibt zu vergessende Inhalte an"] --> A["Betroffenen Belegen die Nutzung im Gedächtnis entziehen"]
    A --> B["Betroffene Gedächtnisversionen ermitteln"]
    B --> C["Entlang der Ableitungsbeziehungen spätere Versionen finden"]
    C --> D["Betroffene Inhalte deaktivieren, weiterhin gültige Belege prüfen"]
    D --> E["Auf Basis der verbleibenden gültigen Belege neu extrahieren"]
    E --> F["Atomare Erinnerungen, Zusammenfassungen und Nutzerprofil aktualisieren"]
    F --> G["Zugehörige Suchindizes und Kontext-Caches invalidieren"]

Abb. 8: Der Ablauf beim Widerrufen von Erinnerungen.

In der Implementierung bilden wir die Entwicklung von Erinnerungen über Versionsketten ab. Am Beispiel der Markenhauptfarbe von oben: Die ursprüngliche Aussage zu Blau bildet die gültige Version v1 und ist mit dem Rohbeleg (ORIGIN) verknüpft. Ergänzt der Nutzer die Kombination mit Cremeweiß, erzeugt das System eine neue Version v2, markiert die bisherige Version als SUPERSEDED und hält zugleich den neuen, präzisierenden Beleg (REFINE) fest. Bestätigt der Nutzer später nur eine bestehende Aussage, kann dies als CONFIRM vermerkt werden, ohne eine neue Erinnerung zu erzeugen.

Verlangt der Nutzer, die ursprüngliche Festlegung auf Blau zu vergessen, entzieht das System dem zugehörigen Beleg die Nutzbarkeit und ermittelt entlang der Versionsbeziehungen die betroffenen Erinnerungen. Versionen, die von diesem Beleg abhängen, werden gelöscht und ihr Inhalt geleert; anschließend wird auf Basis der verbleibenden gültigen Belege neu extrahiert. Belege, die nur bestätigenden Charakter haben, lassen sich dagegen einfach entkoppeln, ohne eigenständig gültige Erinnerungen zu beeinträchtigen.

Dieser Widerruf setzt sich auch auf Nutzerprofil und episodische Zusammenfassungen fort. Werden betroffene Profileinträge ungültig, aktualisiert das System die Profilversion, damit spätere Inferenzen den alten Snapshot nicht mehr verwenden; betroffene Zusammenfassungen müssen neu aufgebaut werden. Gleichzeitig löscht das System die zugehörigen Suchvektoren und unterdrückt eine erneute Extraktion gelöschter Inhalte, um das Risiko zu senken, dass alte Informationen wieder in den Kontext gelangen.

Zu beachten ist, dass bereits abgesetzte Modellanfragen nicht sofort widerrufen werden können. Deshalb verfolgen wir zusätzlich, auf welchen Nachrichten und Erinnerungen Antworten und Tool-Ergebnisse beruhen, und schließen betroffene abgeleitete Inhalte bei späteren Inferenzen aus – damit vergessene Informationen nicht über die eigenen früheren Ausgaben des Agenten wieder eingeführt werden.

Das hier besprochene „Vergessen“ betrifft vor allem die Nutzbarkeit des Langzeitgedächtnisses und des daraus abgeleiteten Kontexts. Es ist nicht gleichbedeutend mit dem Löschen aller ursprünglichen Chatverläufe, generierten Assets oder Transaktionsdaten. Letzteres gehört zu anderen Datenlebenszyklen und Fragen des Datenschutzmanagements und muss gesondert behandelt werden.

7.4 Zuverlässigkeit des Gedächtnisses und Graceful Degradation

Herkunftsnachverfolgung (Provenance Tracking) und Versionsverwaltung machen das Gedächtnissystem besser kontrollierbar, können Verständnisfehler des Modells aber nicht vollständig ausschließen.

So kann ein und dasselbe Gespräch mehrere Kandidaten für Fakten enthalten, von denen einer die Speicherkriterien erfüllt, während ein anderer nur eine vom Modell missverstandene temporäre Anweisung ist. Behandelt man das gesamte Extraktionsergebnis als unteilbares Ganzes, kann ein einzelner Ausreißer andere gültige Erinnerungen in Mitleidenschaft ziehen.

Kandidaten für Erinnerungen müssen daher einzeln geprüft und verarbeitet werden, wobei Fälle wie fehlende Stützung durch die Quelle, inhaltliche Konflikte und fehlerhafte Ausgabeformate zu unterscheiden sind.

Fällt der Gedächtnisdienst aus, sollte das auch nicht die normale kreative Arbeit komplett lahmlegen.

Bei einem Timeout beim Abruf kann die Anreicherung mit Erinnerungen vorübergehend übersprungen werden; eine fehlgeschlagene Extraktion im Hintergrund kann später erneut verarbeitet werden; und ein einzelner Kandidat mit fehlerhaftem Format muss nicht dazu führen, dass andere gültige Einträge mit verloren gehen.

Eine solche Strategie der Graceful Degradation (kontrollierter Funktionsabbau) bedeutet, dass der Agent in manchen Fällen nicht auf die vollständigen historischen Präferenzen zugreifen kann, aber dennoch auf Basis des aktuellen Briefings und des vorhandenen Ausführungsstatus weiterarbeiten kann.

Statt ein fehlerhaftes Gedächtnisergebnis die gesamte Aufgabe beeinträchtigen zu lassen, erhalten wir lieber den normalen Ausführungspfad und liefern den relevanten Hintergrund nach, sobald das Gedächtnis wieder verfügbar ist.

Ob ein Langzeitgedächtnis wirklich Wert schafft, muss sich letztlich in der realen Zusammenarbeit zeigen. Neben der Abrufgenauigkeit interessiert uns auch, ob Erinnerungen veraltet sind, ob sich ihre Herkunft erklären lässt und ob alte Informationen spätere Entscheidungen noch beeinflussen, nachdem der Nutzer sie korrigiert oder widerrufen hat.

Zum Vergrößern klicken

Mit zunehmend ausgereiftem Gedächtnis und Aufgabenkontext kann der Agent bereits auf zeitübergreifende Hintergrundinformationen zugreifen. Zu wissen, was der Nutzer früher getan hat, heißt jedoch nicht, beurteilen zu können, ob die aktuelle Aufgabe fortgesetzt werden sollte.

Eine Aufgabe mit mehreren kreativen Schritten braucht zusätzlich einen klaren Ausführungsplan, Abbruchbedingungen und die Grenzen der Freigaben durch den Nutzer. Genau darum geht es im nächsten Kapitel beim Mechanismus des autonomen Vorantreibens.

8. Autonomes Vorantreiben: Plan, Abbruchbedingungen und Freigaben durch den Nutzer

Die bisherigen Mechanismen ermöglichen es dem Agenten, langfristige Aufgaben zu pflegen, unterbrochene Ausführungen wieder aufzunehmen und bei Bedarf historische Informationen wiederzufinden. Für ein kreatives Ziel, das kontinuierlich vorangetrieben werden muss, bleibt jedoch eine Frage offen: Wie entscheidet der Agent, ob er weiterarbeiten sollte?

Angenommen, der Nutzer möchte einen kurzen Markenfilm. Nachdem der Agent Drehbuch und Storyboard fertiggestellt hat, liefert er vielleicht eine Zusammenfassung und beendet die aktuelle Runde. Das Modell hat dabei keinen Fehler gemacht – es hat die aktuelle Phase tatsächlich abgeschlossen –, doch bis zum fertigen Film, den der Nutzer eigentlich will, ist es noch ein weiter Weg.

In frühen Demos und Szenariodurchläufen sind wir auf genau solche Situationen gestoßen. Nutzer mussten immer wieder „weiter“ schicken, damit der Agent in die nächste Phase überging.

Weist man das Modell dagegen einfach an, „nicht aufzuhören, bevor alle Aufgaben erledigt sind“, entsteht leicht ein anderes Problem: Der Agent wiederholt womöglich bereits gescheiterte Operationen, erzeugt laufend unnötige Assets oder erweitert ohne Bestätigung des Nutzers eigenmächtig den kreativen Umfang. Deshalb müssen Aufgabenziel und Ausführungsfortschritt unabhängig von einzelnen Modellantworten sein, und die Grenzen des automatischen Vorantreibens muss die Runtime kontrollieren.

8.1 Den Plan in eine dauerhaft gepflegte Ausführungs-Checkliste überführen

Wir haben eine Execution Checklist (strukturierte Ausführungs-Checkliste) eingeführt, die die wichtigsten Schritte eines kreativen Ziels von der Planung bis zur Lieferung festhält.

Anders als eine gewöhnliche To-do-Liste, die das Modell im Chat erzeugt, ist die Ausführungs-Checkliste ein strukturierter Zustand, den das System persistent pflegt. Jeder Schritt kann mit einem Ausführungsstatus, Ergebnissen, Erledigungsnachweisen und gegebenenfalls erforderlichen Bestätigungen durch den Nutzer verknüpft sein.

Ein kurzer Markenfilm ließe sich etwa so gliedern:

Sobald der Nutzer den Ausführungsplan freigibt, wird die Checkliste zur Grundlage für das weitere Vorantreiben. Der Worker plant und ruft Tools anhand des aktuellen Schritts auf, und die Runtime kann nach jeder Ausführungsrunde den Fortschritt prüfen.

Wichtig dabei: Die Ausführungs-Checkliste ist kein unveränderlicher, fester Plan.

Kreative Prozesse ändern sich häufig. Beschließt der Nutzer zum Beispiel während der Generierung der Einstellungen, die Figurendefinition zu ändern, müssen die ursprünglichen Schritte und ein Teil der Ergebnisse womöglich neu angepasst werden. Dann muss das System den Plan anhand der neuen Anweisung des Nutzers aktualisieren und die Zuordnung zwischen Schritten und Ergebnissen pflegen.

Die Ausführungs-Checkliste sorgt für die Kontinuität von Ziel und Fortschritt. Sie ermöglicht es dem Agenten, auch nach Kontextkomprimierung, asynchronem Warten oder Prozesswiederherstellung zu finden, an welcher Stelle der Ausführung die aktuelle Aufgabe steht.

8.2 Soll die Aufgabe weiterlaufen, wenn das Modell aufhört zu antworten?

Ist der Plan persistiert, muss noch eine konkretere Frage beantwortet werden: Wie soll die Runtime reagieren, wenn das Modell die aktuelle Runde beendet?

Beim Design dieses Mechanismus haben wir uns an den Ansätzen von Codex Goals und Claude Code Hooks orientiert.

Codex Goals verbindet Ziele mit einem fortlaufenden Ausführungszustand, sodass der Agent an noch nicht erreichten Zielen weiterarbeiten kann. Der Stop Hook von Claude Code erlaubt zusätzliche Prüfungen, wenn das Modell im Begriff ist anzuhalten, und kann je nach Ergebnis das aktuelle Anhalten verhindern.

Beide Designs haben mich auf einen Gedanken gebracht: Dass das Modell eine Antwort beendet, heißt nicht zwangsläufig, dass die gesamte Aufgabe erledigt ist. Die Runtime braucht einen eigenständigen Zielzustand und einen eigenen Prüfmechanismus für das Anhalten.

Allerdings unterscheiden sich die Erledigungskriterien von Coding-Agenten und kreativen Agenten deutlich.

Bei Code-Aufgaben liefern bestandene Tests, ein erfolgreicher Build oder die erwartete Änderung bestimmter Dateien meist recht eindeutige Belege für die Ausführung. Kreative Aufgaben haben dagegen kaum einheitliche, objektive Kriterien. Dass ein Video erfolgreich generiert wurde, sagt nichts darüber, ob Figurenkonsistenz, Schnittrhythmus und visuelle Gesamtwirkung den Erwartungen des Nutzers entsprechen.

Deshalb behandeln wir Prozessfortschritt und Abnahme des Werks getrennt.

Ersteres lässt sich anhand der Ausführungs-Checkliste, der Protokolle der Tool-Aufrufe und des Zustands der Ergebnisse beurteilen; Letzteres erfordert multimodales Verständnis, die konkreten Anforderungen der Aufgabe und gegebenenfalls ein manuelles Review.

Nach jeder Ausführungsrunde prüft die Runtime, ob für die aktuelle Aufgabe noch Schritte ausstehen, ob auf etwas Externes gewartet wird, ob eine Bestätigung des Nutzers nötig ist und ob Ausführungslimits erreicht sind.

flowchart TD
    E["Aktuelle Ausführungsrunde beendet"] --> A{"Ausführungs-Checkliste abgeschlossen?"}
    A -->|Ja| END["Ausführung beenden, Ergebnis anzeigen oder abnehmen"]
    A -->|Nein| B{"Aufgabe pausiert, blockiert oder über dem Limit?"}
    B -->|Ja| STOP["Automatisches Vorantreiben stoppen und Grund festhalten"]
    B -->|Nein| C{"Wartet auf ein externes Ereignis?"}
    C -->|Ja| WAIT["Suspendieren und auf das Ereignis warten"]
    C -->|Nein| D{"Manueller Checkpoint erreicht?"}
    D -->|Ja| GATE["Bestätigungs- oder Auswahlkarte anzeigen"]
    D -->|Nein| F{"Echter Fortschritt erzielt?"}
    F -->|Nein| LIMIT["Automatisches Weiterlaufen stoppen, Leerlauf vermeiden"]
    F -->|Ja| NEXT["Nächste Worker-Runde einplanen"]
    NEXT --> E

Abb. 9: Die Runtime entscheidet anhand des persistierten Aufgabenzustands, ob die Ausführung fortgesetzt wird – nicht allein danach, ob das Modell seine Ausgabe beendet hat.

Besondere Aufmerksamkeit verdient hier der echte Fortschritt (Meaningful Progress).

Neue verwendbare kreative Ergebnisse, ein abgeschlossener Schritt der Checkliste oder ein erfolgreich abgesetzter neuer Generierungsjob können als Anhaltspunkte für Fortschritt dienen.

Überarbeitet der Agent dagegen nur immer wieder die Planbeschreibung oder schaltet den Status von Schritten ständig von „offen“ auf „in Arbeit“, ohne neue verwertbare Ergebnisse zu erzeugen, sollte er nicht endlos weiterlaufen.

Mit Fortschrittsprüfungen und Ausführungslimits halten wir die Inferenzkosten durch solchen Leerlauf so gering wie möglich.

Natürlich hat auch diese Beurteilung Grenzen. Neu generierte Assets belegen nur, dass das System eine Operation ausgeführt hat, nicht aber, dass ihre Qualität stimmt. Eine umfassendere multimodale Qualitätsabnahme bleibt eine Richtung, die wir weiter erforschen müssen.

8.3 Human-in-the-Loop: Nutzer an zentralen Entscheidungen beteiligen

Im kreativen Prozess möchten Nutzer repetitive Arbeitsschritte oft an den Agenten abgeben und zugleich die Kontrolle über die zentrale kreative Richtung behalten.

Visuelle Markenrichtung, Figurendefinition, Storyboard und die finale Auswahl der Einstellungen etwa sind meist stark subjektiv. Entscheidet der Agent an diesen Punkten selbst und generiert weiter, können später erhebliche unnötige Kosten entstehen.

Deshalb haben wir den Human-in-the-Loop Checkpoint (manueller Checkpoint) eingeführt, der das automatische Vorantreiben in Phasen anhält, in denen der Nutzer beteiligt werden muss.

Erreicht die Ausführung einen Checkpoint, kann der Agent über strukturierte Karten den aktuellen Entwurf, Kandidaten und empfohlene Aktionen präsentieren. Der Nutzer wählt direkt „Bestätigen und fortfahren“ oder „Entwurf anpassen“, und das System aktualisiert den Aufgabenstatus anhand dieser eindeutigen Aktion.

Zum Vergrößern klicken

Diese Art der Interaktion orientiert sich auch an der Berechtigungsabfrage von Produkten wie Claude Code: Bei Operationen mit spürbaren Seiteneffekten sollte das System den Nutzer vorab darüber informieren, was ausgeführt werden soll, und ihn entscheiden lassen, ob es weitergeht.

In kreativen Szenarien geht es bei manuellen Checkpoints jedoch nicht nur um Berechtigungen, sondern auch um Ästhetik und kreative Richtung. Ein Nutzer hat dem Agenten die Videogenerierung vielleicht bereits freigegeben, möchte aber nach dem Entwurf der Einstellungen dennoch selbst eine Variante auswählen. Deshalb müssen Checkpoints als eigenständiger Ausführungszustand gespeichert werden und dürfen sich nicht allein darauf stützen, dass das Modell in seiner Antwort „wartet auf Bestätigung“ schreibt.

In Probeläufen während der Entwicklung sind wir genau auf ein solches Problem gestoßen: Der Agent hatte bereits eine Phase erreicht, die eine Bestätigung des Nutzers erforderte, antwortete aber nur mit „Bitte bestätige, ob es weitergehen soll“, ohne eine direkt bedienbare Bestätigungskarte anzubieten – sodass der Nutzer erneut „weiter“ eingeben musste.

Deshalb haben wir in der Runtime einen Absicherungsmechanismus ergänzt: Steht eine Aufgabe an einem Checkpoint, ohne dass das Modell eine entsprechende Rückfrage gestellt hat, ergänzt das System automatisch eine Bestätigungskarte; bei Generierungen, die erst nach der Freigabe durch den Nutzer ausgeführt werden, wird die Aufgabe nach Abschluss der Generierung automatisch wieder aufgeweckt, sofern die Ausführungs-Checkliste noch offene Schritte enthält. So hängen das Warten auf Bestätigung und die Wiederaufnahme der Ausführung nicht mehr allein vom Interaktionsverhalten des Modells ab, sondern werden von der Runtime anhand des Aufgabenzustands koordiniert.

Checkpoints bedeuten natürlich nicht, dass der Nutzer bei jedem Schritt eingreifen muss. Für nicht widerrufbare oder über die Freigaben hinausgehende Operationen verlangt das System stets eine ausdrückliche Bestätigung; repetitive, risikoarme Schritte können dagegen im Rahmen der Freigaben ohne Unterbrechung vorankommen, damit nicht zu viele Bestätigungen den kreativen Prozess unterbrechen.

8.4 Selbstständigkeit, Budget und die Grenzen der Freigaben

Auf einer KI-Kreativplattform kann der Agent Generierungsfähigkeiten verschiedener Modellhersteller für Text, Bild, Video, Audio, 3D und mehr aufrufen, und diese Operationen verursachen meist echte Kosten. Deshalb müssen Selbstständigkeit und Budgetkontrolle getrennt gestaltet werden.

Erlaubt ein Nutzer dem Agenten die automatische Ausführung, heißt das nicht, dass er unbegrenzten Aufrufen kostenpflichtiger Modelle zustimmt. Umgekehrt bedeutet ein freigegebenes Budget nicht, dass jede Operation ohne Review durchlaufen darf.

In der Runtime pflegen wir drei Dimensionen getrennt:

Beispiel: Der Nutzer gibt die Produktion von drei Videoclips frei und erlaubt dem Agenten, sie im Rahmen des Budgets automatisch fertigzustellen.

Stellt sich während der Ausführung heraus, dass zusätzlich Referenzbilder für Figuren nötig sind, kann der Agent prüfen, ob diese Operationen durch den ursprünglichen Plan und das Budget gedeckt sind. Muss der Umfang der Ausführung erweitert werden oder entstehen zusätzliche Kosten, sollte er erneut die Bestätigung des Nutzers einholen.

Hier geht es um eine wichtige Sicherheitsgrenze: Weder ein vom Modell vorgeschlagener Plan noch eine vom Modell behauptete Freigabe kann von sich aus zu einer echten Freigabe durch den Nutzer werden.

Das System muss sich auf ausdrückliche Aktionen des Nutzers in der Oberfläche und den serverseitig gespeicherten Freigabestatus stützen.

Je nach Tool sind zudem abhängig von den tatsächlichen Seiteneffekten unterschiedliche Kontrollstrategien nötig.

• Reine Leseabfragen sind meist risikoarm

• Schreibvorgänge in Dokumenten müssen Versionen und Berechtigungen berücksichtigen

• Kostenpflichtige Generierungen erfordern eine Budgetprüfung

• Irreversible Operationen wie das Löschen von Assets oder das Widerrufen von Erinnerungen erfordern strengere Bestätigungsmechanismen

Gegenüber Coding-Agenten unterliegen Agenten auf Kreativplattformen einer besonderen Einschränkung: Bei vielen externen Generierungen sind die Kosten möglicherweise schon mit dem Absenden entstanden und lassen sich auch dann nicht unbedingt vollständig rückgängig machen, wenn der Nutzer die Aufgabe anschließend stoppt. Budget- und Freigabeprüfungen müssen daher stattfinden, bevor tatsächlich Seiteneffekte entstehen, und mit dem oben beschriebenen Mechanismus der Durable Execution zusammenspielen.

Nach unserer bisherigen Erfahrung liegt die Schwierigkeit autonomer Ausführung ebenso darin, zu erkennen, wann angehalten werden sollte. Bei unzureichendem Guthaben, einer Pause durch den Nutzer, dem Warten auf externe Jobs, einem erforderlichen manuellen Review oder wenn fortgesetzte Ausführung keinen echten Fortschritt bringt, muss die Runtime den aktuellen Zustand bewahren und erst weitermachen, wenn die Bedingungen erfüllt sind.

Das bedeutet auch: Mehr Selbstständigkeit ist nicht automatisch besser. Risiko, Kosten und Überprüfbarkeit unterscheiden sich zwischen kreativen Aufgaben erheblich. Der Agent sollte im Rahmen der Freigaben des Nutzers unnötige Eingriffe möglichst vermeiden und dem Nutzer an zentralen Punkten zugleich die Kontrolle lassen.

Längerfristig hoffen wir außerdem, dass das System mithilfe multimodaler Qualitätsbewertung Figurenkonsistenz, Kontinuität der Einstellungen und visuelle Wirkung genauer beurteilen kann. Je ausgereifter die automatische Abnahme wird, desto mehr Schritte, die bisher eine manuelle Bestätigung erfordern, könnten dem Agenten zur selbstständigen Erledigung überlassen werden.

Kontinuierliche Zusammenarbeit wirft allerdings noch eine weitere Frage jenseits der Aufgabenausführung auf: Nutzer bearbeiten Werke womöglich nicht über den Dialog, sondern direkt im Workspace. Wie hält das System den Zustand konsistent, wenn Agent und Nutzer gleichzeitig dasselbe Dokument oder denselben Workflow bearbeiten?

Dafür braucht es einen gemeinsamen Workspace, der über die Aufgabenausführung hinaus den gemeinsamen Zugriff von Mensch und Agent auf das Werk und dessen gemeinsame Bearbeitung sicherstellt.

9. Shared Workspace: Nutzer und Agent bearbeiten dasselbe Werk

Die bisher besprochenen Mechanismen klären vor allem, wie der Agent Aufgaben versteht, Kontext pflegt und die Arbeit kontinuierlich vorantreibt. Im echten kreativen Prozess findet die Zusammenarbeit zwischen Nutzer und Agent jedoch nicht nur im Chatfenster statt.

Während der Agent etwa anhand eines Storyboards ein Video generiert, passt der Nutzer im Workspace rechts vielleicht direkt den Prompt einer Einstellung an, tauscht Referenzmaterial aus oder ändert einen Modellknoten in einem Flows-Workflow.

Diese Operationen laufen nicht über den Dialog, verändern das Werk aber ganz real. Arbeitet der Agent weiter auf Basis seines bisherigen Kontexts, verwendet er womöglich veraltete Parameter oder überschreibt sogar die Änderungen, die der Nutzer gerade erst vorgenommen hat.

Deshalb behandeln wir kreative Ergebnisse in Lomo Agent als persistente Objekte, die unabhängig von Dialog und Aufgabenkontext existieren, und organisieren die Zusammenarbeit von Mensch und Agent über den Shared Workspace (gemeinsamer Workspace).

9.1 Werke mit eigenem Lebenszyklus

In klassischen dialogbasierten Agenten hängen Generierungsergebnisse meist an einer bestimmten Chatnachricht. Nutzer können sie ansehen, herunterladen oder nachhaken, doch mit wachsendem Gesprächsverlauf werden Verwaltung und spätere Bearbeitung der Werke zunehmend durch die Sitzungsstruktur eingeschränkt.

Die kreativen Abläufe in Lomo umfassen dagegen viele Objekte, die langfristig gepflegt werden müssen, etwa Bilder, Videos, 3D-Assets, Storyboard-Dokumente, Asset-Sammlungen und visuelle Flows-Workflows.

Diese Objekte brauchen eine stabile Identität, Versionen und Zugriffsrechte; sie müssen sich direkt vom Nutzer bearbeiten und zugleich von verschiedenen Aufgaben referenzieren lassen.

Deshalb verwalten wir Dialogkontext und kreative Ergebnisse getrennt:

• Dialog- und Aufgabenkontext pflegen die Absicht des Nutzers, den Ausführungsverlauf und den aktuellen Wissensstand des Agenten.

• Der gemeinsame Workspace speichert die Werke, die tatsächlich fortlaufend bearbeitet und geliefert werden müssen, einschließlich Objektidentität, Inhalt, Version und zugehöriger Verweise.

So bespricht der Nutzer etwa das Storyboard für einen kurzen Markenfilm zunächst in Main, anschließend treibt eine Videoproduktions-Aufgabe die Arbeit weiter voran. Beide Ausführungsräume können im Rahmen ihrer Berechtigungen auf dasselbe Storyboard-Dokument verweisen, ohne jeweils eine eigene Kopie anzulegen.

Ebenso lassen sich die Ergebnisse einer abgeschlossenen Videogenerierungs-Aufgabe weiterhin in einem neuen Workflow referenzieren – unabhängig davon, ob der ursprüngliche Worker noch läuft.

Dieses Design erlaubt es Werken, den Lebenszyklus einzelner Dialogrunden und einzelner Aufgaben zu überdauern, und schafft die Grundlage für die Wiederverwendung von Assets und die Zusammenarbeit über mehrere Aufgaben hinweg.

9.2 Den Agenten Änderungen im Workspace wahrnehmen lassen

Gemeinsame Objekte klären, wie Werke gespeichert werden. Offen bleibt eine andere Frage: Woher weiß der Agent, dass ein Werk bereits geändert wurde?

Angenommen, der Agent hat ein Storyboard-Dokument gelesen und will anhand der Beschreibungen der Einstellungen weiter generieren. Genau in diesem Moment ändert der Nutzer direkt im Workspace den Inhalt der zweiten Einstellung.

Würde das System nur Chatnachrichten aufzeichnen, wüsste die nächste Inferenzrunde des Agenten nichts von dieser Änderung.

Deshalb pflegen wir für gemeinsame Objekte Versionsinformationen und halten fest, welche Version die betreffende Aufgabe beim letzten Lesen oder Bearbeiten des Objekts gesehen hat.

Ändert sich ein Dokument, ein Asset oder ein Workflow, kann das System der zugehörigen Aufgabe einen persistenten Änderungshinweis hinterlassen, zum Beispiel:

Das Storyboard-Dokument wurde von v3 auf v4 aktualisiert; die Beschreibung der zweiten Einstellung hat sich geändert. Bitte vor dem Fortfahren die neueste Version lesen.

Wir haben uns bewusst dagegen entschieden, bei jeder Bearbeitung im Workspace sofort eine Inferenz des Agenten auszulösen.

Der Grund ist einfach: Wenn ein Nutzer einen Workflow anpasst, verschiebt er womöglich mehrfach hintereinander Knoten, ändert Parameter oder tauscht Assets aus. Würde jede Änderung den Worker aufwecken, entstünden nicht nur massenhaft sinnlose Modellaufrufe; der Agent könnte sich auch immer wieder einmischen, bevor der Nutzer mit der Bearbeitung fertig ist.

Änderungshinweise dienen daher vor allem dazu, dass der Agent bei der nächsten Ausführung bemerkt, dass sein Wissensstand veraltet ist. Erst wenn die betreffende Aufgabe tatsächlich weiter vorangetrieben werden muss, entscheidet die Runtime anhand des aktuellen Zustands, ob die Ausführung wieder aufgenommen wird.

Bei visuellen Workflows wie Flows muss der Agent auch nicht in jeder Inferenzrunde die vollständigen Knotendaten lesen. Das System kann zunächst eine knappe Übersicht der Änderungen liefern und den aktuellen Inhalt erst dann bedarfsweise abrufen, wenn das Modell die betreffenden Knoten tatsächlich bearbeiten muss.

Hier schließt sich der Kreis zum oben beschriebenen Context Engineering: Der Workspace hält den vollständigen Zustand des Werks vor, der Kontext liefert nur die Informationen, die für die aktuelle Entscheidung nötig sind.

9.3 Versionskonflikte und optimistische Nebenläufigkeitskontrolle

Änderungen wahrnehmen zu können, reicht noch nicht aus, um gleichzeitige Bearbeitungen abzusichern.

Ein konkreteres Szenario:

Der Agent hat Version v3 des Storyboard-Dokuments gelesen und will die dritte Einstellung anpassen. Gleichzeitig bearbeitet der Nutzer dasselbe Dokument direkt und speichert es als v4.

Committet der Agent anschließend direkt seine auf v3 basierende Änderung, überschreibt er womöglich, was der Nutzer gerade in v4 erarbeitet hat.

Deshalb setzen wir auf Optimistic Concurrency Control (optimistische Nebenläufigkeitskontrolle).

Der Agent erhält beim Lesen eines Objekts dessen aktuelle Version und muss beim Committen einer Änderung die Version mitliefern, auf der sie beruht. Der Server prüft vor dem Schreiben, ob sich das Objekt noch in der erwarteten Version befindet.

Stimmen die Versionen überein, wird die Änderung normal übernommen; wurde das Objekt bereits aktualisiert, lehnt das System Operationen ab, die neuere Inhalte überschreiben könnten, und verlangt, dass der Agent den aktuellen Zustand neu liest.

Allerdings beurteilen verschiedene Arten kreativer Objekte Versionskonflikte mit unterschiedlicher Granularität.

Bei Dokumenten muss ein vollständiges Neuschreiben die zugrunde liegende Version mitliefern. Hat der Nutzer das Dokument bereits geändert, lehnt das System das Überschreiben ab; lokale Änderungen werden über exakte und eindeutige Textausschnitte verortet und nur übernommen, wenn alle erwarteten Ersetzungen zutreffen.

Bei Flows-Workflows setzen wir auf eine feinere Konfliktprüfung. Der Nutzer passt vielleicht gerade einen Einstellungsknoten an, während der Agent gleichzeitig einen anderen Knoten ändert. Würde jede Änderung am Workflow zur Ablehnung führen, könnten beide Seiten wegen des häufigen automatischen Speicherns kaum parallel bearbeiten. Das System prüft daher vor allem, ob sich die Knoten, die der Agent ändern will, verändert haben: Wurde derselbe Knoten bereits vom Nutzer geändert, muss der Agent neu lesen; liegt die Änderung in anderen Knoten, dürfen nicht konfliktbehaftete Änderungen auf den aktuellen Workflow angewendet werden, und der Agent erhält einen Hinweis auf die betreffenden Änderungen.

Dabei werden unterschiedliche Änderungen beider Seiten am selben Inhalt nicht automatisch zusammengeführt. Vielmehr geht es darum, über eine passende Versionsgranularität voneinander unabhängige Bearbeitungen möglichst unabhängig abschließen zu lassen und zugleich zu verhindern, dass ein alter Stand neue Inhalte überschreibt.

sequenceDiagram
    participant A as Agent
    participant O as Gemeinsames Werk
    participant U as Nutzer

    A->>O: Storyboard-Dokument v3 lesen
    U->>O: Storyboard ändern und als v4 speichern
    O-->>A: Hinweis auf Versionsänderung hinterlegen
    Note over O,A: Hinweis wird bei der nächsten Ausführung gelesen

    A->>O: Änderung auf Basis von v3 committen
    O-->>A: Versionskonflikt, Überschreiben abgelehnt
    A->>O: v4 neu lesen
    A->>A: Änderung an den aktuellen Inhalt anpassen
    A->>O: Auf Basis von v4 erneut committen

Abb. 10: Versionskontrolle für gemeinsame Werke.

Hier greifen zudem zwei Mechanismen ineinander: Änderungsbenachrichtigungen lassen den Agenten Aktualisierungen eines Werks rechtzeitig wahrnehmen, Versionsprüfungen bieten beim Committen den letzten Schutz. Selbst wenn eine Benachrichtigung verzögert eintrifft, kann der Agent die Änderungen des Nutzers nicht direkt mit einem veralteten Stand überschreiben.

Natürlich löst optimistische Nebenläufigkeitskontrolle die Frage der Zustandskonsistenz, nicht aber Konflikte zwischen kreativen Absichten. Möchte der Nutzer etwa kühle Farbtöne für eine Einstellung, während der Agent laut ursprünglichem Plan weiter warme Töne verwendet, muss die Entscheidung auch ohne Versionskonflikt anhand der aktuellen Absicht des Nutzers und der Vorgaben der Aufgabe getroffen werden.

9.4 Von Artifacts und Canvas zum gemeinsamen kreativen Arbeitsraum

Beim Interaktionsdesign haben wir uns an Produkten wie Claude Artifacts und ChatGPT Canvas orientiert.

Diese Produkte lösen generierte Inhalte aus gewöhnlichen Chatnachrichten heraus: Nutzer können Dokumente oder Code direkt neben dem Dialog ansehen und bearbeiten und müssen Änderungsdetails nicht immer wieder in natürlicher Sprache beschreiben.

Für Lomo Agent ist diese Interaktionsform eine wertvolle Referenz. Kreative möchten oft lieber direkt einen Knoten verschieben, einen Abschnitt des Storyboards ändern oder ein Bild austauschen, statt dem Agenten jeden Handgriff erneut zu beschreiben.

Der gemeinsame Workspace von Lomo Agent muss allerdings auch Szenarien bewältigen, die über gewöhnliche Dokumentbearbeitung hinausgehen.

Zum einen sind die kreativen Objekttypen komplexer: Neben Text gibt es Bilder, Videos, 3D-Assets und Flows-Workflows mit Abhängigkeiten zwischen Knoten. Zum anderen kann dasselbe Werk von mehreren Aufgaben referenziert werden, während gleichzeitig asynchrone Generierungsjobs laufen und der Nutzer direkt Änderungen vornimmt. Das System muss daher nicht nur den Inhalt der Werke pflegen, sondern auch Versionen, zugehörige Aufgaben und den Kenntnisstand über den Zustand der Werke während der Ausführung.

Deshalb verbinden wir den bearbeitbaren Workspace mit dem Ausführungszustand des Agenten: Nutzer können Werke direkt bearbeiten, und der Worker holt sich bei der weiteren Ausführung den gültigen Objektzustand neu.

Zum Vergrößern klicken

Nach unserer bisherigen Erfahrung besteht eine wichtige Veränderung durch den gemeinsamen Workspace darin, dass Nutzer sich auf zwei Wegen – per natürlicher Sprache und per direkter Bearbeitung – am selben kreativen Prozess beteiligen können. Damit trägt das System aber auch mehr Verantwortung für Zustandssynchronisation und Nebenläufigkeitskontrolle. Gerade wenn ein Asset mehrere Aufgaben zugleich beeinflusst, bleibt die Frage, wie sich Abhängigkeiten zwischen Objekten verwalten lassen und welche nachgelagerten Ergebnisse nach einer vorgelagerten Änderung neu generiert werden müssen, eine Richtung, die wir weiter erforschen.

10. Orchestrierung kreativer Fähigkeiten: vom Modellaufruf zum fertigen Werk

Auf einer Kreativplattform wie Lomote AI muss der Agent nicht nur Tools auswählen und aufrufen, sondern auch die Beziehungen zwischen verschiedenen kreativen Fähigkeiten verstehen.

Ein Bild zu generieren ist relativ einfach. Ein kompletter Kurzfilm kann dagegen Drehbuch, Storyboard, Figurendefinition, Szenenreferenzen, Generierung der Einstellungen und Nachbearbeitung umfassen. In jeder Phase kommen womöglich andere Modelle zum Einsatz, und die Ergebnisse einer Phase wirken sich direkt auf die nachfolgende Produktion aus. Noch wichtiger: Dass ein einzelner Generierungsjob gelingt, heißt nicht, dass der gesamte kreative Ablauf reibungslos zum Abschluss kommt.

Angenommen, der Agent plant folgendes Vorgehen: zuerst Figur und Hintergrund generieren, dann die Figur freistellen und schließlich in eine bestimmte Videoszene einsetzen. Verfügt die Plattform derzeit nicht über die nötigen Fähigkeiten zum Freistellen oder zur Videokomposition, kann der gesamte Plan kein fertiges Werk hervorbringen – so gut die zuvor generierten Assets auch sein mögen.

Deshalb muss der Agent schon in der Planungsphase verstehen, welche Fähigkeiten die Plattform tatsächlich bietet und welche Abhängigkeiten zwischen den verschiedenen Tools und Ergebnissen bestehen.

10.1 Den Agenten kreative Abläufe und Fähigkeitsgrenzen verstehen lassen

Lomote AI integriert bereits eine Reihe von Modellen zur Generierung und Verbesserung von Bildern, Videos und 3D-Inhalten und bietet zudem Asset-Verwaltung und visuelle Flows-Workflows.

Jedes dieser Tools hat seine eigenen Einsatzszenarien, und die Modelle unterscheiden sich bei Eingabebedingungen, Generierungsqualität, Kosten und Ausgabeformat.

Für den Agenten heißt das: Bei der Wahl eines Tools muss er das aktuelle kreative Ziel, vorhandene Assets und die Anforderungen der nachfolgenden Produktion zusammen berücksichtigen.

Bei einem Kurzfilm mit einer festen Figur muss der Agent etwa überlegen, wie er eine Figurenreferenz aufbaut, welche Modelle Referenzbilder als Eingabe unterstützen, wie die visuelle Konsistenz über verschiedene Einstellungen hinweg gewahrt bleibt und ob die Ergebnisse in die weitere Produktion einfließen können. Ruft er die Modelle nur anhand des Endziels des Nutzers auf, entstehen leicht massenhaft Zwischenergebnisse, die gut aussehen, für das finale Werk aber unbrauchbar sind.

Deshalb haben wir kreatives Erfahrungswissen und Einschränkungen der Tool-Fähigkeiten in bedarfsweise abrufbaren Leitfäden aufbereitet – zu Figurenkonsistenz, Storyboard-Planung, Umgang mit Referenzmaterial, Workflow-Orchestrierung und den Produktionsfähigkeiten, die die Plattform aktuell unterstützt. Diese Leitfäden werden dem Agenten bei passenden Aufgaben bereitgestellt und helfen ihm, ausführbare kreative Schritte zu planen, ohne dass das gesamte Fachwissen dauerhaft im System-Prompt stehen muss.

Auch dieser Teil greift mit dem oben beschriebenen Context Engineering ineinander: Der Agent holt sich je nach aktueller Produktionsphase die nötigen Tools und das kreative Wissen und plant und führt dann auf Basis der tatsächlichen Fähigkeiten aus.

Sich darauf zu verlassen, dass das Modell Tool-Beschreibungen versteht, hat natürlich Grenzen. Das Modell schlägt womöglich Produktionspläne vor, die plausibel wirken, sich aber nicht umsetzen lassen. Für zentrale Tool-Fähigkeiten, Ein- und Ausgabebeschränkungen und Ausführungsbedingungen muss das System daher weiterhin eindeutige Prüfgrundlagen bereitstellen.

10.2 Multi-Agent-Videoproduktion am Beispiel von ViMax

Bei der Erkundung der Orchestrierung kreativer Fähigkeiten habe ich mir auch Multi-Agent-Systeme für Videogenerierung wie ViMax angesehen.

ViMax organisiert Drehbuch, Figuren, Storyboard, Generierung der Einstellungen und Videomontage in einem gemeinsamen Produktionsablauf und bearbeitet die miteinander verflochtenen Aufgaben der Videoproduktion durch das Zusammenspiel verschiedener Rollen oder Ausführungsphasen.

Dieser Ansatz ist eine wertvolle Referenz. Videoproduktion ist von Natur aus in Phasen gegliedert, und jede Phase hat ihre eigenen Schwerpunkte: Die Drehbuchplanung konzentriert sich auf die Erzählstruktur, das Figurendesign auf visuelle Konsistenz, und die Generierung der Einstellungen muss die Eingabebedingungen und Ergebnisse konkreter Modelle berücksichtigen.

Eine spezialisierte Arbeitsteilung lässt jede Phase um relativ klar umrissene Zuständigkeiten herum arbeiten und erleichtert es, komplexe Produktionsabläufe zu organisieren.

Allerdings gibt es auch bei solchen Architekturen Abwägungen. Zum einen erhöht die Zusammenarbeit mehrerer Agenten die Kosten für Kontextweitergabe, Zustandssynchronisation und Koordination; zum anderen deckt eine vordefinierte Produktionspipeline nicht unbedingt die sich ständig ändernden kreativen Anforderungen der Nutzer ab.

Die Szenarien von Lomo Agent sind offener. Ein Nutzer braucht vielleicht nur ein einzelnes Plakat, möchte aus vorhandenen Assets ein Video generieren oder bittet den Agenten direkt, einen Flows-Workflow zu ändern. Für jede kreative Anforderung eine feste Multi-Agent-Pipeline einzuführen, könnte im Gegenteil unnötige Ausführungsebenen schaffen.

Derzeit setzen wir deshalb eher auf ein einheitliches System zur Aufgabenausführung, kombiniert mit bedarfsweise geladenen kreativen Leitfäden und Tool-Fähigkeiten, damit der Worker die Produktionsschritte anhand des konkreten Ziels organisiert. Für komplexe kreative Aufgaben, die langfristig gepflegt werden müssen, wollen wir nach und nach eine klarere spezialisierte Arbeitsteilung und die Verwaltung von Aufgabenabhängigkeiten erkunden. Diese Abwägung entspricht auch dem oben beschriebenen Main/Task-Design: Eine zusätzliche Koordinationsebene lohnt sich erst, wenn ein eigenständiger Ausführungsraum einen echten Nutzen bringt.

10.3 Produktions-Abhängigkeitsgraph: von linearer Ausführung zum Abhängigkeitsmanagement

Die strukturierte Ausführungs-Checkliste hilft dem Agenten bereits, den kreativen Fortschritt zu pflegen. Umfasst eine Aufgabe jedoch viele miteinander verflochtene Assets und Generierungsschritte, stößt die lineare Struktur der Liste an Grenzen.

Ein Kurzfilm besteht etwa aus mehreren Einstellungen, die womöglich dieselbe Figurendefinition teilen, aber unterschiedliche Szenen und Generierungsmodelle verwenden.

Manche Einstellungen lassen sich unabhängig generieren, andere müssen warten, bis das vorgelagerte Referenzmaterial fertig ist. Ändert der Nutzer zwischendurch das Aussehen einer Figur, müssen die betroffenen Einstellungen womöglich neu generiert werden – völlig unabhängige Szenen sollten davon aber unberührt bleiben.

Solche Beziehungen lassen sich besser als Production DAG (gerichteter azyklischer Produktionsgraph) ausdrücken.

flowchart LR
    BR["Kreative Anforderung"] --> SCRIPT["Drehbuch / Storyboard"]

    SCRIPT --> CHAR["Figurendefinition"]
    SCRIPT --> SCENE["Szenendefinition"]

    CHAR --> SHOT1["Einstellung 1"]
    CHAR --> SHOT2["Einstellung 2"]

    SCENE --> SHOT1
    SCENE --> SHOT2

    SHOT1 --> REVIEW["Abnahme und Zusammenführung"]
    SHOT2 --> REVIEW

    REVIEW --> FINAL["Finale Lieferung"]

Abb. 11: Der geplante Produktions-Abhängigkeitsgraph.

In einer solchen Struktur steht jeder Knoten für einen Produktionsschritt oder ein Zwischenergebnis, und die Verbindungen zwischen den Knoten beschreiben ihre Abhängigkeiten.

Werden diese Beziehungen strukturiert erfasst, eröffnen sich für das System mehrere Fähigkeiten:

• Abhängigkeitsbasiertes Scheduling: Ein nachgelagerter Schritt wird erst ausgeführt, wenn die nötigen vorgelagerten Assets fertig sind.

• Parallele Generierung: Einstellungen ohne direkte Abhängigkeit können parallel ausgeführt werden, sofern Ressourcen und Budget es zulassen.

• Änderungspropagation: Ändert sich die Definition einer Figur oder Szene, lassen sich die womöglich betroffenen nachgelagerten Ergebnisse ermitteln, statt pauschal alles neu zu generieren.

• Inkrementelle Produktion: Noch gültige Assets und Generierungsergebnisse werden so weit wie möglich wiederverwendet, um wiederholte Aufrufe und unnötige Produktionskosten zu vermeiden.

Ein Abhängigkeitsgraph bringt allerdings zusätzliche technische Komplexität mit sich. Gerade bei kreativen Aufgaben stehen Abhängigkeiten nicht immer eindeutig fest: Ob nach der Änderung eines vorgelagerten Assets ein nachgelagertes Ergebnis zwingend neu generiert werden muss, hängt vom Umfang der Änderung und den konkreten Produktionsanforderungen ab.

Und selbst bei korrekten Abhängigkeiten ist nicht garantiert, dass die Ergebnisse visuell den Erwartungen entsprechen. Figurenkonsistenz, Kontinuität der Einstellungen und Gesamtrhythmus erfordern weiterhin eigene Mechanismen zur Qualitätsbewertung.

Der Production DAG ist daher derzeit eher eine Entwicklungsrichtung, die wir erkunden. Aktuell stellen wir vorrangig sicher, dass der Agent im Rahmen der vorhandenen Modelle und Tools von Lomote AI ausführbare kreative Abläufe umsetzt und Kosten und Gültigkeit von Zwischenergebnissen im Griff behält.

Je weiter Aufgabenabhängigkeiten, automatische Abnahme und multimodales Verständnis ausreifen, desto eher lassen sich diese Mechanismen künftig kombinieren, sodass der Agent nicht mehr nur kreative Aufgaben Schritt für Schritt ausführt, sondern den gesamten Produktionsablauf steuert. Um zu beurteilen, ob diese Designs wirklich funktionieren, reicht eine einzelne reibungslose Demo aber bei Weitem nicht aus. Bei komplexen kreativen Aufgaben kommt es auch zu Tool-Fehlern, Änderungen durch den Nutzer, Zustandswiederherstellung und doppelten Generierungen.

Ob diese Entwürfe tatsächlich funktionieren, muss erst noch durch Wiederherstellungsübungen nach Fehlern und End-to-End-Probeläufe der Zusammenarbeit überprüft werden.

11. Technische Validierung: von der Fehlerbehebung bis zur End-to-End-Zusammenarbeit

Agentensysteme haben eine interessante Eigenschaft: Dass jedes einzelne Modul fehlerfrei läuft, heißt noch lange nicht, dass der gesamte Kollaborationsprozess zuverlässig ist.

So kann eine Nachricht korrekt an die zuständige Aufgabe geroutet werden und ein Tool-Aufruf erfolgreich zurückkehren – und der Agent vergisst nach Abschluss der Generierung trotzdem, weiterzumachen. Oder jeder einzelne Schritt verläuft wie erwartet, am Ende entstehen aber mehrere doppelte Dokumente, und der Nutzer weiß nicht, welches die aktuelle Version ist.

Solche Probleme lassen sich mit klassischen Unit-Tests oder ein paar einfachen Dialogrunden kaum aufdecken.

Bei der Entwicklung von Lomo Agent haben wir deshalb nicht nur die Korrektheit der einzelnen Module geprüft, sondern den Agenten auch in möglichst realitätsnahen Nutzungsszenarien komplette Abläufe durchlaufen lassen, um zu beobachten, wie sich die Mechanismen im Zusammenspiel tatsächlich verhalten.

11.1 Zuverlässigkeitsprüfung der Runtime

Bei Mechanismen wie Durable Execution, Nachrichten-Inbox, asynchroner Generierung und Freigaben durch den Nutzer treten viele Probleme nur bei ganz bestimmten Zustandsübergängen auf.

Zum Beispiel:

• Eine Videogenerierungsanfrage ist bereits abgesendet, doch der Worker startet neu, bevor er das Ergebnis speichert

• Ein alter Worker verliert die Verbindung, ein neuer Prozess übernimmt, und dann setzt der alte die Ausführung fort

• Genau in dem Moment, in dem der Nutzer auf „Stoppen“ klickt, trifft ein Abschlussereignis einer Generierung ein

In normalen Demos kommen solche Situationen selten vor, sie können aber Ausführungszustand, Werke der Nutzer und sogar tatsächliche Kosten direkt beeinflussen. Deshalb haben wir in der Entwicklungsphase mit Fault-Injection-Tests gezielt geprüft, wie das System mit diesen Ausnahmesituationen umgeht.

Die Tests decken konkret die folgenden zentralen Ausführungsgrenzen ab:

Für Modellausgaben, die sich stabil reproduzieren lassen, können wir feste Ergebnisse wiederabspielen und so gezielt die Zustandsübergänge der Runtime prüfen. Externe Generierungsdienste lassen sich mit Timeouts, doppelten Callbacks und Events in falscher Reihenfolge simulieren, sodass wir nicht jedes Mal auf echte, kostenpflichtige Modelle angewiesen sind. Im Mittelpunkt dieser Tests steht das deterministische Verhalten des Systems: Auch wenn das Modell selbst eine gewisse Zufälligkeit aufweist, müssen für Aufgabenzustand, Ausführungsrechte und Abrechnungsregeln eindeutige und überprüfbare Regeln gelten.

Ein recht repräsentativer Test simuliert, dass ein Worker während einer Tool-Ausführung plötzlich „hängen bleibt“. Im Test liefert das Modell eine feste Ausgabe und entscheidet zunächst, ein Abfrage-Tool aufzurufen; der erste Worker hat die Modellentscheidung bereits gespeichert und den Tool-Aufruf als started vermerkt und wird dann künstlich angehalten. Nach Ablauf seines Lease übernimmt ein zweiter Worker, die Ausführungsgeneration steigt auf 2, und er setzt am Checkpoint fort: Da die Modellentscheidung für diesen Step bereits gespeichert ist, muss er nicht erneut inferieren, sondern schließt den Tool-Aufruf mit demselben Idempotenzschlüssel ab. Zuletzt wird der erste Worker fortgesetzt und versucht, sein verspätetes Ergebnis zu committen.

Das Testergebnis entspricht den Erwartungen: Die Runde endet in completed, die Ausführungsgeneration ist 2; das Modell wurde nur einmal aufgerufen, es gibt nur ein Tool-Ergebnis, und der Zustands-Schreibvorgang des alten Workers wird abgelehnt. Mit Integrationstests decken wir außerdem die erneute Zustellung nach verlorenen Queue-Nachrichten, die idempotente Wiederaufnahme von Generierungsjobs nach der Freigabe, das Verhindern neuer Aufgaben durch bereits abgebrochene Runden, Begrenzungen der Kostenfreigabe sowie das Widerrufen von Erinnerungen ab.

11.2 End-to-End-Probeläufe der Zusammenarbeit

Runtime-Tests können prüfen, ob das System Ausnahmezustände korrekt behandelt, bilden aber das tatsächliche Kollaborationserlebnis mit dem Agenten nicht vollständig ab.

Ein Beispiel: Der Agent schließt die Storyboard-Planung erfolgreich ab, hält in der nächsten Phase aber einfach an und beginnt erst mit der Videogenerierung, wenn der Nutzer erneut „weiter“ eingibt. Aus Sicht der Programmausführung ist das vielleicht kein Fehler, für den Nutzer fühlt sich der Ablauf aber offensichtlich nicht natürlich an.

Deshalb habe ich Szenario-Probeläufe eingeführt.

In einer isolierten Umgebung lasse ich den Agenten mit einem echten Textmodell, simulierten Generierungsdiensten und einem simulierten Nutzer mit vordefiniertem Verhalten einen relativ vollständigen kreativen Ablauf durchspielen.

Die Szenarien umfassen Plakatserien, Kurzfilmproduktion, Änderungen an Flows-Workflows, 3D-Kreation, Wechsel zwischen mehreren Aufgaben, das Wiederaufnehmen früherer Aufgaben sowie das Korrigieren und Vergessen von Erinnerungen. Sie beinhalten sowohl fortlaufende Modell- und Tool-Aufrufe als auch Bestätigungen durch den Nutzer, asynchrones Warten und aufgabenübergreifende Kontextverknüpfungen.

Im Kurzfilm-Szenario etwa formuliert der simulierte Nutzer zunächst ein kreatives Ziel, und der Agent muss das Storyboard organisieren, Assets vorbereiten und Generierungsanfragen absenden. Während der Ausführung passt der Nutzer vielleicht den Entwurf an, wählt Einstellungen aus oder schiebt kurzfristig eine andere Aufgabe ein. Uns interessiert dabei nicht nur, ob ein einzelner Schritt gelingt, sondern ob der Agent nach diesen Änderungen weiterhin konsequent am ursprünglichen Ziel weiterarbeitet.

Dabei achte ich besonders auf Folgendes:

• Hält der Agent an den richtigen Punkten an oder macht weiter?

• Muss der Nutzer wiederholt „weiter“ schicken, damit die Aufgabe vorankommt?

• Kommt es zu unnötigen Bestätigungen oder doppelten Generierungen?

• Werden neue Nachrichten korrekt bestehenden Aufgaben zugeordnet?

• Erhält der Agent nach Änderungen des Nutzers am Werk den aktuellen Stand?

• Wird dasselbe Werk unbeabsichtigt in mehrere Kopien aufgespalten?

• Beeinflussen alte Informationen nach dem Korrigieren oder Widerrufen von Erinnerungen weiterhin die spätere Zusammenarbeit?

Im Vergleich zum direkten Aufruf echter Mediengenerierungsdienste hält eine simulierte Umgebung die Testkosten im Griff, erleichtert es, bestimmte Szenarien wiederholt zu konstruieren, und macht Probleme sichtbar, die im modulübergreifenden Zusammenspiel auftreten können.

Auch dieser Ansatz hat aber klare Grenzen. Simulierte Generierungsergebnisse können die visuelle Qualität echter Werke nicht prüfen, und ein simulierter Nutzer mit vordefinierter Strategie kann das komplexe Verhalten in echter Kreativarbeit nicht vollständig abbilden. Die Probeläufe dienen daher vor allem dazu, die Kontinuität von Aufgabenorganisation, Ausführungszustand und Kollaborationsablauf zu prüfen, und stehen nicht unmittelbar für die Erfolgsquote echter Nutzeraufgaben. Die Qualität der finalen Werke und das tatsächliche Nutzungserlebnis müssen weiterhin anhand echter Generierungsergebnisse und des Feedbacks von Nutzern bewertet werden.

11.3 Wie man die Qualität einer Zusammenarbeit misst

Bei diesen Probeläufen wurde mir nach und nach klar, dass sich ein lang laufender Agent kaum vollständig daran messen lässt, ob das Modell flüssig antwortet und Tool-Aufrufe gelingen.

Nutzern sind womöglich ganz andere Fragen wichtiger:

• Wie oft muss ich etwas wiederholt erklären?

• Hat sich der Agent die bereits festgelegten Anforderungen gemerkt?

• Kann ich nach ein paar Tagen ganz natürlich an der bisherigen Arbeit weitermachen?

• Weiß er, was passiert ist, wenn ich ein Werk ändere?

Deshalb achte ich neben der klassischen Ausführungskorrektheit inzwischen auch auf Dimensionen wie Aufgabenkontinuität, Eingriffsaufwand für den Nutzer, wiederholte Operationen und Konsistenz der Ergebnisse.

Die Probeläufe haben auch einige Probleme zutage gefördert, die beim isolierten Testen einzelner Module kaum auffallen.

Bei der Erstellung einer englischsprachigen Plakatserie etwa verstand Main die Anforderung des Nutzers korrekt und legte eine Aufgabe an, doch der Worker wechselte bei der weiteren Planung ins Chinesische. Das Problem lag nicht im Aufgaben-Routing, sondern darin, dass die Aufgabe nur die vom Hauptthread aufbereitete Zielbeschreibung erhielt und ihr die Sprachinformation aus der ursprünglichen Formulierung des Nutzers fehlte. Daraufhin haben wir die Weitergabe der Nutzersprache angepasst, sodass die Aufgabe ihre Antwortsprache anhand der tatsächlichen Eingaben des Nutzers pflegt, statt sich ganz darauf zu verlassen, dass das Modell sie aus der Aufgabenbeschreibung ableitet.

Ein weiteres Problem trat an der Nahtstelle zwischen manuellen Checkpoints und asynchroner Generierung auf. Der Agent erreichte eine Phase, die eine Bestätigung des Nutzers erforderte, bot aber keine bedienbare Bestätigungskarte an; oder der externe Job lief nach der Freigabe einer Generierung durch den Nutzer zwar normal durch, die Aufgabe kam danach aber nicht weiter voran. Für diese Fälle haben wir in der Runtime eine Absicherung durch Bestätigungskarten und ein automatisches Aufwecken nach Abschluss der Generierung ergänzt und so die Abhängigkeit vom Interaktionsverhalten des Modells verringert.

Für sich genommen äußern sich diese Probleme nicht unbedingt als offensichtliche Ausführungsfehler, beeinträchtigen aber direkt die Kontinuität der Zusammenarbeit, die der Nutzer wahrnimmt. Sie haben mir auch noch deutlicher gemacht: Das Modell ist für das Verstehen von Absichten und das Planen von Schritten zuständig, während zentrale Zustände wie Warten, Freigabe und Wiederaufnahme der Ausführung von der Runtime deterministisch abgesichert werden müssen.

Natürlich stehen diese Dimensionen für sich genommen nicht für die Intelligenz eines Agenten. Auf einer Kreativplattform müssen Abschluss des Ablaufs und Qualität des Werks weiterhin getrennt bewertet werden. Ein Agent kann planmäßig alle Einstellungen generieren, ohne dass garantiert ist, dass das finale Video in visuellem Stil, Figurenkonsistenz und Erzählrhythmus den Erwartungen des Nutzers entspricht. Eine verlässlichere multimodale Abnahme bleibt eine Fähigkeit, die wir weiter ausbauen wollen.

Nach bisheriger Erfahrung bieten uns End-to-End-Probeläufe eine relativ gut kontrollierbare Form der Validierung. Sie helfen uns nicht nur, Probleme im modulübergreifenden Zusammenspiel zu finden, sondern stellen auch einige Prinzipien des Architekturdesigns im vollständigen Ausführungsablauf wirklich auf die Probe. Neben dem bloßen Ausbau der Modellfähigkeiten verdient es ebenso kontinuierliche Investitionen, diese Fähigkeiten in der langfristigen Zusammenarbeit stabil ineinandergreifen zu lassen.

12. Offene Probleme und nächste Schritte

Lomo Agent verfügt inzwischen über grundlegende Fähigkeiten wie die Organisation mehrerer Aufgaben, Durable Execution, Kontextverwaltung und einen gemeinsamen Workspace. Bis zu dem kreativen Agenten, den ich mir vorstelle, gibt es aber noch viele Fragen, die es weiter zu erkunden lohnt.

Erstens die aufgabenübergreifende Zusammenarbeit.

Die aktuelle Router/Worker-Struktur lässt mehrere Aufgaben unabhängig vorankommen und bei Bedarf auf gemeinsame Ergebnisse zugreifen. Dürften Worker einander aber aktiv um Hilfe bitten, Aufgaben delegieren oder sogar ein gemeinsames Budget aushandeln, müssten deutlich komplexere Probleme bei Berechtigungen, Zustandssynchronisation und Konsistenz unter Nebenläufigkeit gelöst werden.

Die Zusammenarbeit mehrerer Agenten wirkt verlockend, doch mehr Agenten bedeuten nicht automatisch mehr Effizienz. Zusätzlicher Koordinationsaufwand und Kontextweitergabe können den Gewinn durch Spezialisierung wieder zunichtemachen. Ich möchte zunächst anhand realer Anforderungen herausfinden, welche Arbeit sich aufzuteilen lohnt, und den Umfang der Zusammenarbeit dann schrittweise ausweiten.

Zweitens das Abhängigkeitsmanagement kreativer Abläufe.

Der oben erwähnte Production DAG ist eine Richtung, die mich besonders interessiert. Bei komplexen Produktionen mit mehreren Einstellungen, Figuren und Szenen helfen explizite Abhängigkeiten, parallele Ausführung, inkrementelle Aktualisierungen und die Wiederverwendung von Ergebnissen zu unterstützen.

Abhängigkeiten in kreativen Aufgaben sind jedoch nicht immer eindeutig. Ändert der Nutzer eine Figurendefinition, lässt sich oft nur anhand des konkreten Inhalts beurteilen, welche Einstellungen neu generiert werden müssen und welche weiterverwendet werden können.

Auch die Zuverlässigkeit der asynchronen Generierung lässt sich noch weiter verbessern.

Derzeit kann das System bereits an den Upstream-Dienst übermittelte Generierungsjobs nicht aktiv abbrechen; wurde ein Job bereits angelegt und tritt ein Fehler auf, bevor die Upstream-Job-ID gespeichert ist, fehlt zudem die Möglichkeit, ihn per Rückabfrage wiederzufinden und die Verknüpfung wiederherzustellen.

Für diese Fälle gibt es bereits eine entsprechende Zustandsbehandlung und eine Absicherung der Kosten, doch es können weiterhin unnötige Generierungskosten entstehen. Künftig möchten wir nach und nach die Abbruch- und Abfragefunktionen der Upstream-Dienste anbinden, damit das System Ausführungsunterbrechungen und kurzfristige Änderungswünsche des Nutzers genauer behandeln kann.

Auch die multimodale Qualitätsabnahme ist ein schwieriges Problem.

Derzeit belegen ein erfolgreicher Tool-Rückgabewert und ein abgehakter Checklisten-Schritt nur, dass das System die entsprechende Operation ausgeführt hat. Die tatsächliche Qualität eines Werks hängt zudem von visueller Konsistenz, flüssiger Bewegung, Synchronität von Bild und Ton und dem subjektiven ästhetischen Empfinden des Nutzers ab.

Mit der Weiterentwicklung multimodaler Modelle möchte ich solche Bewertungsfähigkeiten nach und nach in den Ausführungsablauf einbinden, damit der Agent genauer erkennen kann, wann Anpassungen nötig sind, wann sich eine Neugenerierung lohnt und wann er die Entscheidung an den Nutzer zurückgeben sollte.

Darüber hinaus müssen die Genauigkeit des Langzeitgedächtnisses, die Zuverlässigkeit des Aufgaben-Routings und die Grenzen proaktiven Nachhakens weiter überprüft werden.

Herkunftsnachverfolgung und Versionsverwaltung machen das Gedächtnis besser kontrollierbar, können Extraktionsfehler des Modells oder das fälschliche Abrufen historischer Informationen aber nicht vollständig verhindern. Ebenso kombiniert der aktuelle Routing-Mechanismus zwar bereits Aufgabenindex, Suche in der Historie und Duplikatprüfung ähnlicher Aufgaben, um Fehlentscheidungen zu verringern; bei einer großen, über lange Zeit angesammelten Zahl von Aufgaben muss jedoch weiterhin anhand realer Nutzungsdaten gemessen werden, wie genau die Aufgabenzuordnung ist und wie oft Nutzer selbst korrigierend eingreifen müssen.

Beim proaktiven Nachhaken weiß das System vielleicht, dass für eine Aufgabe noch Arbeit aussteht, aber nicht unbedingt, ob der Nutzer gerade gestört werden möchte. Wir wünschen uns, dass künftige Agenten proaktiver werden – doch diese Proaktivität muss auf den Freigaben des Nutzers, dem Wert der Aufgabe und den tatsächlichen Nutzungsgewohnheiten beruhen.

Für viele dieser Probleme wird es kurzfristig nicht unbedingt ausgereifte Lösungen geben. Je mehr echte kreative Szenarien Lomo Agent erschließt, desto häufiger werden wir die bestehende Architektur neu überdenken und prüfen, welche Designs sich wirklich bewähren und welche angepasst werden müssen.

Fazit

Wenn ich auf den Weg von Lomo Agent von der ersten Idee bis zum Launch zurückblicke, habe ich zunehmend den Eindruck, dass die Entwicklung von Agenten die Softwarearchitektur vor einige sehr spannende neue Fragen stellt.

Früher mussten wir beim Softwaredesign meist zuerst klare Funktionen, Abläufe und Interaktionsgrenzen definieren, nach deren Regeln Nutzer dann ihre Aufgaben erledigten. Seit KI Absichten verstehen, Tools aufrufen und selbstständig Entscheidungen treffen kann, lässt sich ein Großteil der Organisations- und Koordinationsarbeit, die bisher bei den Nutzern lag, nach und nach an das System übergeben.

Bessere Modellfähigkeiten sind aber nur ein Teil davon.

Ein Agent, der langfristig mitarbeiten soll, muss auch wissen, woran er gerade arbeitet, was er bereits getan hat, welche Informationen noch gültig sind und unter welchen Umständen er weitermachen oder anhalten sollte. Er muss mit Unterbrechungen, Nebenläufigkeit, Kosten und Berechtigungen in realen Systemen umgehen und Nutzern erlauben, jederzeit ihre Meinung zu ändern.

Die Architektur von Lomo Agent ist ein praktischer Versuch, genau diese Fragen anzugehen. Viele Ideen stammen aus hervorragenden Produkten und Engineering-Praktiken wie DeepSeek, Manus, Claude Code und Temporal, andere habe ich mir nach und nach in meinen eigenen kreativen Szenarien erarbeitet.

Die aktuelle Implementierung befindet sich noch in einer frühen Erkundungsphase; bis zur idealen Form ist es noch ein weiter Weg, und viele Designs müssen sich erst noch im Praxistest mit echten Nutzern bewähren.

Ich bin jedoch nach wie vor überzeugt, dass die Art, wie Menschen und Software miteinander interagieren, mit den stetig wachsenden Fähigkeiten der Modelle noch enormen Gestaltungsspielraum bietet.

Vielleicht müssen wir eines Tages nicht mehr lernen, wie man eine Software bedient, sondern ihr nur noch sagen, was wir erreichen wollen.

In diese Richtung soll sich Lomo Agent immer weiter bewegen.

Wer selbst Agenten baut, ist herzlich eingeladen, Erfahrungen und Fragen zu Architektur und Engineering-Praxis mit uns auszutauschen;

und wer kreativ arbeitet, ist ebenso eingeladen, Lomo Agent mit echten kreativen Vorhaben auszuprobieren.

Lomo Agent ausprobieren: lomo agent

Zum Vergrößern klicken

Zum Vergrößern klicken

Quellen und weiterführende Literatur

Die folgenden Links dienen vor allem dazu, Inspirationsquellen für die Architektur und den Forschungshintergrund aufzuzeigen. Sie bedeuten nicht, dass die jeweiligen Projekte in allen Fähigkeiten dieselbe Implementierung oder dieselben Designziele wie Lomo Agent haben.

1. DeepSeek Super-agent Prototype

2. Temporal — Design Patterns

3. OpenAI — Using Goals in Codex

4. Anthropic — Effective Harnesses for Long-Running Agents

5. Claude Code — Hooks

6. Anthropic — How We Built Our Multi-Agent Research System

7. Manus — Context Engineering for AI Agents

8. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

9. Zep / Graphiti: A Temporal Knowledge Graph Architecture

10. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory

11. OpenClaw — Memory Architecture

12. ViMax — Multi-Agent Video Generation

Hinweis: Bestehende Mechanismen und geplante Weiterentwicklungen sind im Text so weit wie möglich getrennt gekennzeichnet. Die tatsächlichen Fähigkeiten in Bezug auf Idempotenzgarantien externer Dienste, den vom Vergessen abgedeckten Datenumfang, das Caching-Verhalten der Modelle und die Wirksamkeit der automatischen Abnahme hängen jeweils von der konkreten Implementierung und den zugrunde liegenden Abhängigkeiten ab.