Agent-First Design

Mobile First. Als Luke Wroblewski diese Idee 2009 formulierte, war das iPhone zwei Jahre alt, das iPad noch nicht einmal auf dem Markt, und Webseiten waren starre 960-Pixel-Layouts für Desktop-Monitore. Smartphones lieferten einen einstelligen Prozentsatz des Traffics. Und da fordert einer ernsthaft: Entwerft zuerst für das Handy. Der Desktop, das Gerät, auf dem praktisch alle Besucher unterwegs sind, kommt danach. Das war keine Optimierung, das war eine Provokation. Der Aufschrei war entsprechend.

Durchgesetzt hat sich die Idee erst Jahre später, so ab 2012, ich erinnere mich noch an die Diskussionen in Projekten von damals. Und in der Rückschau gibt es nichts mehr zu diskutieren: Es ist genau so gekommen. Heute kommt je nach Messung mehr als die Hälfte des Web-Traffics von Smartphones, viele Produkte existieren überhaupt nur noch als App. Der eigentliche Trick von Mobile First war nie das responsive CSS. Es war die umgedrehte Reihenfolge: zuerst für die härteste Einschränkung entwerfen, dann erweitern. Wer andersrum arbeitete, hat sich jahrelang an Umbauten abgearbeitet.

Ich glaube, wir stehen wieder an genau so einem Punkt. Wieder liegt eine Idee auf dem Tisch, die im ersten Moment verrückt klingt: Wenn Agenten den Großteil der repetitiven Arbeit übernehmen können, dann brauchen Menschen eine völlig neue Art von User Interface, mit anderen Zielen, als UX sie bisher je hatte. Ich nenne das Agent-First Design: Unternehmenssoftware so entwerfen, dass KI-Agenten die primären Erlediger der Arbeit sind, und Menschen diejenigen, die prüfen und verantworten, was die Agenten tun. Den Begriff schlage ich hier vor, das Feld dahinter ist neu, und dieser Artikel ist ein erster Versuch, es zu vermessen. Das alles ist trotzdem keine Prognose für irgendwann in fünf Jahren. Wer gerade entwirft, wie Menschen in seiner Software arbeiten sollen, trifft diese Entscheidung jetzt. Mit oder ohne Absicht.

Agenten brauchen keine Oberflächen

Die eine Hälfte dieses Gedankens existiert bereits. Unter dem Begriff Agent Experience (AX) entsteht gerade ein ganzer Diskurs darüber, wie man Software für Agenten zugänglich macht: saubere APIs, maschinenlesbare Dokumentation, MCP-Server, klar geschnittene Berechtigungen, verständliche Fehlerzustände. Die Kernerkenntnis ist simpel. Ein Agent braucht kein GUI. Man kann ihn zwar per Computer Use durch Web-Masken klicken lassen, das funktioniert sogar. Aber es ist langsam und fehleranfällig, ein Bagger, den man mit Essstäbchen bedient. Ein gut dokumentiertes REST-Interface erledigt dieselbe Aufgabe in einem Bruchteil der Zeit, und jeder Aufruf lässt sich validieren und nachvollziehen.

Über diese Hälfte muss man nicht mehr lange streiten. Wer heute Systeme baut, sollte die Agenten-Schnittstelle als vollwertiges Interface behandeln.

Spannender ist die Frage, die in diesem Diskurs kaum jemand stellt.

Brauchen wir das User Interface überhaupt noch?

Seit es Software gibt, bauen wir User Interfaces mit einem einzigen Zweck: Menschen sollen mit Computerhilfe Arbeit verrichten. Masken, Formulare, Buttons, Workflows. Die ganze UX-Disziplin optimiert darauf, dass ein Mensch seine Aufgabe möglichst schnell und fehlerfrei erledigt.

Wenn aber die Aufgabe selbst zum Agenten wandert, fällt dieser Zweck weg. Und dann gilt: The best part is no part. Jedes User Interface, das gerade irgendwo geplant wird, gehört auf den Prüfstand. Nicht “wie machen wir die Maske besser”, sondern “wozu gibt es diese Maske noch”.

Ein Gedankenexperiment, das jeder kennt: die Steuererklärung. ELSTER ist im Kern ein digitalisiertes Formular, ein klassisches Arbeitsinterface. Ich übertrage Zahlen aus Belegen in Felder. Aber niemand will Formularfelder ausfüllen, das war nie das Ziel. Das Ziel ist eine korrekte Steuererklärung.

