KI-Agenten steuern jetzt deine Foto-Pipeline

Am 3. September 2026 veröffentlichte OpenAI GPT-6 Astra, ein Modell, das Software eigenständig bedienen kann: Formulare ausfüllen, Webseiten navigieren, mehrstufige Aufgaben an einem Computer ausführen, nicht nur Fragen dazu beantworten. OpenAIs eigener Mitgründer nannte es einen Schritt in Richtung AGI. Ob es dieses Etikett verdient oder nicht, die Richtung ist eindeutig.

Es ist keine Geschichte eines einzelnen Unternehmens. Anthropics Claude kann seit 2024 einen Computer bedienen. OpenAIs eigener Operator tat dasselbe seit 2025. ChatGPTs Agentenmodus vereinte beide Ideen später im selben Jahr in einem Produkt. Astra ist der neueste, leistungsfähigste Eintrag in einem Muster, das mittlerweile mehrere Veröffentlichungen tief reicht: KI-Systeme, die einem nicht nur sagen, was zu tun ist, sondern es selbst erledigen.

Diese Verschiebung verändert, was "für KI gebaut" für jedes Stück Software bedeuten muss, das ein Agent berühren könnte. Eine Chat-Oberfläche reicht für einen Menschen. Ein Agent braucht etwas ganz anderes: einen Endpunkt, den er aufrufen kann, einen Job, den er starten und prüfen kann, ein Ergebnis, das er abrufen kann, wenn die Arbeit erledigt ist. Software, die nur ein Prompt-Feld und einen Download-Button bietet, ist eine Sackgasse für einen Agenten, egal wie gut das Modell dahinter ist.

Der Teil, den On-Model schon richtig gemacht hat

Wir haben diese Idee aus Käufersicht bereits behandelt, in KI-Infrastruktur für Modebilder: On-Model wurde als Infrastruktur gebaut, die ein Händler in seine Pipeline einbindet, nicht als kreatives Tool, das eine Person öffnet, um ein Bild zu erstellen. Diese Unterscheidung erweist sich jetzt aus einem ganz anderen Grund als wichtig. Infrastruktur ist per Definition dafür gebaut, von etwas anderem als einer Person aufgerufen zu werden, die sich durch eine Oberfläche klickt. On-Model hat eine REST-API, asynchrone Job-IDs, Webhooks und Batch-Verarbeitung, seit bevor "agentische KI" überhaupt ein Begriff war. Wir haben das nicht für Agenten gebaut. Wir haben es gebaut, weil eine Produktions-Pipeline unbeaufsichtigt laufen muss, und es stellt sich heraus, dass das genau die Form von Schnittstelle ist, die auch ein Agent braucht.

Ob der Aufrufer eine Person in der App ist, ein Skript in einem nächtlichen Cron-Job oder jetzt ein autonomer Agent, der auf ein in Alltagssprache formuliertes Ziel reagiert, die Interaktion dahinter ist identisch:

Agent erhält ein Ziel
        │
Authentifizieren (Bearer-Token)
        │
Projekt anlegen oder wiederverwenden
        │
Jedes Produktbild hochladen  →  erhält eine file_id
        │
Job starten — Model Swap / Flat-to-Model / Packshot / Garment Recolor
        │
Fortschritt beobachten (Event-Stream oder Webhook)  →  status: completed
        │
Ergebnisse abrufen  →  fertige Bild-URLs
        │
Übergabe an PIM / DAM / Storefront

Für einen Agenten, der die API steuert, ändert sich nichts an der API. Das ist der Punkt.

Was ein Agent tatsächlich aufruft

Ein Agenten-Framework liest nicht unsere Dokumentation, es liest eine Tool-Definition. Hier ist ungefähr die Form, die man für den Model-Swap-Endpunkt registrieren würde, direkt aus den echten Request-Feldern aufgebaut:

{
"name": "start_model_swap_job",
"description": "Swap an approved brand identity onto one or more uploaded product images and start an async job.",
"parameters": {
  "type": "object",
  "properties": {
    "identity_code": {
      "type": "string",
      "description": "The approved model identity to apply"
    },
    "project_id": { "type": "string" },
    "images": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Uploaded file_id values"
    },
    "swap_options": {
      "type": "object",
      "properties": {
        "model": { "type": "string", "enum": ["auto", "onda", "nano_banana_2"] },
        "num_variations": { "type": "integer", "minimum": 1, "maximum": 4 },
        "use_anchor": { "type": "boolean" }
      }
    }
  },
  "required": ["identity_code", "project_id", "images"]
}
}

Aufrufen, eine job_id zurückbekommen, und entweder pollen oder sich per Webhook benachrichtigen lassen, wenn der Job fertig ist. Alles andere — Flat-to-Model, Create-Packshot, Garment Recolor — folgt demselben Muster: Job anfragen, laufen lassen, Ergebnisse abrufen. Es ist dokumentiert, egal ob die Leserin ein Entwickler ist oder das, was die Anfrage erzeugt, ein Sprachmodell ist.

Eine Montagmorgen-Aufgabe

Angenommen, eine Ops-Verantwortliche sagt ihrem Agenten: "Die Herbst-Hoodie-Kollektion ist gerade angekommen. Zieh unsere Priya-Identität drüber und mach die Zalando- und Shopify-Größen fertig, bevor das Standup beginnt." Ein leistungsfähiger Agent braucht keine Person, die das in Klicks übersetzt. Er kann:

1. Den PIM-Feed nach den neuen SKUs durchsuchen und die Flat-Lay-Bilder abrufen.
2. Jedes einzelne hochladen und die file_id-Werte sammeln.
3. Einen model-swap-Job starten, mit identity_code auf die freigegebene Markenidentität gesetzt, use_anchor aktiviert, damit das Modell über das ganze Set hinweg wie dieselbe Person aussieht.
4. Den Event-Stream des Jobs beobachten, bis jedes Bild completed meldet.
5. Die Ergebnisse abrufen und entweder direkt auf die Marketplace-Vorgaben zuschneiden oder einen Folge-Job mit der passenden width/height pro Plattform starten.
6. Die fertigen Dateien zurück ins DAM einspielen und mit einem Link "erledigt" melden.

Das ist dasselbe Playbook, das ein Produktionskoordinator heute manuell abarbeitet, nur ausgeführt von etwas, das zwischen Schritt 2 und 5 nicht schläft. Nichts an dieser Abfolge ist spekulativ. Es sind sechs Aufrufe an eine API, die bereits existiert.

Warum die ganze Kategorie sich in diese Richtung bewegt

Computer-use-Agenten werden immer besser in genau der Art mühsamer, mehrstufiger, strukturierter Arbeit, aus der eine Content-Pipeline besteht: Feed prüfen, Batch verarbeiten, Output weiterleiten, Ankunft bestätigen. Das begünstigt Software, die von Anfang an als Infrastruktur gebaut wurde, gegenüber Software, die immer nur eine Person am anderen Ende der Anfrage erwartet hat. Ein Prompt-Feld-Tool bietet einem Agenten nichts, woran er ansetzen kann. Ein System, das auf Jobs, IDs und Statusabfragen aufgebaut ist, ist genau die Oberfläche, für die ein Agent gemacht ist.

On-Model musste nicht erst "agentenfähig" werden. Es war das schon, weil wir es von Anfang an als Infrastruktur gebaut haben und nicht als kreatives Tool. GPT-6 Astra schafft diese Tatsache nicht, es macht sie nur neu relevant. Während Agenten mehr von der operativen Arbeit übernehmen, die Modeteams heute manuell erledigen, sind die Plattformen, die bereits API sprechen und nicht nur Chat, diejenigen, die ein Agent tatsächlich aufgreifen und ausführen kann.

• API-Integration — Endpunkte, Schnellstart und Code-Beispiele, um On-Model in eine Pipeline einzubinden
• API-Dokumentation — Authentifizierung, vollständige Request-/Response-Form für jeden Job-Typ
• KI-Infrastruktur für Modebilder — warum wir On-Model als Pipeline gebaut haben, nicht als Prompt-Feld
• Fünf Input-Typen, eine Plattform — die Job-Typen, die ein Agent (oder ein Mensch) starten kann
• On-Model kostenlos testen — API-Token holen und den ersten Job in Minuten starten