Agentische KI im Unternehmen: die Plattform

TL;DR

Agentische KI ist ein Modell, das in mehreren Schritten eigenständig Werkzeuge aufruft, statt eine Antwort zu schreiben. Im Unternehmen braucht das vier Bausteine: einen Harness für die Agentenschleife, ein Gateway für Identität und Residenz, einen Tool-Layer über Ihre Systeme und Observability. Anthropic liefert die ersten zwei inzwischen selbst.

Was unterscheidet agentische KI von einem Chatbot?

Agentische KI unterscheidet sich in drei Punkten: das Modell entscheidet selbst über die nächsten Schritte, es ruft Werkzeuge auf und liest deren Ergebnisse, und es läuft über Minuten oder Stunden statt über eine Antwort. Ein Chatbot bekommt einen Prompt und liefert Text. Ein Agent bekommt ein Ziel und arbeitet daran, bis es erreicht ist oder er abbricht.

Diese drei Unterschiede erzeugen die Betriebsanforderungen. Eine Schleife, die Werkzeuge aufruft, braucht einen Ort, an dem sie laufen darf. Werkzeuge, die auf Ihre Systeme zugreifen, brauchen eine Freigabe. Lange Läufe brauchen Zustand, Unterbrechbarkeit und Kostenkontrolle. Nichts davon löst ein Prompt.

Eigenschaft	Chatbot	Agent
Steuerung	Nutzer gibt jeden Schritt vor	Modell entscheidet die Schritte
Werkzeuge	Keine oder ein Suchaufruf	Dateisystem, Shell, APIs, MCP-Server
Laufzeit	Sekunden	Minuten bis Stunden
Zustand	Gesprächsverlauf	Verlauf plus Dateisystem plus Zwischenergebnisse
Kostenverhalten	Vorhersehbar pro Nachricht	Skaliert mit Schritten und Parallelität
Risiko	Falsche Antwort	Falsche Antwort plus falsche Aktion

Die letzte Zeile ist der Grund, warum Agenten eine Plattform brauchen und kein Projekt. Ein falscher Satz ist peinlich. Ein falscher Schreibzugriff auf ein Quellsystem ist ein Vorfall.

Was muss eine Plattform für agentische KI liefern?

Eine Plattform liefert vier Dinge, die ein Anwendungsteam nicht wiederholt bauen kann: einen Ort für lange Agentenschleifen, eine Identitäts- und Routing-Schicht, die durchsetzt wer welches Modell wo aufrufen darf, einen kontrollierten Tool- und Connector-Layer und Observability pro Nutzer. Alles andere ist Anwendungscode.

Der Grund zu zentralisieren ist nicht Eleganz. Jeder der vier Bausteine hat eine Compliance-Folge, und zehn Teams, die sie einzeln lösen, erzeugen zehn Antworten auf die Frage, wo Prompts verarbeitet werden. Zentralisieren Sie die Compliance-Fläche und lassen Sie die Teams ihre Agenten besitzen.

Baustein	Was er besitzt	Bauen, kaufen oder konfigurieren
Harness	Agentenschleife, Werkzeugausführung, Sandboxes, Sitzungszustand	Kaufen oder konfigurieren, Anthropic liefert einen
Gateway	Identität, Modellzugriff je Gruppe, Routing, Residenz	Konfigurieren, eine unterstützte Komponente existiert
Tool-Layer	Zugriff auf Ihre Systeme über MCP und APIs	Selbst bauen, das kann niemand sonst
Observability	Tokens, Kosten, Traces, Bewertung pro Nutzer	Konfigurieren, vorhandenen Stack nutzen

Harness: Agentenschleife selbst bauen oder Claude Managed Agents?

Nutzen Sie den verwalteten Harness, solange Sie nicht die Schleife selbst kontrollieren müssen oder eine Datenschutzlage brauchen, die er nicht erfüllt. Claude Managed Agents liefert Harness und Laufzeitumgebung, also lautet die Frage nicht mehr “Schleife bauen oder Messages-API direkt”.

