Agenten sind die neue Architektur — was Google verschweigt: drei Dinge, die KMU vorher fixen müssen

Google Cloud Next 2026 hat letzte Woche eine Keynote-Folie hingestellt, die seitdem auf jedem zweiten LinkedIn-Profil landet: „Agents are the architecture now." Klingt visionär. Wir hören diesen Satz auch von Kunden, seit AWS und Microsoft mit gleichlautenden Folien hinterherziehen. Das Problem: Wer als Mittelständler darauf einsteigt und einen Agenten auf seine Produktivdaten loslässt, ohne vorher drei Foundations zu klären, fliegt blind. Wir sehen das gerade live, weil wir genau diese Foundations bei mehreren Kunden aufgebaut haben. Hier sind die drei Dinge, die in keiner Keynote stehen.

Was Google sagt — und was es weglässt

Die Botschaft der großen Cloud-Anbieter ist 2026 einheitlich: Agentic AI ist die nächste Architekturstufe. Statt monolithischer Anwendungen baut man Pipelines aus spezialisierten Agenten, die selbständig Tools nutzen, Sub-Aufgaben verteilen und Ergebnisse aggregieren. Vertex, Bedrock und Foundry liefern dafür die Runtime, das Identity-Backbone und die Marketplace-Anbindung.

Das ist nicht falsch. Es ist nur unvollständig.

Was die Keynotes auslassen: In dem Moment, in dem dein Agent das erste Mal echte Daten anfasst — eine Rechnung schreibt, ein Ticket kommentiert, einen Vertrag liest — wechselst du vom Prototypen-Modus in den Compliance-Modus. Und dort gelten andere Regeln. Du brauchst Antworten auf drei Fragen, die in keiner Demo gestellt werden:

• Wer hat diesen Agenten gerade aufgerufen, und mit welcher Befugnis?
• Was hat dieser Agent in den letzten 24 Stunden tatsächlich gemacht, und was hat das gekostet?
• Welche Tools darf dieser Agent in welchem Kontext nutzen — und welche nicht?

Wir nennen das die drei Foundations. Ohne sie ist „Agents are the architecture" eine Folie. Mit ihnen ist es eine Produktivumgebung.

Foundation 1: Inbound-Auth mit kurzlebigen JWTs und Scopes

Die häufigste Architektur, die wir 2026 in der Wildbahn sehen, sieht so aus: Ein Agent läuft als Cloud-Service. Wer ihn aufruft, schickt einen API-Key im Header. Der API-Key ist seit zwölf Monaten unverändert, steht in drei verschiedenen Repos und einem Slack-Channel. Wer den Key hat, ist „der Agent" — egal ob es das Marketing-Team ist, ein externer Berater oder der Hauspraktikant.

Das funktioniert für einen Prototyp. Für eine Produktivumgebung ist es eine Zeitbombe. Was du stattdessen brauchst:

• Kurzlebige Tokens. Jeder Aufruf gegen deinen Agenten kommt mit einem JWT, das maximal eine Stunde gültig ist. Idealerweise ausgestellt vom selben Identity-Provider, der auch deine Mitarbeiter authentifiziert.
• Explizite Scopes. Im Token steht, was der Aufrufer darf: nur lesen, nur in Projekt X, nur bestimmte Aktionen. Der Agent prüft den Scope, bevor er irgendetwas tut.
• Audit pro Aufruf. Wer hat wann mit welchem Scope welchen Agenten aufgerufen — das gehört in ein zentrales Log, nicht in eine CloudWatch-Ecke, die niemand liest.

Konkret: Wir nutzen für die Identity-Schicht einen Cognito-Pool, der per Client-Credentials-Flow kurzlebige JWTs ausstellt. Jeder unserer Agenten verlangt einen gültigen Token, prüft den Scope (`agents/invoke`) und routet den Aufruf erst dann an die Logik. Das klingt nach Standard-OAuth — und genau das ist es. Aber wir sehen Kunden, die nach drei Monaten Agent-Betrieb noch immer mit statischen Bearer-Tokens arbeiten. Wenn so ein Token leakt, ist nicht ein Account kompromittiert, sondern die gesamte Agenten-Pipeline.

Foundation 2: End-to-End-Tracing mit Cost- und Token-Attribution

Beobachtbarkeit von Agenten ist kein Logging-Problem. Es ist ein Tracing-Problem. Der Unterschied: Logs erzählen dir, dass etwas passiert ist. Traces erzählen dir, warum, in welcher Reihenfolge, von wem ausgelöst und zu welchen Kosten.

Was ein Agent in der Praxis tut, ist nie ein einzelner LLM-Aufruf. Ein typischer Workflow sieht so aus:

1. Inbound-Aufruf vom Webhook eines SaaS-Tools (zum Beispiel ein neues Ticket im Projektmanagement-System).
2. Triage-Agent klassifiziert das Ticket — ein LLM-Call, vielleicht 800 Tokens Input, 200 Tokens Output.
3. Triage-Agent ruft das CRM-Tool auf, um Kundenkontext zu laden — zwei Tool-Calls, vielleicht 1.500 zusätzliche Tokens.
4. Triage-Agent eskaliert an einen Spezial-Agenten — der wiederum zwei eigene LLM-Calls macht.
5. Finale Antwort wird als Kommentar im Ticket gepostet — ein weiterer Tool-Call.

