Von der KI-Einführung zum agentenbasierten Betrieb: Was die „AI in 2026“-Sammlung der HBS für Enterprise-KI bedeutet

Die Forschungssammlung „AI in 2026“ von HBS Working Knowledge steht unter dem Motto „Von der Einführung zum Agentischen“. Unsere Interpretation für die Infrastruktur ist der Wandel hin zur delegierten Ausführung: Sobald KI in der Lage ist, Aufgaben über verschiedene Schritte, Tools, Systeme und Personen hinweg zu erledigen, müssen Unternehmen festlegen, was das System tun darf, mit wessen Befugnis, unter welchen Kontrollen und mit welchen Nachweisen im Anschluss.

1. Der entscheidende Wandel liegt nicht bei Prompts oder besseren Prompts

Viele frühe generative KI-Programme in Unternehmen konzentrierten sich auf den Zugang und die Einführung. Agentische Systeme erweitern die Arbeitseinheit: Anstatt dass ein einzelner Durchlauf eine Antwort liefert, kann ein Prozess Modellaufrufe, Tools, persistente Zustände, Genehmigungen, Wiederholungen und externe Auswirkungen umfassen.

Das verändert die operative Fragestellung. Ein Prompt kann Informationen anfordern oder eine Transformation anstoßen; ein Agenten-Durchlauf kann zu einer Delegation von Arbeitwerden.

Das ist der rote Faden, der die HBS-Forschung verbindet. Der Beitrag zur Führung fragt, was passiert, wenn Führungskräfte digitale Unterstützungsteams erhalten. Die Forschung zu Arbeitsplätzen untersucht, welche Aufgaben Menschen bereit sind zu delegieren. Die Studie zur Teamarbeit fragt, wann KI die kollaborative Leistung verbessert. Die Studie zur Kreditvergabe untersucht, worauf es Menschen ankommt, wenn Algorithmen folgenschwere Entscheidungen treffen. Die Diskussion zur Talentdichte fragt, wie Unternehmen knappes Fachwissen in einen Wettbewerbsvorteil verwandeln.

2. HBS-Thema eins: Führung wird zu Orchestrierung

In „What Leadership Looks Like in an Agentic AI World“beschreiben Tsedal Neeley und Ritcha Ranjan agentische KI als potenzielle digitale Unterstützung für Führungskräfte: Systeme, die Informationen sammeln, sie mit organisatorischen Prioritäten abgleichen, Führungskräfte auf Interaktionen vorbereiten und komplexe Aufgaben semi-autonom ausführen können.

Die technische Konsequenz wird leicht übersehen. Ein nützliches „digitales Unterstützungsteam“ lässt sich nicht als einfache zustandslose Vervollständigung modellieren. Es benötigt eine Laufzeitumgebung, die einen Vorgang beibehalten, über mehrere Schritte hinweg agieren, Tools nutzen, bei Bedarf auf menschliche Beurteilung warten und die durchgeführten Aktionen nachvollziehbar machen kann.

Dies ist die Rolle, die ein Agent-Harness spielt. TrueForge in seiner offiziellen Dokumentation beschreibt sich selbst als Agent-Harness, also als Laufzeitumgebung für ein LLM, die die Ausführungsschleife für Modelle und Tools steuert, den Kontext bei langwierigen Aufgaben verwaltet, MCP-Tools und -Skills unterstützt, bei Bedarf eine isolierte Ausführungsumgebung (Sandbox) bereitstellt, für menschliche Freigaben pausiert, Sub-Agenten unterstützt und Sitzungen über Wiederverbindungen und Neustarts hinweg beibehält.

Der Anspruch sollte begrenzt bleiben: TrueForge kann einen Agenten dauerhaft und überprüfbar machen. Es bestimmt jedoch nicht die Prioritäten einer Führungskraft, entscheidet nicht, welche Aufgaben delegiert werden sollten, und weiß nicht, wie gute Führung aussieht.

3. HBS-Thema zwei: Aufgaben automatisieren, nicht Verantwortung

Die HBS-Forschung von James Riley zur öffentlichen Einstellung gegenüber Automatisierung untersuchte 2.357 Personen aus 940 Berufen. Die Befragten befürworteten die Automatisierung von etwa 30 % der Arbeitsplätze bei den derzeitigen Möglichkeiten; bei der Vorstellung einer KI, die den Menschen zu geringeren Kosten übertrifft, stieg die Zustimmung auf 58 %. Dennoch gab es eine signifikante Gruppe von Berufen, die sich der Automatisierung aus sozialen oder moralischen Gründen widersetzten.