Der verwaltete Harness steht auf vier Begriffen: ein Agent (Modell, System-Prompt, Werkzeuge, MCP-Server, Skills), ein Environment (wo Sitzungen laufen), eine Session (eine laufende Instanz an einer Aufgabe) und Events (Nachrichten zwischen Ihrer Anwendung und dem Agenten). Sitzungen sind zustandsbehaftet angelegt, setzen nach Pausen fort und halten Gesprächsverlauf und Sandbox-Zustand serverseitig. Eingebaute Werkzeuge decken Bash, Dateioperationen, Websuche und Abruf mit Domain-Allowlist oder Blocklist sowie MCP-Server ab. Geplante Deployments führen Agenten per Cron aus.

Zwei Fakten entscheiden, ob das in einen europäischen Einsatz passt. Erstens kann das Environment eine selbst gehostete Sandbox auf Ihrer Infrastruktur sein, und genau diese Option nennt Anthropic für Compliance- und Residenzanforderungen: Werkzeugausführung und Sandbox-Dateisystem bleiben bei Ihnen, während angehängte Memory-Stores bei Anthropic gespeichert bleiben und für die Sitzung in Ihre Sandbox kopiert werden. Zweitens ist Managed Agents wegen der Zustandsbehaftung derzeit weder für Zero Data Retention noch für eine HIPAA-Vereinbarung geeignet. Sitzungen und hochgeladene Dateien lassen sich über die API löschen, die Eignungslücke ist aber strukturell und keine Einstellung.

Unsere Empfehlung:

Ihre Randbedingung	Harness-Wahl
Lange Läufe, keine ZDR-Anforderung	Claude Managed Agents mit Cloud-Sandbox
Werkzeugausführung muss auf Ihrer Infrastruktur bleiben	Claude Managed Agents mit selbst gehosteter Sandbox
Zero Data Retention ist vertraglich zugesagt	Auf der Messages-API bauen, Zustand selbst halten
Sie müssen Schleife, Wiederholungen und Werkzeugverteilung steuern	Messages-API oder Agent SDK
Agenten sind entwicklerseitig, in IDE und CLI	Claude Code mit Subagenten, kein eigener Harness

Die Beta läuft hinter dem Header managed-agents-2026-04-01, ist für API-Konten standardmäßig aktiv, und MCP-Tunnel sowie Dreaming stecken in einer engeren Research Preview. Rechnen Sie damit, dass sich die Schnittstelle bewegt. Unser Leitfaden zum Claude Agent SDK in der EU behandelt den Selbstbau-Weg auf Bedrock und Google Cloud.

Gateway: was verlangt die Identitäts- und Residenzschicht?

Am Gateway hören Residenz und Identität auf, Richtlinie zu sein, und werden Konfiguration. Für Organisationen, die Inferenz über den eigenen Cloud-Anbieter führen müssen, ist der Claude apps gateway das unterstützte Muster, und seine Voraussetzungen sind präzise genug, dass sie vor allem anderen in das Plattformdesign gehören.

Was es ist: ein selbst gehostetes einzelnes Linux-Binary vor Amazon Bedrock, Claude Platform on AWS, Google Cloud oder Microsoft Foundry, das Entwickelnde gegen Ihren Identitätsanbieter anmeldet, Modellzugriff je Gruppe durchsetzt und OpenTelemetry-Metriken mit Token-Zahlen, Modell, Nutzeridentität und Latenz liefert, Logs und Traces als Opt-in je Ziel.

Was es verlangt, und jede Zeile hat irgendwo einen Rollout blockiert:

1. Claude Code v2.1.195 oder neuer auf dem Gateway-Server und jedem Entwicklerrechner. Der Upstream Claude Platform on AWS braucht v2.1.198 oder neuer auf dem Server, die Claude-Desktop-Anbindung v2.1.203 oder neuer.
2. Einen OIDC-Identitätsanbieter. Okta, Microsoft Entra ID, Google Workspace, Keycloak, Dex oder jeden anderen OIDC-konformen Anbieter. SAML und LDAP werden nicht unterstützt, was erstaunlich viele gewachsene Identitätslandschaften ohne Brücke ausschließt.
3. PostgreSQL 11 oder neuer für den Device-Anmeldefluss und die Ratenlimit-Zähler, mit dauerhaften Ausgaben-, Audit- und Identitätstabellen, sobald Ausgabengrenzen aktiv sind. Sichern Sie die Datenbank.
4. Eine private Netzadresse. Bei der Anmeldung verlangt Claude Code, dass der Gateway-Hostname nur auf private Adressen auflöst: RFC 1918, Link-Local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 oder Loopback. Wer intern aus eigenem öffentlichem Adressraum nummeriert, muss diese Blöcke ausdrücklich deklarieren.