Was dazwischen liegt, kennt jeder, der schon mal eine gemacht hat. Für mein Arbeitszimmer rechne ich jedes Jahr dieselbe Übung: Strom, Wasser, Heizung, Grundsteuer, Schornsteinfeger und Gebäudeversicherung raussuchen, alles addieren, durch die Wohnfläche des Hauses teilen, mal die Quadratmeter des Büros. Die Rechnung ist seit Jahren identisch, nur die Zahlen ändern sich. Für die Anlage Vorsorgeaufwand suche ich Beitragsbescheinigungen von Versicherungen zusammen, die in irgendwelchen Mail-Anhängen vom Januar stecken. Lauter Fleißarbeit, bei der ich nichts entscheide.

Genau solche Strecken sind Kandidaten für agentische Komponenten. Und zwar einzeln, das ist mir an dem Beispiel wichtig. Die Steuererklärung ist ohnehin kein Monolith, sie besteht aus Anlagen: N für den Arbeitslohn, Vorsorgeaufwand für die Versicherungen, Kind, KAP und so weiter. Niemand muss das als großen Wurf automatisieren. Eine Komponente fischt die Beitragsbescheinigungen aus dem Postfach. Eine zweite übernimmt die Arbeitszimmer-Rechnung, sobald die Nebenkostenabrechnung da ist. Jede ist für sich nützlich, jede für sich prüfbar, und zusammen ergeben sie irgendwann die Erklärung.

Was dann für mich übrig bleibt, ist eine Prüfansicht: Hier ist deine Erklärung. An drei Stellen war ich unsicher, die gehen wir jetzt einzeln durch. Erst danach zeigt sie mir die erwartete Erstattung und den Absenden-Knopf. Mit Absicht in dieser Reihenfolge, dazu später mehr.

Das Formular verschwindet. Was an seine Stelle tritt, ist eine völlig andere Art von Interface.

Vom Arbeitsinterface zum Prüfinterface

Jetzt die andere Seite desselben Beispiels: das Finanzamt. Dort sitzen Sachbearbeiter, die solche Erklärungen prüfen, tausende pro Jahr, heute noch Maske für Maske. In einer agent-first gebauten Welt hat ein Agent die Erklärung bereits durchgearbeitet. Posten gegen Belege abgeglichen, Vorjahresvergleich gemacht. Was auffällig ist, wird markiert. Der Mensch arbeitet die Erklärung nicht mehr ab. Er beurteilt, was der Agent daraus gemacht hat.

Das Interface, das er dafür braucht, hilft ihm nicht beim Erfassen. Es zeigt ihm, was der Agent getan hat, auf welcher Datengrundlage, mit welcher Begründung, und wo sich sein Blick lohnt. Für diese Art von Interface gibt es Vorarbeiten, aus der Medizin, aus Moderations-Queues, aus Audit-Systemen. Aber als Standardrepertoire für Unternehmenssoftware ist davon nichts übersetzt: keine etablierten Patterns, keine Ausbildung, nicht mal ein gefestigter Name. Ich nenne diese Interfaces hier Prüfinterfaces, bis jemand einen besseren Namen findet. Wobei der Name nur die Hälfte der Aufgabe trifft: Prüfen ist der eine Teil. Der andere ist, die Agenten gemeinsam weiterzuentwickeln, dazu gleich mehr. Ich halte diese Interfaces für eine der interessantesten Design-Aufgaben der nächsten Jahre.

An dieser Stelle lohnt ein zweiter Blick auf die Analogie. Mobile First hieß: für die härteste Einschränkung zuerst entwerfen, den kleinen Bildschirm. Die härteste Einschränkung ist diesmal nicht der Agent. Der nimmt jede API und arbeitet rund um die Uhr. Knapp ist etwas anderes: die Aufmerksamkeit des Menschen, der prüfen soll. Sie ist die teuerste und am schnellsten erschöpfte Ressource im ganzen System. Für sie wird das neue Interface entworfen. Drei Prinzipien zeichnen sich für mich ab, und alle drei bewirtschaften diese eine knappe Ressource.

Prüftiefe staffeln

