Hinweis: Dieser Inhalt wurde automatisch übersetzt. Feedback senden

Der Headless User

13 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

Wenn der primäre Nutzer von Enterprise-Software ein KI-Agent wird, ist Jensen und Mecklings Principal-Agent-Framework von 1976 keine Metapher mehr. Die Verifier-Klasse, die auf der anderen Seite entsteht, ist die nächste Preisanomalie des Arbeitsmarkts.

Vom Menschen als User zum Agenten als User: die Neubestimmung, die Software und Arbeit neu ordnet

Mitte April 2026 kündigte Salesforce auf der TDX Headless 360 an: einen Umbau der Plattform rund um APIs, Model Context Protocol Tools und Command-Line-Interfaces (Salesforce; VentureBeat). Das war kein UX-Refresh. Es war die Anerkennung einer Tatsache: Der primäre Nutzer von Enterprise-Software ist kein Mensch mehr.

Die Wortwahl ist entscheidend. Ein Jahrzehnt Design-Orthodoxie hat "User" mit "Person" gleichgesetzt. Personas hatten Namen, Fotos, Ziele; Design-Sprints begannen mit Empathy Maps; Wireframes stellten sich vor, wie Augen über einen Screen wandern. Headless 360 verfeinert diese Orthodoxie nicht. Es zerlegt sie. Der Browser wird zur Legacy-Oberfläche. Die Spreadsheet-Ansicht wird zu einer von vielen Outputs, nicht mehr zum Output. Der Screen wird optional.

Die Fachpresse las den Wandel genauso klar wie Salesforce selbst. VentureBeat beschrieb den Launch als Infrastruktur für KI-Agenten, während PPC.land ihn als Schritt rahmte, der den Browser als verpflichtendes Interface abschafft (VentureBeat; PPC.land). Salesforce erklärte, dass der Launch mehr als sechzig MCP-Tools und mehr als dreißig Coding-Skills umfasste, zusätzlich zu einem breiteren Set agent-facing Oberflächen (Salesforce). Das ist die Größenordnung eines Plattform-Pivots, nicht eines Produkt-Releases.

Die Verschiebung ist auch anderswo in der Tooling-Layer sichtbar. The New Stack stellte diesen Monat fest, dass Cursor, Claude Code und OpenAIs Codex "zu einem AI coding stack verschmelzen, den niemand geplant hatte" (The New Stack). Angrenzende Plattformen bauen ebenfalls eigene Agent-Layer, wie Atlassians Rovo-Dokumentation ziemlich deutlich macht (Atlassian). All diese Produkte setzen einen Operator voraus, der generierte Artefakte lesen, editieren und ihnen vertrauen kann, ohne sie Zeile für Zeile zu prüfen. Das Artefakt ist nicht länger das Dashboard. Das Artefakt ist das Verhalten.

Was hier passiert, ist kein Fortschritt in User Experience. Es ist eine Neubestimmung davon, wer der User ist. Drei Jahrzehnte lang behandelte Enterprise-Software den Menschen als Principal: die Entität, deren Aufmerksamkeit, Zustimmung und Fehler den Feedback-Loop des Systems bildeten. Der Mensch klickte; die Software reagierte. Dieser Loop war eng, weil die Latenz zwischen Absicht und Eingabe gering war. Softwarefirmen optimierten jeden Teil davon: schnellere Formulare, weniger Klicks, hübschere Dashboards.

Dieser Loop bricht auf. Nicht, weil der Mensch eliminiert würde. Der Mensch bleibt die Quelle der Absicht, der Kontoinhaber, derjenige, der die Rechnung bezahlt. Aber der Mensch ist nicht länger die Entität an der Konsole. Etwas anderes ist es. Es tippt. Es macht API-Calls. Es bedient die Software.

Dieses Etwas einen "User" zu nennen, überdehnt das Wort. Präziser ist es ein Agent, der im Auftrag eines Users handelt. Und genau in der Distanz zwischen beiden, zwischen Principal und Agent, öffnet sich das neue Terrain.