Zwei Designfolgen ergeben sich sofort. Der Start ist fail-closed für Konfiguration, Postgres-Verbindung, OIDC-Discovery und Upstream-Aufbau, also bricht das Gateway ab statt degradiert zu bedienen. Das ist richtiges Verhalten und macht das Gateway zu einer Produktionsabhängigkeit mit den Verfügbarkeitsanforderungen einer solchen. Und einen Service-Token-Fluss für unbeaufsichtigte Pipelines gibt es nicht: die Anmeldung läuft immer über den Browser-Device-Flow, also authentifizieren CI-Jobs direkt beim Cloud-Anbieter, und die Gateway-Einstellungen bleiben von CI-Runnern fern.

Die Eigenschaft der Datenebene, die Sie Betriebsrat und Datenschutz zeigen können: das Gateway sendet aus eigener Datenebene nichts an Anthropic-Infrastruktur, solange die Anthropic-API nicht als Upstream konfiguriert ist. Telemetrie, Audit-Logs, Managed Settings und die Identität der Entwickelnden bleiben, wo Sie sie hinlegen.

Eine Abwägung treffen Sie bewusst: Gateway-Sitzungen holen die servergesteuerten Einstellungen aus der claude.ai-Administration nicht, also kommt die Richtlinie aus dem eigenen Managed-Block des Gateways. Sie bekommen Residenz- und Anbieterkontrolle und geben einen Teil der Enterprise-Funktionen ab. Unser Leitfaden zum LiteLLM-Gateway für die EU behandelt die Mehr-Anbieter-Alternative.

Wo wird die Residenz tatsächlich entschieden?

Die Residenz wird von der Route entschieden, nicht von einer Einstellung auf der Plattform. Auf der First-Party-API akzeptiert inference_geo nur "global" und "us", und Workspace-Geo kennt nur "us" und ist nach dem Anlegen fest. Auf Amazon Bedrock und bei den von Google betriebenen Claude-Modellen gilt inference_geo gar nicht: dort bestimmen Endpunkt-URL oder Inferenzprofil die Region.

Diese Asymmetrie treibt die meisten EU-Plattformarchitekturen. Lautet die Anforderung Verarbeitung in einer EU-Region, führt die Plattform über einen regionalen Endpunkt auf einer Partnerplattform, und Gateway oder Anwendung wählt ihn. Die Seite zur Datenresidenz nennt den Rest: US-Inferenz kostet bei Claude 4.6 und neueren Modellen Faktor 1,1, allowed_inference_geos und default_inference_geo setzen eine Richtlinie über alle Schlüssel eines Workspace durch, und Ratenlimits sind über alle Geos geteilt.

Vier Prüfschritte gehören in das Runbook der Plattform und nicht in ein Dokument:

1. Konfigurierte Geo je Workspace nach jeder Änderung prüfen, denn ein neuer Workspace erbt die Einstellung nicht.
2. Endpunkt oder Inferenzprofil je Region auf den Cloud-Routen prüfen, denn das entscheidet, wo Inferenz läuft.
3. Das Antwortfeld usage.inference_geo in die Telemetrie schreiben, damit Sie nachträglich belegen können, wo eine Anfrage lief.
4. Nach jedem Modellgenerationswechsel erneut prüfen, weil inference_geo nur von Claude 4.6 und neuer unterstützt wird und ältere Modelle mit 400 antworten.

Unser Leitfaden zur Claude-Datenresidenz behandelt die Einstellungen je Route im Detail.

Was kostet der Betrieb?

Drei Kostenpositionen: Tokens, der Parallelitätsfaktor und die Infrastruktur der Plattform selbst. Tokens folgen veröffentlichten Tarifen. Die Parallelität ist die Position, die überrascht. Die Infrastruktur ist vergleichsweise klein und oft die einzige, die im Plan steht.