Nicht jede Agenten-Entscheidung verdient denselben menschlichen Blick. Eine Pendlerpauschale, die exakt den Vorjahren entspricht, braucht keinen. Eine erstmalige Absetzung über 25.000 Euro braucht einen gründlichen. Dazwischen liegen Stichproben. Die Finanzverwaltung arbeitet im Kern heute schon so: Risikomanagementsysteme (§ 88 Abs. 5 AO) veranlagen unauffällige Erklärungen vollautomatisch, ohne dass ein Mensch sie je sieht. Neu ist, dass Agenten diese Staffelung auf das ausweiten können, wofür bisher Menschen nötig waren, auf unstrukturierte Belege, Freitexte, Plausibilität. Das Kriterium bleibt dabei das Schadenspotenzial der einzelnen Entscheidung. Ob KI im System steckt, spielt dafür keine Rolle. Wie man diese Staffelung architektonisch denkt, habe ich in Die Taube sieht besser ausführlich beschrieben. Im Prüfinterface wird sie sichtbar: Bagatellen tauchen gar nicht erst auf, die auffällige Erklärung bekommt einen eigenen, tiefen Prüfbildschirm.

Entscheidungen forcieren, Lernsignale sammeln

Quer durch die Industrie bekommt gerade jede Software nachträglich einen KI-Knopf spendiert. Mal an sinnvoller Stelle, mal eher als Feigenblatt. Für die Anwender ist das nett. Nur lernt dabei niemand etwas. Ein Klick auf “Vorschlag übernehmen” sagt nichts. Dahinter kann gründliche Prüfung stecken oder bloßes Wegklicken.

Agent-First Design dreht das um. Die Analyse läuft immer, ungefragt. Und das Interface verlangt eine echte Entscheidung: den Wert bestätigen, oder einen eigenen eintragen und in einem Halbsatz begründen. Im Finanzamt hieße das: Der Agent hat die Werbungskosten anerkannt, der Prüfer setzt sie niedriger an und schreibt dazu, warum. Über tausende Erklärungen entsteht aus solchen Abweichungen ein Bild. Wo liegt der Agent daneben, in welche Richtung, bei welcher Art von Posten? Daraus werden bessere Prompts und bessere Prüfregeln. Schritt für Schritt auch mehr Autonomie, auf den Pfaden, die sie vertragen.

Das Prüfinterface ist also mehr als ein Kontrollwerkzeug. Es ist die Datenquelle, aus der die Entwickler und der Fachbereich lernen. Jede gesammelte Entscheidung kann zum Testfall für Evals werden, also für die Messläufe, die zeigen, ob ein geänderter Prompt besser oder schlechter geworden ist. Und die Begründungen verraten, an welchen Stellen sich das Nachschärfen überhaupt lohnt. Welche Qualitätsfragen dabei zu beantworten sind, habe ich in AI Systems Architecture: Die Qualitätsfragen sortiert.

Wir bauen heute die Interfaces, die das Wissen für die Automatisierung von morgen einsammeln. Und das Schöne daran: Genau dieser Baustein lässt sich auch in bestehende Software nachrüsten. Man braucht kein neues System, um anzufangen zu lernen. Ein forcierter Vorschlag mit Begründungsfeld in der alten Maske reicht für den Anfang.

Reibung ist ein Feature

Das dritte Prinzip widerspricht allem, was man in UX gelernt hat. Man kennt die Leute an der Flughafen-Sicherheitskontrolle, die stundenlang Gepäckbilder anstarren. Monate vergehen, und da ist nie eine Bombe. Trotzdem sollen sie beim zehntausendsten Koffer noch genau hinschauen. Menschen können das nicht. Wir ermüden, wir winken durch.

Gemessen ist das längst. Warnhinweise in Krankenhaus-Software klicken Ärzte in rund 90 Prozent der Fälle weg, auch weil zu viele unwichtige Warnungen die wichtigen entwerten. Warum der Mensch in solchen Schleifen oft der schlechteste verfügbare Prüfer ist und wann er trotzdem unverzichtbar bleibt, habe ich in Die Taube sieht besser auseinandergenommen.

Die klassische UX-Antwort, Klicks minimieren und Wege verkürzen, macht es schlimmer. Sie optimiert das Durchwinken. Ein Prüfinterface braucht das Gegenteil: bewusst eingebaute Reibung an den Stellen, wo es zählt. Reibung ist dabei kein Selbstzweck. Bei Bagatellen bleibt der Weg glatt, die Reibung gehört dorthin, wo eine Entscheidung teuer oder unumkehrbar ist.