Die verschwindende Schnittstelle

Diese Entwicklung hatte einen langen Vorlauf. In Lenny's Newsletter beschrieb Marc Andreessen natürliche Sprache als die nächste Abstraktionsschicht über höheren Programmiersprachen, nachdem Maschinencode und Assembly C und Python Platz gemacht hatten (Lenny's Newsletter). Andrej Karpathy, ehemals Tesla und OpenAI, fasste den jüngsten Schritt in seine Software-1.0-, 2.0- und 3.0-Taxonomie, in der englische Prompts zu einer Art werden, LLMs zu programmieren (Y Combinator podcast). Jede Schicht machte Computer für eine breitere Gruppe zugänglich und machte eine schmalere Gruppe obsolet.

Guillermo Rauch, Gründer von Vercel, formulierte die Konsequenz im selben Podcast sehr klar: Viele Programmierjobs, die früher hochspezialisiert waren, werden zu Übersetzungsarbeit, vor allem von Absicht oder Design hin zur Implementierung (Lenny's Newsletter). Übersetzung, von Design zu Code, von Policy zu Konfiguration, von Spezifikation zu Schema, war zwei Generationen lang die Mittelschicht der white-collar Softwarearbeit. Rauchs Punkt ist nicht, dass Programmierung verschwindet. Sondern dass die Übersetzer verschwinden.

Headless 360 ist die Enterprise-Version desselben Schritts, und es bleibt nicht allein. Im gleichen Zeitfenster brachten Oracle, SAP, Workday, und ServiceNow jeweils parallele Agent-Plattform-Initiativen heraus. Der Browser war eine Übersetzungsschicht: menschliche Absicht, ausgedrückt durch Klicks auf Formulare, die über Middleware in Tabellen schrieben, die APIs aufriefen. Entfernt man den Browser, schrumpft die Kette zusammen: Absicht mappt direkt auf den API-Call, der Agent übernimmt die Übersetzung. Der Administrator, der wusste, wie man sich durch siebzehn Screens klickt, um eine Compliance-Regel zu konfigurieren, verliert den Moat, den diese Screens boten. Der Operations-Spezialist, der die Reihenfolge von Checkboxes auswendig konnte, verliert ihn ebenfalls. Ebenso der Trainer, der neuen Mitarbeitern den Klickpfad beibrachte.

Was ersetzt diese Moats? Keine neuen auf derselben Ebene. Die Ebene selbst löst sich auf. An ihre Stelle tritt ein anderes Set von Artefakten (der System Prompt, das Tool-Schema, der Evaluation Harness) und eine andere Gruppe von Praktikern, die sie bauen. Anthropic, OpenAI und Salesforce liefern jeweils auf unterschiedliche Weise die Primitive dieser Ersatzschicht aus (Anthropic MCP docs; OpenAI function calling; Salesforce).

Das Gegenintuitive an einer verschwindenden Schnittstelle ist, dass die Arbeit nicht mit ihr verschwindet. Die Arbeit verlagert sich. Jemand muss weiterhin entscheiden, was eine Compliance-Regel bedeutet, welche Ausnahmen akzeptabel sind und was passieren soll, wenn der Vorschlag des Agenten an den Rand der Policy gerät. Diese Person klickt nicht mehr. Sie reviewt zunehmend.

Die Frage ist, wie man sie nennt.

Das Principal-Agent-Problem, Maschinenedition

Die Ökonomik hat seit fünfzig Jahren ein Framework für genau diese Situation. 1973 veröffentlichte Stephen Ross ein Paper, in dem er das Problem des Principal einführte: eine Situation, in der eine Partei eine Handlung an eine andere delegiert und der Agent private Information besitzt, die der Principal nicht vollständig beobachten kann (Ross 1973). Drei Jahre später formalisierten Michael Jensen und William Meckling das Framework in Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure und definierten Agency Costs als Summe aus Monitoring Expenditures des Principal, Bonding Expenditures des Agenten und Residual Loss (Jensen and Meckling 1976). Die Lücke zwischen dem, was der Principal wollte, und dem, was der Agent lieferte, ist die ganze Logik des Frameworks.

Ein halbes Jahrhundert lang wurde das Framework auf menschliche Agenten angewandt. Aktionäre delegierten an Führungskräfte. Klienten delegierten an Anwälte. Patienten delegierten an Ärzte. Jede Ausarbeitung der Theorie (leistungsgebundene Vergütung, Treuhandrecht, Audit Committees, Regeln zur Board-Unabhängigkeit) war ein Versuch, Residual Loss durch verändertes Monitoring zu verkleinern.

Im Jahr 2026 gilt das Framework mit ungewöhnlicher Direktheit. Software hat kein Eigeninteresse und keine Treuepflicht, daher ist die Analogie nicht perfekt. Aber die strukturellen Annahmen übertragen sich sauber genug, dass die Kostenkategorien fast ohne Verrenkung passen. Zwei jüngere Management-Papers, Humberd and Latham (2026) im Journal of Management Studies und Jarrahi and Ritala (2025) in der California Management Review, machen denselben Schritt unabhängig voneinander: Sie behandeln KI als neue Art von Agent in der Firma und fragen, wie Monitoring und Bonding aussehen, wenn der Agent Software ist.

Private Information war im ursprünglichen Framework der Wissensvorsprung des Agenten über Zustände, die der Principal nicht beobachten konnte. In der Maschinenversion ist Private Information das interne Reasoning des Modells: die Kette von Aktivierungen, die den Output erzeugt hat und sich von der API-Oberfläche aus nicht inspizieren lässt. Interessendivergenz war im Original der Agent, der persönlichen Nutzen auf Kosten des Principal verfolgt. In der Maschinenversion ist es ein Trainingsziel, das von der User-Absicht abweicht: Das Modell optimiert auf plausiblen Output statt auf korrekten Output, auf den Eindruck von Hilfsbereitschaft statt auf Substanz. Monitoring Cost war im Original der Preis für die Prüfung der Handlungen des Agenten. In der Maschinenversion ist es der Preis dafür, Model-Outputs im Produktionsmaßstab zu verifizieren, ein Preis, der mit Output-Volumen statt mit Aufgabenwichtigkeit skaliert. Residual Loss war im Original die Differenz zwischen beabsichtigtem und realisiertem Ergebnis. In der Maschinenversion ist es Halluzination, Scope Drift, stilles Versagen: die gesamte Taxonomie von Fehlern, die ein Principal womöglich nie entdeckt.

Die Theorie nahm praktisch jede Dynamik vorweg, die Agent-Deployment-Teams gerade mühsam wiederentdecken. Was sie nicht vorwegnehmen konnte, war die Größenordnung. Ein menschlicher Anwalt produziert ein Dokument nach dem anderen. Ein menschlicher Manager trifft eine Entscheidung nach der anderen. Dieses Volumen zu überwachen ist teuer, aber begrenzt. Ein Software-Agent produziert Dokumente, Entscheidungen und Seiteneffekte in einem Tempo, das kein Principal standardmäßig überblicken kann. Monitoring Cost war im klassischen Framework eine Frage der Sorgfalt. In der Maschinenedition ist sie eine Frage der Kapazität.

Diese Kapazität ist dort, wo sie existiert, in einer kleinen und namenlosen Gruppe von Menschen konzentriert. Sie sind der Flaschenhals. Sie sind, auch wenn es noch niemand so gesagt hat, eine Klasse.

Die Verifier-Klasse

Alexander Embiricos aus OpenAIs Codex-Team beschrieb den aktuellen Flaschenhals eher als menschliche Validierung und Code Review als als rohe Codegenerierung (Lenny's Newsletter). Embiricos sprach über einen spezifischen Workflow (asynchrone Coding-Agenten, die hochfahren, Änderungen erzeugen und zur Freigabe zurückbringen), aber die Diagnose verallgemeinert sich. Bereichsübergreifend ist der Schritt, der entscheidet, ob der Output eines Agenten in Produktion geht, der menschliche Pass danach.

Dieser Pass ist schwieriger, als er aussieht. Hamel Husain und Shreya Shankar, Forscher im Bereich AI Evals, argumentieren, dass sich Evaluationskriterien verändern, je mehr Outputs Menschen inspizieren, was bedeutet, dass sich die Rubrik nicht vollständig im Voraus fixieren lässt (Lenny's Newsletter). Der Verifier prüft die Arbeit des Agenten nicht nur gegen eine Spezifikation; er konstruiert die Spezifikation in Echtzeit, als Reaktion auf die Verteilung der Outputs, die das System tatsächlich produziert. Evaluation ist in diesem Regime nicht bloß das Anwenden einer Testsuite. Es ist das Erfinden einer Testsuite unter Druck.

In der Praxis sieht das aus wie ein Defekt-Floor, den der Generator zuverlässig einführt, und ein Review-Ceiling, das der Verifier zuverlässig liefern kann, während sich die Lücke mit zunehmender Nutzung weitet. Der Floor ist messbar: Veracodes Spring-2026-Update stellte fest, dass 55 Prozent der getesteten KI-Codegenerierungsaufgaben sicher waren, was impliziert, dass im benchmarkten Set rund 45 Prozent bekannte Sicherheitsprobleme enthielten (Veracode). Eine Y-Combinator-Diskussion über die W25-Kohorte, berichtet von TechCrunch, sagte, dass rund ein Viertel der Batch Codebases hatte, die zu 95 Prozent KI-generiert waren (TechCrunch). Hochvolumige Generierung, die mit leichter Prüfung in Produktion läuft, ist keine Prognose. Es ist bereits normal.

Nichts davon ist auf Code beschränkt. Dasselbe Muster wiederholt sich in Legal Review, in der medizinischen Dokumentation, in Financial Analysis, in Marketing Copy. In jedem Bereich produziert der Agent in Volumen; ein Mensch prüft; der Prüfer ist die begrenzende Ressource. Die fachspezifischen Details variieren. Die Form der Rolle nicht.

Diese Rolle hat keinen Titel. Sie hat keine Karriereleiter. Sie taucht in keinem Organigramm auf. Derzeit wird sie von den Leuten ausgefüllt, die gerade in der Nähe sind: dem Senior Engineer, der eigentlich Features bauen sollte, dem Staff Lawyer, der eigentlich Mandanten beraten sollte, dem Lead Designer, der eigentlich gestalten sollte. Ihr offizieller Job ist etwas anderes. Ihr tatsächlicher Job ist, zu reviewen, was ein Agent produziert hat, und zu entscheiden, ob es shipped.

Sie sind die Verifier-Klasse. Der Name ist neu; die Funktion ist es nicht. Aber die Bedingungen sind neu.

Was einen Verifier von einem Reviewer, Editor, Auditor oder Approver unterscheidet, ist nicht der Review-Akt selbst. Es ist das Zusammentreffen von drei Bedingungen.

Die Upstream-Queue ist ungekapppt: Output wird von einem System erzeugt, dessen Durchsatz mit API-Spend skaliert, nicht mit den Arbeitsstunden eines anderen Menschen. Der Durchsatz des Verifiers skaliert nicht mit: Er ist durch menschliche kognitive Bandbreite begrenzt. Und die Rubrik ist emergent: Wie Husain und Shankar beschreiben, muss sie sich als Reaktion auf die Verteilung der Outputs bilden, die das System tatsächlich produziert, statt im Voraus definiert zu werden.

Editoren und Auditoren erfüllen eine oder zwei dieser Bedingungen. Der Verifier erfüllt alle drei gleichzeitig. Das ist das ökonomische Herz der Rolle.

Die Verteilungsfrage

Die dominante Erzählung über KI und Arbeit kreist um Verdrängung: Generative Systeme würden die Mitte der Skill-Verteilung komprimieren, Mid-Level-Knowledge-Worker überflüssig machen und Gewinne bei Kapitaleignern und Frontier-Talent konzentrieren. Diese Erzählung setzt den reibungsfreien Fall voraus: ein Agent, der seinen eigenen Output ohne Review shipped.

Verifikation verändert die Form. Anders als Generierung ist Verifikation stark domainabhängig. Ein General-Purpose-Agent kann eine Patentanmeldung, einen Radiologiebericht, eine Quartalsmitteilung und eine Kreditfreigabe entwerfen. Der Verifier für jedes dieser Artefakte muss jeweils über das Domänenwissen eines Patentanwalts, Radiologen, Controllers und Kreditentscheiders verfügen. Dieses Wissen ist nicht übertragbar. Es lässt sich nicht schnell synthetisieren. Es entsteht aus Jahren spezifischer Ausbildung in einem spezifischen Kontext, und genau das ist am schwersten auszulagern.

Die kontraintuitive Konsequenz ist, dass Verifikation manche Formen von Expertise wieder lokalisiert. Offshoring beruhte in früheren Jahrzehnten darauf, dass Ausführung vom Kontext entkoppelt werden konnte: Die Spezifikation wurde im Ursprungsland einmal geschrieben und im Ausland vielfach ausgeführt. Verifikation lässt sich nicht entkoppeln. Jeder Output verlangt ein neues Urteil. Jedes Urteil verlangt den Kontext, den der Agent nicht mitliefert.

Figma’s State of the Designer 2026, eine Umfrage unter 906 Digital Designern in Zusammenarbeit mit NewtonX, dokumentierte eine scharfe Umformung der Rolle selbst (Figma report; Figma blog). Ausführungsarbeit (die Produktion von Mockups, Wireframes, Prototypen) ist stark im Preis gefallen, während Urteilsarbeit (die Auswahl, Kuratierung und editorische Ausrichtung generierter Optionen) zur bindenden Constraint wurde, wie die Befragten sie beschreiben. In einem separaten Hiring-Post argumentiert Figma, dass KI die Nachfrage nach Designern erhöht, besonders nach Senior Hires mit stärkerem Urteil und mehr Erfahrung (Figma hiring post). Die beiden Aussagen liegen auf unterschiedlichen Ebenen. Die eine beschreibt, wie Designer ihre Arbeit erleben; die andere, wie Figma das für Enterprise-Kunden interpretiert. Beide weisen in dieselbe Richtung. Der Jobtitel blieb gleich. Der Job nicht.

In Lenny Rachitskys Interview vom Februar 2026 formulierte Lazar Jovanovic von Lovable den Ersatzskill als Klarheit, Taste, Judgment und bessere Entscheidungsfähigkeit statt als reine Coding-Geschwindigkeit (Lenny's Newsletter). Klarheit bedeutet hier: eine Absicht so zu spezifizieren, dass der Agent sie nicht missverstehen kann, und zu erkennen, wann er es doch getan hat. Das ist derselbe kognitive Zug, den Verifikation verlangt, nur von der anderen Seite beschrieben.

Diese Beobachtungen zeigen in eine Richtung. Der Arbeitsmarkt flacht nicht zu einer schmalen Frontier-Elite ab. Er schichtet sich entlang einer neuen Achse (Generator versus Verifier), die quer durch bestehende Rollen verläuft. Die High-Leverage-Position ist der Verifier in einer wichtigen Domäne, mit Kontext, der sich nicht leicht skripten lässt, und Urteilskraft, die sich nicht leicht automatisieren lässt. Vergütung wird folgen. Hiring Friction ebenfalls: Die Zahl der Menschen, die im großen Maßstab generieren können, explodiert; die Zahl derer, die im großen Maßstab verifizieren können, nicht.

Diese Asymmetrie ist die nächste Preisanomalie des Arbeitsmarkts.

Die zwei Interfaces

Jedes Softwareprodukt, das in den nächsten fünf Jahren gebaut wird, wird zwei Interfaces tragen, ob seine Designer sie benennen oder nicht.

Das erste ist das Protocol Interface: die Oberfläche, über die Agenten das System bedienen. Seine Primitive sind der API Endpoint, die MCP-Tool-Definition, der CLI-Command, der Permission Scope, das Rate Limit. Seine Design-Disziplin ist Lesbarkeit für ein Modell: Naming, das Ambiguität widersteht; Schemas, die fail closed; Dokumentation, die dicht genug für Retrieval und strukturiert genug für Tool Selection ist. Salesforce’ Headless 360 ist ein frühes öffentliches Statement dafür, wie dieses Interface im Enterprise-Maßstab aussieht, während Anthropic’s Model Context Protocol und OpenAIs Tool-Use-Spezifikationen Teil der Ökosystem-Infrastruktur darum herum sind (Salesforce; Anthropic MCP docs; OpenAI function calling).

Das zweite ist das Judgment Interface: die Oberfläche, über die ein Verifier prüft, freigibt, ändert oder ablehnt, was der Agent getan hat. Seine Primitive sind der Diff, der Rollback, die Trace, die Attribution Chain, die Approval Queue. Seine Design-Disziplin ist nicht Lesbarkeit für ein Modell, sondern Lesbarkeit für einen Domänenexperten unter Zeitdruck. Was ist passiert? Warum? Was ändert sich, wenn es bestehen bleibt? Was bricht, wenn es rückgängig gemacht wird? Ein gut gestaltetes Judgment Interface erlaubt es einem Domänenexperten, einen KI-unterstützten Output schnell zu bestätigen; ein schlecht gestaltetes zwingt ihn, die Arbeit manuell neu zu machen, und vernichtet den Effizienzgewinn, den der Agent eigentlich liefern sollte.

Die meisten Unternehmen bauen derzeit das erste Interface aggressiv und das zweite fast gar nicht. Die Protocol Surface bekommt eine Roadmap, ein dediziertes Team und Aufmerksamkeit auf Board-Ebene. Die Judgment Surface bekommt ein nachträglich angebautes Admin Panel, einen CSV-Export oder, zunehmend, gar nichts — in der Annahme, der Agent sei "gut genug", um ohne Review zu shippen. Jeder Verifier, der heute aus einem Ticketing-System heraus arbeitet, widerlegt diese Annahme.

Eine falsifizierbare Prognose: Bis Ende 2028 erwarte ich, dass die meisten führenden Enterprise-Software-Anbieter ein benanntes, erstklassiges Judgment Interface ausliefern. Der auslösende Druck ist nicht Agency Theory, sondern Procurement. Wenn frühe Agent-Ära-Verträge zur Verlängerung anstehen, wird die Frage nach Verifier-Burnout ohne dedizierte Oberfläche schwer zu beantworten sein.

Die tiefere Verschiebung ist älter als jede dieser Technologien. Jensen und Mecklings Framework von 1976 wandert aus ökonomischen Fakultäten in Produkt-Roadmaps. Die Monitoring Costs, die sie modellierten, werden zu UX-Budgetposten. Der Residual Loss, den sie benannten, wird zu einer Quarterly Metric. Agency Theory, fünf Jahrzehnte lang die Sprache der Corporate Governance, wird zur Sprache des Softwaredesigns.

Wenn der User ein Agent ist, ist der Kunde ein Verifier. Diese Unterscheidung ist nicht rhetorisch. Sie ist die Form des nächsten Jahrzehnts von Enterprise-Software und des Arbeitsmarkts, der sie betreibt. Die Produkte und Karrieren, die das verstehen, werden compounden. Der Rest wird weiter für einen Principal optimieren, der den Screen längst verlassen hat.

Sources