Das ist ein Ticket. Multipliziert mit hundert Tickets am Tag, sind das fünfhundert LLM-Calls, dreihundert Tool-Calls und ein vierstelliger Token-Verbrauch. Wenn du diese Kette nicht durchgängig tracest, kannst du drei kritische Fragen nicht beantworten:

• Welcher Agent verursacht 80 Prozent meiner Bedrock-Rechnung?
• Welcher Schritt in welcher Pipeline halluziniert am häufigsten?
• Wenn ein Kunde sich beschwert: was hat der Agent ihm wirklich geantwortet, und auf welcher Grundlage?

Konkret arbeiten wir mit einer zentralen Tracing-Plattform, an der jeder LLM-Call, jeder Tool-Call und jeder Agent-Hop hängt. Wir taggen jeden Trace mit Projekt, Kunde, Agent-Version und Modell-Identifier. Damit sehen wir nicht nur, dass etwas teuer wurde — wir sehen, welche Agent-Version, in welchem Kunden-Projekt, an welchem Wochentag. Das ist die Grundlage für Eval-Pipelines, Kostenkontrolle und das ehrliche Gespräch mit dem Kunden über Pricing.

Foundation 3: Fein-granulare Policies — „Tool X in Projekt Y"

Die meisten Agent-Frameworks haben ein binäres Berechtigungsmodell: ein Agent hat Zugriff auf ein Tool, oder er hat keinen. Das ist 2026 zu grob. Was du in der Praxis brauchst, sind Aussagen wie:

• „Der Support-Agent darf Tickets in Projekt A lesen und kommentieren, in Projekt B nur lesen, in Projekt C gar nicht."
• „Der DevOps-Agent darf in Repository X pushen, aber nur auf Branches, die mit `agent/` beginnen."
• „Der Verifier-Agent darf das CRM lesen, aber keine personenbezogenen Datenfelder zurückgeben."

Das ist keine theoretische Spielerei. Sobald du mehrere Agenten in mehreren Kundenprojekten betreibst, brauchst du diese Granularität. Sonst hast du genau zwei Optionen: zu restriktiv (der Agent kann nichts und ist nutzlos) oder zu permissiv (der Agent kann alles, und der erste Fehlgriff kostet dich einen Kunden).

Wir nutzen für diese Schicht eine Policy-Engine, die Regeln als deklarative Statements formuliert — separat vom Agent-Code. Damit kann ich eine Policy ändern, ohne den Agenten neu zu deployen. Audit, Code-Review und Rollback sind sauber getrennt.

Praktischer Nebeneffekt: Wenn ein Kunde fragt, was unser Agent in seiner Umgebung darf und was nicht, können wir ihm das nicht als Marketing-Slide zeigen, sondern als prüfbares Regelwerk. Das beruhigt Compliance-Verantwortliche deutlich schneller als jede Demo.

Was das für Mittelständler heißt

Es gibt 2026 zwei Wege, mit Agenten zu starten:

1. Der Hype-Weg. Du buchst Vertex oder Bedrock, baust einen Demo-Agenten, zeigst ihn der Geschäftsführung, bekommst Applaus. Du integrierst ihn in dein CRM, dein Ticketsystem, deine Buchhaltung. Sechs Wochen später hast du keinen Überblick mehr, wer was aufruft, was es kostet, und was der Agent in welchem Kontext tun darf. Der erste Vorfall ist eine Frage von Monaten, nicht Jahren.
2. Der Architektur-Weg. Du startest mit denselben Tools, aber baust zuerst die drei Foundations: Inbound-Auth, Tracing, Policies. Erst dann lässt du den ersten Agenten an Produktivdaten. Du wirst zwei Wochen langsamer sein — und sechs Monate später deutlich schneller, weil du keinen einzigen Vorfall aufarbeiten musst.

Wir haben beides bei Kunden gesehen. Der Unterschied ist nicht das Modell, nicht das Framework, nicht die Cloud. Es sind diese drei Foundations.

Drei Schritte für die nächsten 30 Tage

Wenn dein Unternehmen 2026 erste Agenten produktiv setzt, mach diese drei Dinge, bevor irgendein Agent echte Daten sieht:

1. Kläre die Identity-Frage zuerst. Welcher Identity-Provider stellt die Tokens aus? Wie lange leben sie? Welche Scopes brauchst du? Das ist eine Architektur-Entscheidung, keine Implementierungs-Frage.
2. Wähle deine Tracing-Plattform, bevor du den zweiten Agenten baust. Tracing nachzurüsten ist drei Mal so teuer wie es einzubauen. Egal welche Plattform — Hauptsache zentral, Hauptsache mit Cost-Attribution.
3. Schreib deine erste Policy auf, bevor du den ersten Agenten deployest. Auch wenn sie zunächst trivial ist („Dieser Agent darf nur Tool X in Projekt Y nutzen"). Der erste Satz im Policy-Dokument ist wichtiger als der hundertste Prompt-Tweak.

Fazit

„Agents are the architecture now" ist als Slogan richtig. Als Roadmap ist es gefährlich, weil er suggeriert, dass die Plattformen den Rest erledigen. Tun sie nicht.

Identity, Observability und Policy sind keine Detail-Themen, die man nach dem ersten Erfolg nachzieht. Sie sind die Foundations, ohne die jede Agenten-Architektur in den ersten produktiven Wochen kollabiert oder — schlimmer — schleichend Vertrauen verliert.

Wir bauen das gerade live für unsere Kunden, und wir reden ehrlich darüber, weil die Keynote-Slides es nicht tun.