Starten Sie mit einer wiederkehrenden Übergabe
Unser Beispiel: Neue Serviceanfragen werden einer zuständigen Gruppe zugeordnet und für die Bearbeitung vorbereitet. Das Ergebnis enthält Anliegen, belegte Eckdaten, fehlende Informationen und einen Antwortentwurf. Die zuständige Person entscheidet über Zusagen. So wird die Übergabe einfacher, ohne dass ein Agent unbemerkt Verträge oder Erwartungen verändert.
Ein Agent lohnt sich eher bei wiederkehrender Reibung als bei einem einmaligen Sonderfall. Prüfen Sie deshalb zunächst, wie häufig Informationen fehlen, Aufgaben weitergereicht werden oder dieselben Rückfragen entstehen. Daraus ergibt sich der eigentliche Auftrag.
Workspace-Agent-Kanal und neue Agents API unterscheiden
Dieser Leitfaden beschreibt den veröffentlichten API-Kanal eines Workspace Agents mit dessen eigenem Zugriffstoken. Seit dem 10. September existiert daneben die Agents API in Public Beta: eine eigene Entwicklungsoberfläche für dauerhafte Sessions und verwaltete Agentenabläufe. Diese beiden Wege sind nicht austauschbar. Ersetzen Sie in einer bestehenden Workspace-Integration deshalb weder Endpunkt noch Token allein wegen der ähnlichen Bezeichnung. Die Architekturentscheidung hält fest, ob ein veröffentlichter Arbeitsraumablauf gestartet oder eine eigene Anwendung entwickelt werden soll.
Angenommen, abgeschlossen, fachlich richtig
Die Trigger-API quittiert angenommene Arbeit mit HTTP 202. Eine Statusabfrage ist als Beta dokumentiert; die eigentliche Agentenantwort lässt sich laut Quelle derzeit nicht über diese API abrufen. Ein erfolgreicher Laufstatus ersetzt daher nicht die Prüfung, ob beispielsweise die richtige Serviceanfrage vorbereitet wurde.
- Denselben Test einmal normal und einmal mit wiederholtem Ereignis ausführen.
- Bei Wiederholungen eine stabile Ereigniskennung zur Vermeidung doppelter Ausführung verwenden.
- Das Ergebnis im Zielsystem prüfen und eine fehlgeschlagene Übergabe gezielt auslösen.
Legen Sie fest, wann der Agent stoppt
Für den Pilot schlagen wir drei Stopps vor: widersprüchliche Kundendaten, eine nicht erlaubte Aktion und ein nicht erreichbares Zielsystem. Jeder Stopp erzeugt einen verständlichen Arbeitsauftrag an eine Person. Ein leerer Rückgabewert darf nicht als „keine offenen Fälle“ interpretiert werden, solange auch ein Zugriffsfehler möglich ist.
Begrenzen Sie die angeschlossenen Konten auf die benötigten Bereiche. Dokumentieren Sie, wer den Agenten betreut, wie Zugangsdaten ersetzt werden und welcher manuelle Ablauf bei Ausfällen weiterläuft. Diese Betriebsregeln gehören zur Abnahme des Piloten.
Vom Pilot zum verbundenen Prozess
Erst wenn normale Fälle und Ausnahmen nachvollziehbar bearbeitet werden, erweitern Sie die Datenquellen oder erlaubten Aktionen. Für mehrere Systeme lohnt sich eine klare Integrationsarchitektur: Zuständigkeit, Ereignisverarbeitung, Freigabe und Ergebnisnachweis werden gemeinsam geplant.
Der KI-Systemcheck zeigt, ob Ihr Engpass eher bei Informationen, Übergaben oder Ausführung liegt. Darauf kann eine KI-Automatisierung mit einem definierten ersten Workflow aufbauen.
Nachvollziehbar bleiben
Primärquellen
- Workspace AgentsQuellenstand:
- Workspace Agent access tokensQuellenstand:
- Codex access tokensQuellenstand:
- Trigger workspace agent runsQuellenstand:
- OpenAI: Agents API overviewQuellenstand:




