Der Agent-Zugriff ist keine Workflow-Vertrauensstellung

Das Muster, das sich branchenweit abzeichnet

Das Wichtigste auf einen Blick: Mehrere Plattformen bieten mittlerweile Agenten an, die in der Lage sind, Probleme zu untersuchen, Lösungen vorzuschlagen und diese umzusetzen – und das mit echten Berechtigungsmodellen und Sandboxing im Hintergrund. Das ist eine echte technische Meisterleistung, nicht nur eine Demo.

Wenn man sich die jüngsten Ankündigungen zu Plattformen und Tools ansieht, wiederholt sich ein Thema: ein Agent, der Protokolle und Metriken auswerten, ein Problem bis zu seiner Ursache zurückverfolgen, eine Lösung vorschlagen oder umsetzen und in der Produktivumgebung Maßnahmen ergreifen kann – und zwar mit einem Plan, den du zuvor genehmigst.

Das betrifft nicht nur Plattformanbieter. Frag irgendeinen Entwickler, welchen Programmier-Agenten er nutzt, und du wirst jedes Mal eine andere Antwort bekommen. Patrick Dawkins, Principal Engineer bei Upsun, bezifferte die Zahl kürzlich auf etwa 22 wichtige Tools, die derzeit im Umlauf sind – und diese Zahl ändert sich von Woche zu Woche. 

Einige davon sind wirklich gut konzipiert. Agenten laufen unter ihrer eigenen Identität, fordern bereichsbezogene Berechtigungen für einen bestimmten Plan an, anstatt dauerhaften Zugriff zu haben, und testen das generierte Programm in einer isolierten Sandbox anhand echter Builds und Tests, bevor irgendetwas einen Menschen erreicht.

Das ist eine ernstzunehmende Antwort auf eine echte Frage: Wie lässt man einen Agenten in der Nähe der Produktivumgebung arbeiten, ohne das Unternehmen darauf zu setzen, dass er niemals Fehler macht? Die Antwort lautet zunehmend: eine gute Infrastruktur hinter dem Agenten – und nicht blindes Vertrauen in das Modell.

Wo diese Antwort an ihre Grenzen stößt

Das Wichtigste auf einen Blick: Diese Agenten sind dafür ausgelegt, die eigene Infrastruktur einer Plattform zu betreiben – für die Person, die sich bereits im Dashboard dieser Plattform auskennt. Die meiste echte Arbeit bleibt nicht innerhalb einer einzigen Plattform, und die meisten Entscheidungen auf diesem Weg werden nicht von einem Entwickler getroffen.

Hier ist der Teil, der nicht laut ausgesprochen wird: Die meisten dieser Agenten arbeiten innerhalb der Plattform, die sie entwickelt hat – auf deren eigenen Deployments, Logs und im Dashboard. Sie sind für diejenigen gedacht, die sich dort bereits wohlfühlen, was heute meist den Entwickler bedeutet.

Aber ein Feature wird selten über ein einziges Tool bereitgestellt. Ein Problem entsteht in einem Tracker, den dein Team bereits nutzt. Die Arbeit findet in einem Repo statt, das irgendwo gehostet wird. Eine Design-Prüfung erfolgt in einem Design-Tool. Jemand aus der Sicherheitsabteilung muss seine Zustimmung geben, bevor es die Kunden erreicht. Ein Manager möchte Transparenz, ohne ein Terminal öffnen zu müssen. Nichts davon befindet sich im Dashboard einer einzelnen Plattform, und nichts davon wird gelöst, indem man den Agenten innerhalb dieser einen Plattform intelligenter macht.

Die Frage ist nicht, ob ein Agent sicher agieren kann, sobald er sich bereits in deiner Plattform deiner Wahl befindet. Es geht darum, ob der gesamte Ablauf – über alle beteiligten Tools hinweg und unter Einbeziehung aller Personen, die einen Schritt einsehen oder genehmigen müssen – etwas ist, das du und dein Team tatsächlich gemeinsam abwickeln und dem ihr vertrauen könnt.

Das haben wir selbst erlebt

Das Wichtigste auf einen Blick: Ein Agent für einen einzigen Zweck und ein einziges Tool ist wirklich nützlich. Er ist aber auch ein Vorgeschmack darauf, wo genau dieser Ansatz an seine Grenzen stößt und nicht mehr das Gesamtbild abdeckt.

Bevor es Upsun Dispatch gab, hat einer unserer eigenen Entwickler einen internen Agenten so angepasst, dass er Pull-Anfragen in GitLab überprüft. Er erfüllt seine Aufgabe gut: Er liest eine Merge-Anfrage und markiert, was Aufmerksamkeit erfordert. Er hat außerdem eine zweite Version entwickelt, die Anfragen stapelweise scannt und sortiert, welche fehlerfrei und bereit zum Zusammenführen sind, welche noch geprüft werden und welche Konflikte aufweisen.