Token-Tarife von der Preisseite: Sonnet 5.5 zu 2 USD Input und 10 USD Output je Million mit Cache-Treffern zu 0,10 USD, Opus 5.5 zu 4 USD und 20 USD mit Cache-Treffern zu 0,20 USD, und 10 Prozent Aufschlag für regionale oder Multi-Region-Endpunkte. Agentische Lasten sind von Natur aus cache-lastig, weil System-Prompt, Werkzeugdefinitionen und Skill-Inhalte sich wiederholen, also zählt der Cache-Tarif hier mehr als in einer Chat-Last.

Die Parallelität unterscheidet agentische Plattformen von allem anderen. Agent-Teams in Claude Code verbrauchen im Planungsmodus etwa siebenmal mehr Tokens als normale Sitzungen, weil jedes Teammitglied ein eigenes Kontextfenster trägt. Dieselbe Rechnung gilt für jedes Fan-out-Muster, das Sie bauen: Gleichzeitigkeit vervielfacht Kontext, und Kontext ist der Kostenblock. Entwerfen Sie das Fan-out mit einem Budget, statt es zu entdecken.

Kostenposition	Treiber	Steuerung
Tokens im Normalbetrieb	Kontextgröße pro Schritt, Anzahl Schritte	Prompt-Caching, kleinere Modelle für Teilschritte
Tokens im Fan-out	Anzahl paralleler Agenten	Gleichzeitigkeit begrenzen, Haiku oder Sonnet für Worker
Residenzaufschlag	Regionale Endpunkte	Nur die Lasten dorthin, die es brauchen
Gateway-Infrastruktur	Ein Linux-Host plus verwaltetes PostgreSQL	Kleinste Datenbankstufe genügt
Observability	OTLP-Volumen	Traces stichprobenartig, Metriken vollständig

Unser Leitfaden zu den Claude-API-Kosten in der EU hält die Tarifzahlen je Route, und unser Leitfaden zum Selbsthosten von Langfuse behandelt die Observability-Schicht in der EU.

Selbst bauen oder auslagern?

Bauen Sie den Tool-Layer selbst und konfigurieren Sie den Rest. Harness und Gateway sind inzwischen Produkte mit dokumentierten Voraussetzungen, also liegt der Engineering-Wert in den MCP-Servern und APIs, die Ihre eigenen Systeme sicher freigeben. Genau das kann eine externe Partei schlecht, weil es Wissen darüber braucht, welche Felder in Ihren Systemen gefährlich sind.

Arbeitspaket	Aufwand	Bauen oder kaufen
Harness-Auswahl und erster Agent	10 bis 15 Tage	Konfigurieren
Gateway mit Identitätsanbieter in Betrieb nehmen	10 bis 20 Tage	Guter Auslagerungskandidat
MCP-Server über interne Systeme	15 bis 30 Tage je System	Im Haus bauen
Observability-Pipeline und Bewertungsrahmen	15 bis 25 Tage	Gemischt
Runbook zur Residenzprüfung	5 Tage	Im Haus bauen
Modellwechsel und Regressionstests	5 Tage je Generation	Im Haus, regelmäßig

Unsere Einschätzung: das Gateway ist der beste Auslagerungskandidat auf dieser Liste, weil die Voraussetzungen präzise sind, die Fehlerzustände fail-closed und die Konfiguration des Identitätsanbieters ein Team beim ersten Mal zwei Wochen kostet. Der MCP-Tool-Layer ist der schlechteste, weil eine externe Partei die API freigibt, die leicht aufzurufen ist, und nicht die, die sicher aufzurufen ist. Unser Leitfaden zu Claude MCP im Unternehmen behandelt Freigabe- und Sicherheitsmodell dieser Schicht.

Was Sie von einer bezahlten Plattformarbeit verlangen sollten:

1. Eine Harness-Entscheidung mit genannter Zero-Data-Retention-Folge, nicht aufgeschoben.
2. Die Residenzroute benannt, mit automatisierter Prüfung statt Dokumentation.
3. Ein Gleichzeitigkeitsbudget für jedes Fan-out-Muster, mit gezeigtem Faktor.
4. Zuordnung pro Nutzer im Betrieb, auch auf den Cloud-Routen, wo die Anthropic-Dashboards nichts sehen.
5. Den Tool-Layer als Code in Ihrem Repository, mit ausdrücklich ausgeschlossenen gefährlichen Operationen.

Eine Plattform für Mitarbeitenden-Chat ist ein anderer Bau: unser Leitfaden zur internen KI-Plattform behandelt LibreChat und Open WebUI auf Bedrock, und unser LLMOps-Leitfaden das Betriebsmodell um beides.

Ein Agent, der unter Ihrer Marke Kunden erreicht, stellt eine Frage, die eine interne Plattform nicht stellt: ob Sie damit zum Anbieter dieses Systems nach dem AI Act geworden sind. Unser Leitfaden zur KI-Kennzeichnungspflicht behandelt die drei Auslöser und die Offenlegung ab der ersten Interaktion.

FAQ

Was ist agentische KI?

Agentische KI ist ein Modell, das ein Ziel bekommt, selbst über die nächsten Schritte entscheidet, dabei Werkzeuge aufruft und deren Ergebnisse liest, und über Minuten oder Stunden daran arbeitet. Ein Chatbot bekommt dagegen einen Prompt und liefert eine Antwort. Der Unterschied erzeugt die Anforderungen an Laufzeit, Freigaben und Kostenkontrolle.

Was ist eine Plattform für agentische KI?

Die gemeinsame Schicht, die mehreren Teams erlaubt, Claude-Agenten zu betreiben, ohne dieselben Probleme einzeln zu lösen: ein Harness für lange Agentenschleifen, ein Gateway für Identität und Modell-Routing, ein kontrollierter Tool-Layer über interne Systeme und Observability pro Nutzer. Die Teams besitzen ihre Agenten, die Plattform die Compliance-Fläche.

Claude Managed Agents oder eigene Schleife?

Claude Managed Agents für lange und asynchrone Lasten, solange Sie nicht Zero Data Retention oder Kontrolle über die Schleife brauchen. Es liefert Harness, Sandboxes, Sitzungszustand und geplante Deployments und unterstützt selbst gehostete Sandboxes, wenn Werkzeugausführung auf Ihrer Infrastruktur bleiben muss. Es ist in der Beta und weder ZDR- noch HIPAA-fähig.

Was verlangt der Claude apps gateway?

Claude Code v2.1.195 oder neuer auf Server und allen Clients, einen OIDC-Identitätsanbieter (SAML und LDAP werden nicht unterstützt), PostgreSQL 11 oder neuer und einen Hostnamen, der nur auf private Adressen auflöst. Der Start ist fail-closed, und es gibt keinen Service-Token-Fluss, also authentifiziert CI direkt beim Cloud-Anbieter.

Kann eine agentische Plattform die Inferenz in der EU halten?

Ja, über regionale Endpunkte auf Amazon Bedrock, Google Cloud oder Microsoft Foundry, wo Endpunkt oder Inferenzprofil die Region bestimmen. Die First-Party-API bietet für Inferenz nur "global" und "us" und für Workspace-Geo nur "us", also kommt EU-Verarbeitung von den Partnerplattformen.

Was kostet der Betrieb einer agentischen Plattform?

Tokens dominieren: Sonnet 5.5 zu 2 USD Input und 10 USD Output je Million, Opus 5.5 zu 4 USD und 20 USD, plus 10 Prozent für regionale Endpunkte. Die Position zum Planen ist der Parallelitätsfaktor, denn Fan-out vervielfacht Kontext, und Agent-Teams in Claude Code verbrauchen im Planungsmodus etwa siebenmal mehr Tokens als normale Sitzungen.

Quellen

1. Anthropic: Claude Managed Agents (28. Oktober 2026)
2. Claude Code: Claude apps gateway (28. Oktober 2026)
3. Anthropic: Data residency (28. Oktober 2026)
4. Anthropic: Modell- und Feature-Preise (28. Oktober 2026)
5. Claude Code: Kosten steuern (28. Oktober 2026)
6. Anthropic Support: Was ist der Enterprise-Plan (28. Oktober 2026)