Agenten sind immer Neueinstellungen am ersten Tag. Es ist Zeit, dafür zu entwerfen.

Bis 2027, 74% der Unternehmen werden laut einer aktuellen Deloitte-Studie Agenten in irgendeiner Form einsetzen. Jahrelang haben wir Software entworfen und gebaut, um das menschliche Erlebnis beim Navigieren durch unsere Apps, Websites, Betriebssysteme und Dokumente zu verbessern. Jetzt ist der Nutzer überhaupt kein Mensch mehr. Das hat weiterreichende Folgen, die über die Verlagerung von Dashboards und den von uns für menschliche Aufgaben gestalteten kontrollierten Workflows hinausgehen. Wir befinden uns in einem Moment, in dem wir die Betriebsumgebungen von Agenten designen müssen, während wir auch gleichzeitig menschliche Workflows entwerfen, um die Agentenerfahrung in diesen Umgebungen effektiv zu steuern.  

Wir stehen noch am Anfang unseres Lernens darüber, was Agenten tatsächlich von uns benötigen, um wiederholbar und zuverlässig erfolgreich zu sein. Der Instinkt ist, die Integration von Agenten rein als Prompt‑ oder UI‑Problem zu betrachten. Das Gestalten einer gut gesteuerten Ausführungsumgebung ist für uns kulturell Neuland. Die grundlegenden Prinzipien von gutem Design und guter Verwaltung haben sich jedoch nicht geändert: wir schulden den Agenten klaren Kontext, eindeutige Richtung und explizite Absicht.

Kontext: Warum das Programmieren zuerst kam

Kontext ist wahrscheinlich der wichtigste Input, wenn wir wollen, dass Agenten wiederholt auf dem gewünschten Niveau liefern. In der Softwareentwicklung ist mehr davon dokumentiert als in fast jedem anderen Bereich: Repositories, API‑Schemata, die Beziehungen zwischen Systemen, Code‑Reviews und Community‑Diskussionen. Daher ist es logisch, dass KI‑Forschungslabore mit dem Programmieren begannen. Es ist eines der wenigen Gebiete, in denen ein großer Teil des Kontextes bereits schriftlich festgehalten ist. 

Aber wie jeder neue Mitarbeiter in einem Softwareteam sagen wird, selbst mit all diesen Daten werden Agenten immer noch die institutionelle Erinnerung vermissen, die in den ungeschriebenen Regeln steckt, die niemand dokumentiert hat. Diese Lücke ist weit verbreitet: 43 % der Entwickler befürchten, dass KI‑Tools nicht genug Kontext zu ihrem konkreten Projekt oder Code‑Base haben. Implizites Wissen umfasst alles von alltäglichen Konventionen, wie bevorzugten Bibliotheken für bestimmte Aufgaben, bis hin zu hochbrisanten operativen Geistern: ein nächtlicher Hotfix, der ewig bestehen bleibt, oder eine scheinbar leere Datenbankspalte, die heimlich einen kundenspezifischen Umsatzbericht untermauert. Dieser Kontext lebt im Kopf eines Senior‑Engineers, in einem aktuellen Slack‑Thread oder überhaupt nirgends. Er befindet sich selten im Code‑Base selbst.  

Wenn das in der Software, einem der am besten dokumentierten Bereiche, zutrifft, ist leicht nachvollziehbar, warum Agenten in vielen anderen Branchen ab dem ersten Tag Schwierigkeiten haben, effektiv zu arbeiten. Im Gesundheitswesen und im Rechtsbereich wird ein großer Teil des institutionellen Wissens, das die tägliche Arbeit prägt, erlernt und verinnerlicht. Es lebt in den Erfahrungen der Menschen und nicht in formaler Dokumentation. Ein juristischer Agent kennt möglicherweise nicht die bevorzugte Struktur, den Ton oder die Argumentationsweise eines bestimmten Partners für ein Schreiben, während ein Gesundheits‑Agent die lokalen Workflows und Eskalationspraktiken einer stark frequentierten Klinik, die die ärztlich geführte Triage unterstützen, nicht versteht. Dokumentation allein kann diese Lücke nicht schließen, weil die Herausforderung nicht nur der Zugang zu Informationen ist, sondern die Übertragung von Kontext. Um Agenten das zu geben, was sie zum Erfolg benötigen, müssen wir sie genauso einarbeiten, wie wir einen neuen Mitarbeiter aufnehmen würden.