Beides sind nützliche Tools. Keines davon ist ein Workflow. Sie sind Teil eines bestimmten Abschnitts des Prozesses, auf einer Plattform, und dort hören sie auch schon auf. Der Rest dessen, was tatsächlich in der Produktivumgebung geändert wird – das Issue, mit dem alles begann, die Diskussion rund um das Design, die Person aus der Sicherheitsabteilung, die ihre Zustimmung geben muss –, findet immer noch woanders statt und wird von nichts Bestimmtem nachverfolgt. Die Entwicklung des Review-Agents hat diese Koordinationsarbeit nicht beseitigt, sie hat lediglich einen Teil davon beschleunigt. 

Was sich ändert, wenn der Workflow die Grundlage ist, nicht der Agent

Kernaussage: Wenn man den Workflow – und nicht den Agenten oder die Plattform – als die entscheidende Einheit betrachtet, ändert sich, was entwickelt werden muss: die Tools, in denen er läuft, wer daran teilnehmen darf und wie Kosten und Compliance nachverfolgt werden.

Upsun Dispatch geht von einer anderen Prämisse aus: Der Workflow ist das Grundelement. 

Jedes Team hat bereits seine eigenen Rituale und Abläufe rund um die Bereitstellung, den Hin- und Her-Prozess bei der Überprüfung eines Pull-Requests und die Gespräche, die stattfinden, bevor überhaupt programmiert wird. Daraus ergeben sich einige Konsequenzen, wenn man dies als das betrachtet, worum herum es sich zu gestalten lohnt – und nicht die Aktionen eines einzelnen Agenten:

• Es läuft in den Tools, die dein Team bereits hat, nicht nur in einem eigenen Dashboard. GitHub, GitLab, Linear, Jira und die Rituale, denen dein Team bereits folgt, bilden die Basis – es ist kein separates System, das zusätzlich eingeführt werden muss.
• Jeder im Team kann an einem Gate agieren, nicht nur der Entwickler, der den Lauf ausgelöst hat. Die Freigabe ist nicht an denjenigen gebunden, der gerade an seinem Schreibtisch sitzt.
• Die Kosten sind auf Teamebene sichtbar, nicht auf individueller Ebene. Agenten geben Token aus, und auf dem Laptop einer einzelnen Person kann niemand sehen, wohin das Geld fließt. Upsun Dispatch zeigt die Kosten pro Lauf, pro Workflow und pro Team an.
• Es setzt nicht auf ein einziges Modell. Speichere einen Anthropic- oder OpenAI-Schlüssel, wähle einen Standard aus und tausche ihn bei Bedarf aus, damit der Workflow das Team nicht an das Modell bindet, das bei der Einrichtung zufällig am besten war.
• Jeder Durchlauf wird als Compliance-Daten protokolliert: das Problem, der Kontext des Agenten, der Plan, wer ihn genehmigt hat und was er gekostet hat.

Nichts davon ersetzt das menschliche Urteilsvermögen darüber, wie viel Spielraum ein Agenten erhält. Es verändert lediglich, wo dieses Urteilsvermögen zum Tragen kommt.

Wo Menschen weiterhin entscheiden

Das Wichtigste auf einen Blick: Workflow-Orchestrierung bedeutet nicht, dass Agenten unbeaufsichtigt laufen. Upsun Dispatch verfügt bereits heute über einen integrierten Checkpoint, und es werden weitere hinzukommen, je mehr Teile des Workflows Dispatch selbst ausführen kann.

Dass der Workflow die entscheidende Einheit ist, bedeutet nicht, dass er sich von selbst abläuft. Derzeit bedeutet das einen integrierten Kontrollpunkt: Dispatch pausiert eine von Jira ausgelöste Implementierung nach der Planung und wartet auf eine Entscheidung, bevor programmiert wird. Jeder, der das Issue kommentieren kann, kann es genehmigen, mit Feedback zurücksenden oder dort stoppen – genau wie beim Plan-Genehmigungsschritt eines plattform-nativen Agenten, nur dass dies hier vor dem Programmieren geschieht und nicht vor dem Merge.

Der Unterschied liegt darin, wohin dieser Kontrollpunkt zielt – nicht nur darin, wo er heute steht. Ein in das Dashboard einer Plattform integrierter Kontrollpunkt deckt immer nur die Teile eines Workflows ab, die innerhalb dieser Plattform ablaufen. Da Upsun Dispatch zunehmend einen ganzen Workflow abdeckt – der sich über einen Tracker, einen Repo-Host und einen Review-Schritt erstreckt –, ist es das Ziel, dass an jedem dieser Punkte menschliche Kontrollpunkte stattfinden, nicht nur an der einen Stelle, an der eine einzelne Plattform zufällig eine Hürde eingebaut hat. Einem Agenten mehr Spielraum zu geben und eine Person auf dem Laufenden zu halten, steht hier nicht im Widerspruch zueinander. Die Hürde ist es, die diesen Spielraum sicher macht.