Erst das eigene Urteil abfragen, dann den KI-Vorschlag zeigen. Ab und zu einen präparierten Fehlerfall einstreuen und messen, ob er gefunden wird, das Äquivalent zum Testbild im Gepäckscanner. Eine Begründung verlangen statt eines Ja-Buttons. Und die erwartete Erstattung erst dann zeigen, wenn die unsicheren Posten bestätigt sind, deshalb die Reihenfolge in der Prüfansicht von vorhin. Mein Kollege Ruben Vitt hat dazu einen lesenswerten Artikel geschrieben: Approval ist kein UX-Bug. Genau so ist es gemeint. Das ist UX mit einem anderen Optimierungsziel: Urteilsqualität statt Durchsatz.

Die Einwände

Drei höre ich regelmäßig. Erstens: “Agenten können doch klicken, wozu neue Schnittstellen?” Stimmt, Computer Use existiert, und für Legacy-Systeme ohne API ist es ein legitimes Übergangswerkzeug. Als Zielbild ist es absurd, siehe Bagger und Essstäbchen.

Zweitens: “Das ist doch alles Hype.” Teilweise ja. Gartner hat prognostiziert, dass über 40 Prozent der Agentic-AI-Projekte bis Ende 2027 wieder eingestellt werden, und nennt als Gründe Kosten, unklaren Business Value und fehlende Risikokontrollen. Auffällig an dieser Liste: Die Modelle stehen nicht drauf. Diese Projekte scheitern an der Naht zwischen Agent und Mensch, also genau an dem, was hier Design braucht. Für mich ist das kein Gegenargument. Es ist die Begründung.

Drittens, aus der Gegenrichtung: Wenn der Agent vor jeder Aktion einen Menschen fragen muss, ist die versprochene Autonomie nur eine Attrappe. Für pauschale Freigabe-Pflichten stimmt das sogar. Die Antwort darauf heißt Staffelung. Der Agent erledigt die Bagatelle autonom, und die große Entscheidung bekommt einen Menschen mit einem Interface, das echtes Urteilen möglich macht.

Die Arbeit verschwindet nicht, sie verschiebt sich

Bleibt die Frage, was aus den Menschen wird, die diese Arbeit heute machen. Ich glaube nicht, dass die Arbeit verschwindet. Sie verschiebt sich. Die repetitive Erfassung geht weg, das Fachwissen wird wichtiger als vorher, nur an anderer Stelle. Früher haben Softwareentwickler Software für Fachexperten gebaut. Jetzt bauen Softwareentwickler mit Fachexperten zusammen Agenten, die selbstständig arbeiten können. Wer zwanzig Jahre lang Steuererklärungen geprüft hat, erkennt eine frisierte Rechnung, bevor er sie ganz gelesen hat. Genau dieses Wissen gehört in die Prompts, die Prüfregeln und die Evals, und dorthin kommt es nur, wenn der Fachbereich von Anfang an mitentwickelt. Bei Software-Entwicklern passiert gerade dasselbe, ich habe darüber geschrieben: Wir schreiben weniger Zeilen selbst und tragen mehr Verantwortung pro Zeile.

Der Agent-First-Test

Woran erkennt man am Ende, ob eine Fachanwendung agent-first gedacht ist? Mein Vorschlag für einen Test: Für jeden zentralen Vorgang müssen fünf Pfade beschrieben sein.

• Ausführung: Was erledigt der Agent selbst?
• Prüfung: Was bekommt der Mensch zu sehen, und warum genau das?
• Eskalation: Ab welcher Tragweite muss ein Mensch entscheiden?
• Audit: Wie lässt sich später nachvollziehen, was passiert ist und warum?
• Lernen: Welche menschlichen Korrekturen fließen zurück in Prompts, Prüfregeln und Evals?

Das ist die Interface-Seite dessen, was ich in AI Systems Architecture auf der Systemebene beschrieben habe. Wer diese fünf Fragen für seine Anwendung nicht beantworten kann, hat noch human-first gedacht.

2012 konnte sich kaum jemand vorstellen, dass der Desktop zur Nebensache wird. Die Teams, die es trotzdem ernst genommen haben, mussten später nicht umbauen. Genau an diesem Punkt stehen wir wieder. Wer heute eine Fachanwendung entwirft, sollte sich zwei Fragen stellen: Wer erledigt diese Arbeit in fünf Jahren? Und wenn die Antwort “ein Agent” lautet, was zeigt mein Interface dann dem Menschen?