Richtung: Warum Osmose nicht funktioniert

Die Einarbeitung eines neuen Teammitglieds erfordert mehr als das Bereitstellen der richtigen Materialien und Zugänge. Wenn wir am Erfolg der Menschen um uns herum interessiert sind, geben wir klare Anweisungen, was mit den neuen Materialien und Zugängen zu tun ist: Erwartungen, Klarheit über das angestrebte Ziel und fortlaufendes Feedback. Diese Denkweise übertrage ich auch auf das Design für Agenten. Ich gebe klare, spezifische Anweisungen (bezogen auf die aktuelle Aufgabe). Das gilt für jedes Teammitglied, unabhängig von dessen Betriebszugehörigkeit. Dennoch muss in einem Szenario mit einem Neueinstellungen die Richtung weiter gehen, weil sie noch keinen institutionellen Kontext besitzen.

Stellen Sie sich einen Agenten als einen Neueinstellungen vor, der niemals aufhört, neu zu sein. Er ist eifrig und fähig (und ehrlich gesagt hat er unerschöpfliche Energie), aber er kann nicht so viele ungeschriebene Regeln aufnehmen und behalten, wie es ein Mensch im Laufe der Zeit tut. Menschen lernen durch Osmose und Erfahrung, während Agenten aus einer Architektur lernen, die explizit in ihre Arbeitsumgebung eingebaut ist.

Bei einem Neueinstellungen können Sie diese Lücke im Laufe der Zeit durch Fragen, Feedback und neue Erkenntnisse, die er über die Prozesse und Vorlieben der Organisation sammelt, schließen. Wörtlich Gespräche an der Kaffeemaschine oder Team‑Mittagessen. Bei einem Agenten müssen Sie diese Lückenschließung in das Design selbst einbauen. Das kann beinhalten: 

• Dem Agenten ein strukturiertes Kontextfenster geben, das dauerhafte Regeln, aufgabenbezogene Fakten und relevante Historie trennt, anstatt ihm einen Haufen Dokumente aufzuzwingen. 
• Seine Berechtigungen und Entscheidungsgrenzen von Anfang an festlegen: was es eigenständig tun darf, was Genehmigung erfordert und worauf es niemals zugreifen darf. 
• Einige konkrete Beispiele für hochwertige Ergebnisse direkt in die Erfahrung einbetten, damit der Agent ein klares Modell dafür hat, wie die Arbeit ausgeführt werden soll.
• Frühere Sackgassen, die Sie erlebt haben, teilen.

Das Design einer gut gesteuerten Agenten‑Umgebung geht nicht darum, die Arbeit für das Modell zu erleichtern. Es geht darum, das menschliche Engineering‑Team vor unsichtbarer technischer Schuld zu schützen. Doch selbst ein gut angeleiteter Agent kann Anweisungen perfekt befolgen und dennoch das Wesentliche verfehlen. Die Richtung sagt ihm, was zu tun ist, aber nicht, wie „gut“ aussieht. Genau hier kommt die Absicht ins Spiel.

Absicht: Warum Agenten zum Mittelwert tendieren

Es ist wichtig, sich daran zu erinnern, dass Agenten Muster‑Erkennungs‑Maschinen sind, die auf riesigen Wissensmengen trainiert wurden und von Natur aus dazu neigen, den statistischen Durchschnitt zu liefern. Ohne klare, explizite Absicht ist genau dieses Durchschnittsergebnis das, was ein Agent zurückliefert. Bitten Sie einen Agenten, „einen Endpunkt für die Benutzerauthentifizierung hinzuzufügen“, so erzeugt er eine textbook‑Express‑Route mit einfacher Passwort‑Hashing. Es funktioniert, ignoriert jedoch vollständig den benutzerdefinierten Auth‑Service Ihres Teams, überspringt erforderliche Telemetrie und zerstört Ihr standardisiertes Fehlermeldungsformat. Auf dem Papier ist es ein ausreichendes Feature, aber je nach Kontext ein architektonischer Fehler in der Praxis. Die Leichtigkeit, mit der solche „Bugs“ eingeführt werden, kann nicht genug betont werden.