Workflows waren früher kaum mehr als ein Nachverfolgungsmechanismus, eine Aufzeichnung der Arbeit, die jemand anderswo erledigte. Was sich geändert hat, ist nicht, dass der Workflow plötzlich wichtiger geworden ist. Es ist vielmehr so, dass der Workflow nun einen Teil der Arbeit selbst übernehmen kann – was bedeutet, dass die Frage nicht mehr lautet, was nachverfolgt werden muss, sondern wo ein Mensch tatsächlich gebraucht wird und wo nicht.

Nichts davon steht im Widerspruch dazu, dass ein plattforminterner Agent diese Plattform gut bedienen kann. Es beantwortet eine andere Frage: nicht „Kann dieser Agent hier sicher agieren?“, sondern „Kann dieser Workflow, der sich über die Tools und Personen erstreckt, mit denen er tatsächlich zu tun hat, als Ganzes vertrauenswürdig sein und geprüft werden?“

Warum diese Unterscheidung jetzt wichtig ist, nicht erst später

Das Wichtigste auf einen Blick: Die aktuelle Welle an Agent-Features zielt auf Entwickler ab, die sich bereits innerhalb einer Plattform befinden. Die Workflows, mit denen Software tatsächlich ausgeliefert wird, umfassen jedoch mehr Tools und mehr Menschen als das – und genau an dieser Lücke bleiben Teams hängen, sobald sie über eine einzelne, klar abgegrenzte Aufgabe hinausgehen.

Die meisten Teams stoßen nicht gleich am ersten Tag auf diese Lücke. Eine einzelne, klar abgegrenzte Aufgabe – etwa ein Agent, der einen Build repariert oder eine Warnmeldung innerhalb einer Plattform, in der er bereits arbeitet, einstuft – funktioniert mit der aktuellen Welle plattformnativer Agenten einwandfrei. 

Die Lücke tritt zutage, sobald sich eure Arbeit über mehr als ein Tool erstreckt oder sobald jemand, der kein Entwickler ist, einen Schritt einsehen oder genehmigen muss. An dieser Stelle reicht „der Agent kann sicher handeln“ nicht mehr als vollständige Antwort aus, denn das Problem lag nicht wirklich beim Agenten. Es ging um den Workflow, von dem er nur ein kleiner Teil ist.

Wenn dein Team bereits Agent-Workflows über mehrere Tools hinweg ausführt und die Koordinationsprobleme spürt, kannst du Upsun Dispatch kostenlos unter upsun.com/dispatch ausprobieren.

Häufig gestellte Fragen (FAQ)

Reicht ein gut gesicherter, plattformnativer Agent nicht für KI-gestützte Softwarebereitstellung aus?
Für Aufgaben, die innerhalb einer Plattform bleiben, oft schon. Die Lücke entsteht, sobald eine Aufgabe mehrere Tools umfasst, wie zum Beispiel einen Issue-Tracker, einen Repo-Host und einen Review-Schritt, oder sobald jemand außerhalb der Technik einen Teil des Prozesses einsehen oder genehmigen muss.

Was bedeutet „Der Workflow ist die Grundkomponente, nicht der Agent“ bei Upsun Dispatch?
Es bedeutet, dass das, was entworfen und als vertrauenswürdig angesehen wird, die Abfolge von Schritten und Übergaben ist, die ein Team bereits befolgt – über die Tools hinweg, die es bereits nutzt –, und nicht die Aktionen eines einzelnen Agenten innerhalb der eigenen Infrastruktur einer Plattform.

Ersetzt Upsun Dispatch plattformnative Features wie die Workspace-Agenten von GitHub Copilot?
Nein. Ein Plattformagent, der die eigene Plattform gut bedienen kann, ist genau dafür nach wie vor nützlich. Die Workflow-Orchestrierung ist eine Ebene darüber – für jene Teile der Bereitstellung, die von vornherein nie im Dashboard einer einzelnen Plattform untergebracht werden sollten.

Welche Teams profitieren am meisten von einer KI-Orchestrierung auf Workflow-Ebene anstelle eines Agenten auf einer einzigen Plattform?
Teams, bei denen die Bereitstellung bereits mehrere Tools umfasst, denn genau dort reicht ein plattformgebundener Agent – so leistungsfähig er auch sein mag – nicht mehr aus, um den gesamten Weg von der Idee bis zur Produktion abzudecken.