UiPath Autopilot erstellt API-Workflows aus natürlicher Sprache
Der Coding-Agent in Studio Web verbindet Beschreibung, API-Aufrufe, Tests und Orchestrator-Veröffentlichung in einer Oberfläche.
UiPath hat Autopilot im September 2026 als Coding-Agent für API-Workflows in Studio Web in die öffentliche Vorschau gebracht. Eine natürlichsprachliche Vorgabe kann damit zum Ausgangspunkt eines strukturierten Workflows werden: Autopilot schlägt Aktivitäten und Code vor, verbindet API-Aufrufe und hilft dabei, das Ergebnis zu validieren, auszuführen und in Orchestrator zu veröffentlichen.
Der entscheidende Sprung liegt in der zusammenhängenden Bearbeitung. Statt jede Aktivität einzeln auszuwählen und zu konfigurieren, lässt sich zunächst beschreiben, welche Systeme miteinander sprechen und wie Daten behandelt werden sollen. Der Agent kann anschließend auch einen bestehenden API-Workflow verändern. UiPath kennzeichnet die Unterstützung allerdings als experimentell und empfiehlt, generierte Workflows vor der Ausführung oder Veröffentlichung zu kontrollieren.
Das ist seit September 2026 neu
Die Funktion gehört zu Studio Web und benötigt laut Release Notes vom September 2026 weder eine lokale Installation noch eine bestimmte installierte Produktversion. Der Zugang erfolgt über die cloudbasierte Entwicklungsumgebung. Der Status „Public Preview“ bedeutet, dass Interessierte die Funktion bereits einsetzen können, sie aber noch nicht den Reifegrad einer allgemein verfügbaren Produktfunktion besitzt.
Autopilot wird dabei nicht nur als Textgenerator eingesetzt. UiPath beschreibt ihn als agentischen Assistenten, der Automatisierungen planen, erstellen, ausführen, debuggen und erklären kann. Für API-Workflow-Projekte umfasst das den Aufbau aus einer Beschreibung, die Einbindung von Connector-Aktivitäten sowie Validierung und Start des erzeugten Ergebnisses. Modellzugriff, Autonomiestufe und verfügbare Werkzeuge lassen sich zentral über Automation Ops steuern.
Damit unterscheidet sich die Vorschau von einer bloßen Codevervollständigung: Der Chat arbeitet auf der Ebene des gesamten API-Workflows. Er kann vorhandene Strukturen einbeziehen und Änderungen an mehreren zusammengehörigen Aktivitäten vorschlagen, anstatt nur eine isolierte JavaScript-Zeile zu formulieren.
Eine Anforderung wird zum strukturierten API-Workflow
Ein konkreter Anwendungsfall ist die Übergabe von Bestelldaten zwischen zwei Geschäftssystemen. Die Vorgabe könnte lauten: „Rufe die neuen Bestellungen über die vorhandene API-Verbindung ab, verarbeite nur freigegebene Einträge und übergib die benötigten Felder an das Zielsystem. Behandle fehlerhafte Antworten getrennt.“ Diese Formulierung benennt Quelle, Auswahlregel, Ziel und Ausnahmefall – genau die Informationen, aus denen Autopilot passende Workflow-Bausteine ableiten kann.
Nach der Beschreibung schlägt der Agent strukturierte Schritte vor. Dazu können HTTP-Anfragen, Aktivitäten aus UiPaths Integration Service, Kontrollfluss und JavaScript gehören. Die Ausgabe ist damit nicht lediglich ein Textvorschlag, sondern ein bearbeitbarer API-Workflow in Studio Web. Welche Verbindung und welche Datenstruktur tatsächlich passen, bleibt im Projekt sichtbar und kann dort angepasst werden.
Besonders nützlich ist diese Arbeitsweise bei Abläufen, deren fachliche Regel bereits klar ist, deren technische Verdrahtung aber viele einzelne Konfigurationsschritte verlangt. Der Prompt ersetzt dabei keine präzise Aufgabenbeschreibung. Je genauer Eingangsdaten, Auswahlbedingungen, Zielaktion und erwartetes Fehlerverhalten formuliert sind, desto gezielter kann der Agent Aktivitäten und Code vorschlagen.
HTTP-Aufrufe und Connectoren lassen sich kombinieren
Autopilot ist nicht auf eine einzige Integrationsart festgelegt. Laut Dokumentation zu API-Workflows unterstützt die Vorschau sowohl HTTP-Anfragen als auch Connector-Aktivitäten des Integration Service. Das erlaubt zwei unterschiedliche Zugänge innerhalb desselben Projekts: Ein vorhandener Connector kann standardisierte Aktionen bereitstellen, während eine HTTP-Anfrage einen API-Endpunkt direkt anspricht.
Diese Verbindung bietet sich beispielsweise an, wenn ein angebundenes Geschäftssystem über einen Connector angesprochen wird, eine ergänzende Funktion aber nur als HTTP-Endpunkt verfügbar ist. Autopilot kann beide Aktivitätstypen in den Workflow einordnen. Die zugehörigen API-Verbindungen werden im Projekt verwaltet; Zugangsdaten müssen deshalb nicht in eine frei formulierte Anweisung geschrieben werden.
Auch Integration-Service-Trigger können Bestandteil eines API-Workflows sein. Für die Kostenrechnung nennt UiPath sie gemeinsam mit Connector-Aktivitäten, HTTP Requests sowie Skript- und Kontrollflussaktivitäten als Bestandteile der pauschal gemessenen Ausführung. Welche Aktivität gewählt wird, hängt somit nicht allein von der Syntax des Prompts ab, sondern von den im Projekt verfügbaren Verbindungen und dem gewünschten API-Zugriff.
Kontrollfluss und JavaScript ergänzen die Verbindung
Reine Datenübergabe ist nur ein Teil vieler API-Aufgaben. Häufig müssen Antworten ausgewertet, Felder umgeformt oder Aktionen von Bedingungen abhängig gemacht werden. Dafür kann Autopilot Kontrollfluss und JavaScript in den Workflow aufnehmen. Der Studio-Web-Leitfaden hebt hervor, dass der Agent bei JavaScript-Ausdrücken den Kontext des Workflows und seiner Objektstrukturen berücksichtigt.
In der Praxis sollte eine Anweisung daher nicht nur „Daten übertragen“ fordern. Hilfreicher ist eine konkrete Regel wie: „Führe die Zielaktion nur aus, wenn der Status freigegeben ist; bereite aus den vorhandenen Feldern das benötigte Objekt auf; leite eine fehlerhafte API-Antwort in eine getrennte Behandlung.“ So erhält der Agent Anhaltspunkte für Bedingung, Transformation und Fehlerpfad.
Besteht bereits ein API-Workflow, kann der Chat ihn bearbeiten. Eine gezielte Änderung könnte etwa verlangen, eine zusätzliche Bedingung vor einer vorhandenen Connector-Aktivität einzufügen oder die Behandlung einer HTTP-Antwort anzupassen. Das ist vor allem dann interessant, wenn die Grundstruktur erhalten bleiben soll und nur ein Teil der Logik geändert wird.
Gute Vorgaben beschreiben Daten und Verhalten
Für brauchbare Ergebnisse sollte die Beschreibung vier Dinge eindeutig benennen: den fachlichen Zweck, die vorhandene Verbindung, die zu verarbeitenden Daten und das Verhalten bei abweichenden Antworten. Diese Angaben helfen Autopilot, nicht nur Aktivitäten auszuwählen, sondern sie im richtigen Zusammenhang vorzuschlagen.
Eine kompakte Vorgabe kann nach diesem Muster formuliert werden: „Nutze die vorhandene Verbindung zu System A. Lies die neuen Datensätze aus. Verarbeite nur Einträge mit Status B. Übertrage die Felder C und D an System E. Wenn der Aufruf scheitert, erfasse den Fehler getrennt.“ Die Bezeichnungen A bis E werden dabei durch die realen Verbindungen, Statuswerte und Felder des Projekts ersetzt.
Bei JavaScript ist zusätzlich das gewünschte Resultat wichtig. Statt allgemein eine „Transformation“ anzufordern, sollte die Anweisung sagen, welche vorhandenen Felder in welcher Objektstruktur benötigt werden. Autopilot kann den Workflow-Kontext berücksichtigen; eindeutig benannte Ein- und Ausgabestrukturen reduzieren trotzdem den Interpretationsspielraum.
Validierung, lokale Läufe und Evaluationstests
Der Agent unterstützt die Strecke über die Generierung hinaus. Nach UiPaths Vorschau-Dokumentation kann er API-Workflows validieren und lokal ausführen. Evaluationstests gehören ebenfalls zum beschriebenen Funktionsumfang. Damit lässt sich das vorgeschlagene Verhalten in Studio Web untersuchen, bevor der Workflow in Orchestrator veröffentlicht wird.
Validierung und Test erfüllen unterschiedliche Aufgaben. Die Validierung deckt Probleme in der Struktur oder Konfiguration auf. Ein lokaler Lauf zeigt, wie sich der Workflow mit den verwendeten Verbindungen und Daten verhält. Evaluationstests prüfen, ob erwartete Ergebnisse erreicht werden. Keine dieser Funktionen macht eine inhaltliche Prüfung der generierten Logik überflüssig: Eine formal gültige Bedingung kann fachlich trotzdem den falschen Status auswählen.
Besondere Aufmerksamkeit verdienen die Punkte, die Autopilot aus natürlicher Sprache ableitet: ausgewählte Verbindung, URL und Methode eines HTTP-Aufrufs, verwendete Objektfelder, Bedingungen, JavaScript-Ausdrücke sowie die Reaktion auf Fehler. UiPath empfiehlt ausdrücklich, einen generierten Workflow vor dem Ausführen oder Veröffentlichen zu prüfen. Das ist bei einer experimentellen Funktion nicht nur ein allgemeiner Vorsichtshinweis, sondern die sinnvolle Grenze zwischen Generierung und freigegebener Automatisierung.
Von Studio Web nach Orchestrator
Ist der Workflow passend konfiguriert und geprüft, unterstützt Autopilot auch die Veröffentlichung in Orchestrator. Studio Web deckt damit Entwurf, Bearbeitung und lokale Erprobung ab; Orchestrator übernimmt den veröffentlichten Workflow. Die Oberfläche bleibt der zentrale Ort, an dem die vom Agenten vorgeschlagenen Aktivitäten und Ausdrücke nachvollzogen werden können.
Die Verwaltung über Automation Ops ergänzt diese technische Strecke auf Organisationsebene. Nach UiPaths Autopilot-Dokumentation für Studio Web können Modellzugriff, Autonomiestufe und verfügbare Werkzeuge zentral gesteuert werden. Teams können damit festlegen, welche agentischen Möglichkeiten in ihrer Umgebung bereitstehen, ohne jede einzelne Anweisung im Projekt separat zu regeln.
Der passende Einsatzbereich sind API-basierte Geschäftsaufgaben, bei denen Zweck und Datenlogik klar beschrieben werden können: Datensätze abrufen und filtern, Informationen zwischen verbundenen Systemen weiterreichen, Antworten transformieren oder bestehende API-Workflows gezielt erweitern. Weniger geeignet ist eine vage Aufforderung ohne benannte Systeme, Datenfelder oder erwartetes Verhalten, weil der Agent dann wesentliche Entscheidungen interpretieren müsste.
Eine Ausführung hat einen festen Verbrauchswert
UiPath rechnet API-Workflows pro Ausführung ab. Unter Unified Pricing fallen laut Lizenzdokumentation 0,05 Platform Units je Ausführung an. Im Flex-Modell entspricht eine Ausführung 15 API Calls.
In dieser Pauschale sind Connector-Aktivitäten, HTTP Requests, Integration-Service-Trigger sowie Skript- und Kontrollflussaktivitäten innerhalb des Workflows enthalten. Sie werden nicht zusätzlich einzeln gemessen. Für die Kalkulation zählt damit die Zahl der Workflow-Ausführungen, nicht die Zahl der enthaltenen Aktivitäten. Die Verbrauchsanzeige kann der Dokumentation zufolge um ungefähr eine Stunde verzögert sein.
Gerade bei häufig ausgeführten Integrationen ist diese Einheit die relevante Planungsgröße. Ein umfangreicher Workflow mit mehreren enthaltenen Aktivitäten erzeugt laut der beschriebenen Messlogik nicht automatisch mehrere separat berechnete Verbräuche innerhalb derselben Ausführung. Unterschiedliche Preismodelle verwenden jedoch unterschiedliche Einheiten: Platform Units unter Unified Pricing und API Calls unter Flex.
Wo Autopilot den größten Unterschied macht
Der Nutzen entsteht dort, wo eine fachlich präzise Beschreibung bislang in viele manuelle Konfigurationsschritte übersetzt werden musste. Autopilot kann diese Übersetzung innerhalb von Studio Web übernehmen, bestehende Workflows verändern und die nachfolgenden Aktionen von der Validierung bis zur Veröffentlichung unterstützen. HTTP-Aufrufe, Connectoren, Kontrollfluss und JavaScript bleiben dabei als konkrete Bestandteile sichtbar und bearbeitbar.
Die Vorschau macht API-Automatisierung dadurch zugänglicher, ohne die technische Ebene zu verstecken. Entwickler können schneller zu einer ersten ausführbaren Fassung gelangen; Automation-Teams können Anforderungen in natürlicher Sprache enger mit den tatsächlichen Workflow-Bausteinen verbinden. Die verlässlichste Nutzung kombiniert eine genaue Beschreibung mit einer gezielten Kontrolle der generierten Verbindungen, Datenstrukturen, Bedingungen und Fehlerpfade.
UiPath Autopilot ist somit weder nur ein Chatfenster noch eine vollständig autonome Veröffentlichungsschleife. Es ist ein Coding-Agent innerhalb von Studio Web, der aus Anforderungen konkrete API-Workflow-Strukturen erzeugt und sie über mehrere Entwicklungsaktionen hinweg begleiten kann. Der Status als öffentliche Vorschau setzt den Rahmen: Die Fähigkeiten sind bereits praktisch nutzbar, die Verantwortung für die freigegebene Logik bleibt bei den Menschen, die den Workflow ausführen oder veröffentlichen.