Um dies zu verhindern, muss die Richtung mit aktiver Absichts‑Verifizierung und Protokollierung gekoppelt werden. Leitplanken sollten nicht nur prüfen, ob der Code kompiliert, obwohl das wichtig ist. Leitplanken müssen ausdrücklich die voreingenommenen Standards, Randfall‑Regeln und den Domänen‑Kontext durchsetzen, die generische Ausgaben zu produktionsreifer Arbeit aufwerten. Protokollierung ist für uns Menschen ein Indikator für den Systemstatus. Diese Nachverfolgbarkeit ist entscheidend für das Vertrauen. 

In menschlichen Interaktionen gibt es viel Raum für Unsicherheit. Jemand kann Ihnen eine erste Version zeigen, und gemeinsam können Sie besprechen, was stark ist und was verbessert werden muss. Das funktioniert, weil wir nicht erwarten, dass unsere menschlichen Kolleg*innen autonome Maschinen sind. Um die Kraft und das Versprechen von agentenbasierten Kolleg*innen (die wir tatsächlich autonomer einsetzen müssen…) wirklich zu nutzen, können wir viele dieser Richtungs‑Checks einbauen. Der Austausch muss weiterhin stattfinden, darf aber nicht ausschließlich manuell erfolgen. Indem Sie klare Akzeptanzkriterien und Verifizierungsregeln von vornherein festlegen, ermöglichen Sie dem Agenten, eigene interne Feedback‑Schleifen zu betreiben. Design für Fehlervorbeugung ist ein weiteres bewährtes UX‑Prinzip, das wir in dieser neuen Welt anwenden können: dem Agenten die Möglichkeit geben, niedrige Vertrauenswerte zu kennzeichnen, bevor er eine Aktion ausführt, anstatt stillschweigend auf eine Schätzung zurückzugreifen.

Wo die Metapher versagt

Das Neueinstellungen‑Modell funktioniert, bis es nicht mehr funktioniert. Bei einer menschlichen Einstellung führt Erfahrung zu Kompetenz, die zu Urteilsvermögen führt. Beobachtet man, wie der Neueinstellungen das „Warum“ hinter Kontext und Richtung verinnerlicht, entsteht über die Zeit Vertrauen, und im Allgemeinen ist das kumulativ. Ein Agent hat keinen Ort, an dem er diese Erfahrung ansammeln und speichern kann.

Die erste Woche und die hundertste Woche eines Neueinstellungen sehen unterschiedlich aus. Die erste und die tausendste Aufgabe eines Agenten sehen identisch aus, es sei denn, Sie entwerfen und bauen etwas, das sie unterscheidet. Das ist unsere neue Design‑Herausforderung.

Agentenverantwortung hängt vom Design ab

Wenn Verantwortung nicht im Agenten selbst verankert sein kann, muss sie in der umgebenden Struktur liegen. Es reduziert sich auf dieselben drei Fragen, die ich stellen würde, bevor ich einer Neueinstellung Arbeit übertrage: Welchen Kontext hat sie? Welche Richtung habe ich ihr gegeben? Was ist meine eigentliche Absicht?

Das nächste Mal, wenn Sie einem Agenten eine Aufgabe übertragen, prüfen Sie nicht nur das Ergebnis. Überprüfen Sie zuerst Ihre eigenen Eingaben. Haben Sie ihm den Kontext gegeben, den ein Neueinstellung am ersten Tag benötigen würde? War Ihre Richtung spezifisch genug, um wörtlich genommen zu werden? War Ihre Absicht klar genug, dass die „mittlere Antwort“ nicht das Beste war, das er hätte liefern können?

Mit dieser klaren Anleitung (in Byte?) geschieht etwas Interessantes: ein Agent benötigt keine lange Anlaufphase, um vertrauenswürdig zu werden. Der Kontext, die Richtung und die Verifizierung, die Sie von Anfang an einbauen, bestimmen, wie er jede Aufgabe ausführt. Ein Neueinstellung gewinnt Ihr Vertrauen im Laufe der Zeit; ein Agent muss es jedes Mal durch das von Ihnen entworfene System verdienen. Verantwortung ist nichts, woran er wächst, sie ist von Anfang an eingebaut. Die Frage ist nicht, wann Ihr Agent bereit für mehr Verantwortung ist, sondern ob Sie ihn so gestaltet haben, dass er diese Verantwortung bei jeder einzelnen Aufgabe verdient.