Für die Unternehmensarchitektur ist nicht der prozentuale Hauptwert die wichtige Lektion. Es ist die Erkenntnis, dass Delegationsgrenzen kontextabhängig sind. Manche Arbeiten können unbeaufsichtigt ausgeführt werden. Manche Arbeiten sollten durch den Menschen ergänzt werden. Manche Arbeiten sollten eine menschliche Entscheidung erfordern, selbst wenn das Modell technisch in der Lage wäre, zu handeln.

Das spricht gegen einen universellen „autonomen Modus“. Ein Produktionssystem benötigt explizite Kontrollpunkte:

• Auf welche Modelle und Tools darf dieser Agent zugreifen?
• Welche Vorgänge können ohne Eingreifen ausgeführt werden?
• Welche Aktionen erfordern eine menschliche Freigabe?
• Welches nachgelagerte System bleibt für die endgültige Auswirkung maßgeblich?
• Was passiert, wenn Richtlinien, Budget oder Autorisierung ein Nein vorgeben?

TrueFoundry MCP Gateway bildet die natürliche Entsprechung für die gemeinsame Tool-Grenze: Registrierung und Discovery, Inbound-Identität, Tool-basierte Zugriffskontrolle, Downstream-Anmeldeinformationen, Pre-/Post-Tool-Leitplanken, Genehmigungsworkflows und Audit-Funktionen für MCP-Datenverkehr, der über das Gateway geleitet wird. AI Gateway bietet eine entsprechende Modellgrenze mit einheitlichem Zugriff, RBAC, Ratenbegrenzungen, Budgets, Routing/Fallbacks, Leitplanken und Observability.

Die produktive Autorisierung muss zudem unterschiedliche Prinzipale wahren. Der Mensch oder die Workload ist das Subjekt , in dessen Namen die Arbeit erfolgt; der registrierte Agent ist der Akteur , der den Aufruf tätigt; und der nachgelagerte Dienst wendet die für dieses Ziel konfigurierten Anmeldeinformationen und geschäftlichen Berechtigungen an. Das Beta-Agenten-Identitätsdesign von TrueFoundry ermöglicht es, den Benutzer oder Dienst zurechenbar zu halten und gleichzeitig den aufrufenden Agenten separat zu identifizieren und zu autorisieren. Das gewährt jedoch noch keine geschäftliche Berechtigung: Die Erlaubnis, process_refund aufzurufen, unterscheidet sich von der Erlaubnis, eine bestimmte Bestellung über einen bestimmten Betrag zu erstatten.

Keines der beiden Gateways trifft die zugrunde liegende geschäftliche Entscheidung für Sie. Wenn eine Rückerstattung, ein Kredit, eine Bereitstellung oder eine Berechtigungsänderung domänenspezifische Autorisierungsregeln erfordert, gehören diese Regeln weiterhin zur entsprechenden Richtlinie und zum maßgeblichen System.

4. HBS-Thema drei: KI kann zum Teammitglied werden – doch Teamarbeit erfordert eine gemeinsame Infrastruktur

Der HBS-Artikel „When AI Joins the Team, Better Ideas Surface“ berichtet von einem Feldexperiment mit 791 Fachkräften von Procter & Gamble. Teams, die KI einsetzten, erzielten im Experiment die qualitativ hochwertigsten Lösungen; Ideen in den Top 10 % stammten dreimal häufiger von Teams mit KI-Unterstützung als von Einzelpersonen, die ohne KI arbeiteten. Zudem verkürzte die KI die Bearbeitungszeit um 16 % bei Einzelpersonen und um 13 % bei Teams. Die abschließende, von Fachleuten begutachtete Studie wurde in Organization Science im Jahr 2026.

Das bedeutet nicht, dass jedes Unternehmen eine ganze Schwarmintelligenz von Agenten aufbauen sollte. Es deutet auf etwas Subtileres hin: KI kann den Zugang zu Fachwissen erweitern und helfen, funktionale Silos aufzubrechen, sofern sie in ein gut durchdachtes Arbeitssystem eingebettet ist.

Für Infrastrukturteams wirft das ein Problem der Wiederverwendbarkeit auf. Wenn jedes Team seine eigenen Modelladapter, Tool-Zugangsdaten, Agenten-Loops, Genehmigungs-UX, Skills und Traces entwickelt, erzielt das Unternehmen zwar lokale Beschleunigung, aber globale Fragmentierung.

Ein skalierbareres Modell sieht so aus:

• TrueForge für die offene Laufzeitmechanik der Agentenausführung.
• AI Gateway für den gemeinsamen Modellzugriff und modellseitige Richtlinien.
• MCP Gateway für den kontrollierten Zugriff auf Tools und Daten.
• Skills Registry für versioniertes prozedurales Wissen, das über verschiedene Agenten-Oberflächen hinweg wiederverwendet werden kann.
• Agent Registry für ein gemeinsames Inventar, eine Zugriffsoberfläche sowie Metriken und Traces für registrierte Agenten, einschließlich Remote-Agenten.

Der organisatorische Vorteil besteht nicht in „mehr Agenten“. Er liegt darin, dass nützliche Praktiken wiederverwendbar werden, anstatt in einem einzelnen Prompt, auf dem Laptop eines Entwicklers oder in der privaten Integration eines Teams gefangen zu bleiben.

5. HBS-Thema vier: Entscheidungen mit hoher Tragweite erfordern Leistung und Nachweise

Elisabeth Paulsons Forschung zu menschlichen versus algorithmischen Entscheidungsträgern untersuchte etwa 9.000 TeilnehmerIm Kreditszenario entschieden sich die Teilnehmer mit einer um 4,3 Prozentpunkte höheren Wahrscheinlichkeit für einen menschlichen Bankmanager als für einen Algorithmus. Zwar zeigten die Teilnehmer im Durchschnitt weiterhin eine Präferenz für menschliche Entscheidungsträger, die Studie ergab jedoch, dass die Leistungsmerkmale des Entscheidungsträgers insgesamt wichtiger waren als die Frage, ob es sich um einen Menschen oder einen Algorithmus handelte.

Dies ist kein Beweis dafür, dass Fairness, Rechtmäßigkeit oder ein ordnungsgemäßes Verfahren zur Disposition stehen. Die Studie selbst bewertet geäußerte Präferenzen in zwei Conjoint-Experimenten und nicht die reale Validität des Einsatzes eines automatisierten Entscheidungssystems. Die wichtigere Lektion für Systeme ist enger gefasst: Leistungsversprechen benötigen messbare Belege, während rechtliche, ethische, datenschutzrechtliche, faire, transparente und implementierungsbezogene Verpflichtungen unabhängig bewertet werden müssen.

Dies erfordert die Trennung von mindestens vier Ebenen:

TrueForge’s Agent → Sitzung → Turn → Ereignis -Modell kann Laufzeitnachweise rund um einen Vorgang bewahren. TrueFoundry Gateways fügen Anforderungs- und Tool-Grenz-Telemetrie für den darüber geleiteten Datenverkehr hinzu. Diese Aufzeichnungen sind nützliche Grundlagen für Debugging, Überprüfung, Evaluierung und Audit – aber ein Trace ist selbst kein Evaluator, und eine Genehmigung ist kein Ersatz für eine Autorisierung.

6. HBS-Thema fünf: Talentdichte schafft ein Wiederverwendungsproblem

Im Interview von HBS Working Knowledge mit Boris Groysberg ist das zentrale Argument, dass es einfacher ist, Top-KI-Talente zu gewinnen, als diese so zu integrieren, dass sich ihr Wissen im gesamten Unternehmen vervielfacht. Bei der „Talentdichte“ geht es nicht nur um die Anzahl außergewöhnlicher Mitarbeiter; es geht darum, starke Persönlichkeiten in kritischen Rollen einzusetzen und Bedingungen zu schaffen, unter denen ihr Fachwissen die Leistung des Systems um sie herum verändert.

Diese Forschung hat Auswirkungen auf die Infrastruktur. Hochqualifizierte KI-Ingenieure sollten ihre knappe Zeit für Architektur, Evaluierung, Produktbeurteilung, Modell-/Tool-Auswahl und die spezifische Geschäftslogik aufwenden – nicht für den wiederholten Aufbau von Authentifizierung, Provider-Adaptern, Tool-Credential-Handling, Genehmigungsstatus, Kostenrechnung und Trace-Infrastruktur für jede Anwendung.

TrueFoundry Skills Registry ist hier besonders relevant. Sie bietet einen gemeinsamen Katalog wiederverwendbarer, versionierter Agenten-Skills mit Repository-RBAC, Versionsverlauf und Audit. Dadurch wird ein nützliches Verfahren von einer individuellen Technik zu einem organisatorischen Artefakt. Dasselbe Prinzip gilt für registrierte Agenten, Gateway-Richtlinien, Routing-Regeln, Budgets und gemeinsame Observability.

7. Von organisatorischen Erkenntnissen zu einem agentenbasierten Betriebsmodell

Die Zusammenführung der fünf HBS-Themen deutet auf ein Unternehmensbetriebsmodell hin, das weder „Menschen genehmigen alles“ noch „Agenten führen alles aus“ lautet. Es ist ein gestuftes Delegationssystem:

8. Was sollten Unternehmen jetzt standardisieren?

Die HBS-Forschung ist organisatorischer Natur, keine Spezifikation für Softwarearchitektur. Doch sobald eine Organisation die Prämisse akzeptiert, dass KI zunehmend als Teammitglied, Delegierter und Entscheidungsteilnehmer agieren wird, werden eine Reihe von Infrastrukturfragen unvermeidlich.

1. Standardisieren Sie die Agenten-Laufzeit. Definieren Sie, wie Sitzungen persistiert, Tools entdeckt, Kontext verwaltet, Code isoliert, die Ausführung durch Genehmigungen pausiert und Ereignisse aufgezeichnet werden.
2. Trennen Sie Modellrichtlinien vom Anwendungscode. Zentralisieren Sie Anbieter-Anmeldedaten, Zugriffskontrolle, Routing, Budgets, Ratenbegrenzungen, Sicherheitsvorgaben und Modell-Telemetrie, wo immer dies möglich ist.
3. Schützen Sie Unternehmens-Tools durch explizite Identitäts- und Richtlinienvorgaben. Behalten Sie den menschlichen oder arbeitslastbasierten Subjektbezug bei, identifizieren Sie den handelnden Agenten und setzen Sie nachgelagerte geschäftliche Autorisierungen durch. Ein Tool wird nicht allein dadurch sicher, dass es MCP spricht.
4. Konzipieren Sie HITL (Human-in-the-Loop) als einen zustandsbasierten Übergang innerhalb der Laufzeitumgebung. Der Prozess sollte vor der Ausführung einer Nebenwirkung pausieren, die anstehende Aktion exakt speichern, die Entscheidung des Prüfers protokollieren und vom persistierten Zustand aus fortfahren. Genehmigungen sollten ablaufen oder nach wesentlichen Zustandsänderungen neu validiert werden.
5. Bewahren Sie Nachweise über die Ergebnisse auf. Laufzeit-Traces erklären, was der Agent versucht hat; Aufzeichnungssysteme belegen, was tatsächlich geschehen ist.
6. Wandeln Sie bewährte Verfahren in wiederverwendbare Artefakte um. Fähigkeiten, Richtlinien, Agentendefinitionen und Evaluierungen sollten versioniert werden, anstatt in kopierten Prompts zu existieren.
7. Belassen Sie die geschäftliche Verantwortung außerhalb des Modells. Menschliche Verantwortliche und maßgebliche Systeme entscheiden weiterhin darüber, was wichtig ist, was erlaubt ist und was als Erfolg gilt.

Ein konkreter Kontrollpfad: Die Bearbeitung einer Rückerstattung

Stellen Sie sich einen Support-Agenten vor, der die get_order und process_refund Tools aus der TrueForge-Dokumentation verwendet. Ein produktiver Pfad beginnt mit der Persistierung der Kundenanfrage, der Sitzung und des Identitätskontexts. Der Agent kann die Bestellung zwar über das MCP-Gateway abrufen, doch die Erreichbarkeit des Tools ist nur die erste Prüfung: Die Anwendung oder das Bestellsystem muss dennoch bestätigen, dass dieser Kunde – oder der Dienst, der im Namen des Kunden handelt – auf diese Bestellung zugreifen darf und dass die Bestellung für eine Rückerstattung infrage kommt.

Wenn das Modell process_refundvorschlägt, sollte die Laufzeitumgebung vor jeder Änderung eine ausstehende Aktion erstellen. Dieser Datensatz sollte die Genehmigung an die exakte Bestellung, den Betrag, den Grund, die Vorgangs-ID sowie die relevante Richtlinie oder Datenversion binden. Ein Prüfer genehmigt diese spezifische Aktion, nicht das Tool im Abstrakten und nicht jeden zukünftigen Argumentsatz. Wenn sich die Bestellung während der Pause des Prozesses wesentlich ändert, sollte die Aktion neu validiert oder erneut zur Genehmigung vorgelegt werden.

Nach der Genehmigung kann TrueForge die verkettete Sitzung aus dem persistenten Status fortsetzen. Die ändernde Anfrage sollte einen Idempotenz-Schlüssel oder eine eindeutige Vorgangs-ID enthalten. Wenn die Verbindung unterbrochen wird, sollte das System nicht von einem Fehler ausgehen und die Rückerstattung blind wiederholen; stattdessen sollte es den Vorgang mit dem maßgeblichen Bestell- oder Zahlungssystem abgleichen und erst dann erneut versuchen, wenn das aufgezeichnete Ergebnis dies zulässt. Diese Unterscheidung trennt der Agent hat beschlossen, eine Rückerstattung zu versuchen, der Tool-Aufruf wurde abgesetzt, und die Rückerstattung wurde tatsächlich durchgeführt.

TrueForge-Ereignisse und Gateway-Traces können den Vorschlag, die Richtlinienprüfungen, die Genehmigung, den Aufruf, die Antwort, die Latenz und die Kosten miteinander verknüpfen. Der Beleg des maßgeblichen Systems bleibt der verbindliche Nachweis für das Ergebnis. Evaluatoren können dann mit dem zusammengeführten Datensatz arbeiten – für Offline-Regressionssets, Trajektorien- oder Aufgabenerfolgsprüfungen sowie für die Überwachung der Ergebnisse nach der Bereitstellung –, ohne dabei so zu tun, als würde das Tracing an sich bereits Qualität garantieren. Der Wert der Plattform liegt in der Kohärenz dieser Grenzen: Laufzeitstatus, Modellrichtlinien, Tool-Richtlinien, Identität, Genehmigung und Nachweise bleiben miteinander verbunden, während die geschäftliche Autorisierung und die endgültige Wahrheit beim Domänensystem verbleiben.

9. Der tiefere Punkt: Agentische KI ist ein Problem organisatorischer Systeme

Der Ausdruck „von der Einführung zur Agentik“ ist nützlich, da er einen echten Wandel in der Verantwortung markiert. Wenn KI ein Werkzeug ist, erledigt der Mensch die Arbeit und die KI unterstützt ihn. Wenn KI agentisch wird, wird ein Teil der Arbeit an ein System delegiert, das Zwischenschritte wählen und mit externen Funktionen interagieren kann.

Deshalb darf die Architektur für Unternehmensagenten nicht bei der Modellauswahl stehen bleiben. Das Unternehmen benötigt eine Laufzeitumgebung für die delegierte Arbeit sowie Steuerungsebenen für die Ressourcen, auf die diese Arbeit zugreifen kann.

TrueForge ist das Open-Source-Agenten-Framework von TrueFoundry für diese Laufzeitschicht. AI Gateway, MCP Gateway, Agent Registry, und Skills Registry bieten gemeinsame Kontrolle und Wiederverwendungsmöglichkeiten für Modelle, Tools, Agenten und prozedurales Wissen. Nichts davon ersetzt das unternehmerische Urteilsvermögen. Zusammen bilden sie die Infrastruktur, um Richtlinien zu kodieren, Zugriffe durchzusetzen, Ausführungsnachweise zu sichern und das Verhalten von Agenten im Laufe der Zeit zu verbessern.

Referenzen

1. HBS Working Knowledge – Wie Führung in einer Welt der agentenbasierten KI aussieht.
2. HBS Working Knowledge – Menschen sind weitgehend damit einverstanden, dass KI viele Aufgaben übernimmt – bis zu einem gewissen Punkt.
3. HBS Working Knowledge – Wenn KI Teil des Teams wird, entstehen bessere Ideen.
4. Organization Science – Der kybernetische Teamkollege: Ein Feldexperiment zu generativer KI und Teamarbeit.
5. HBS Working Knowledge – Wer sollte Bankkredite genehmigen: Menschen oder Algorithmen?.
6. PNAS Nexus – Öffentliche Einstellungen zur Leistung von algorithmischen und menschlichen Entscheidungsträgern.
7. HBS Working Knowledge – Erfolg mit KI beginnt bei der „Talentdichte“.
8. TrueForge – Einführung.
9. TrueForge – SDK-Konzepte.
10. TrueForge – Sandbox.
11. TrueFoundry – Einführung in das AI Gateway.
12. TrueFoundry – MCP Gateway.
13. TrueFoundry – Authentifizierung und Sicherheit für das MCP Gateway.
14. TrueFoundry – Agentenidentität (Beta).
15. TrueFoundry – Agenten-Registry.
16. TrueFoundry – Skills-Registry.

Redaktioneller Hinweis: Die Harvard Business School, HBS Working Knowledge und die genannten Dozenten stehen in keiner Verbindung zu diesem Artikel und unterstützen TrueFoundry nicht. Die Forschung der HBS dient als externer Rahmen; alle Produktzuordnungen und Schlussfolgerungen zur Infrastruktur sind redaktionelle Analysen von TrueFoundry. Die Produktfunktionen werden auf Basis der öffentlich zugänglichen Dokumentation mit Stand vom 1. September 2026 beschrieben.

‍