NAME
agentic-infrastructure-stack — Die Agenten-Infrastruktur und das neue Backend
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
Wir haben oft über Agenten-Frameworks gesprochen. LangGraph, CrewAI, AutoGen, verschiedene SDKs, Schleife, Tool-Aufruf, Speicher, Planer, Kritiker, Supervisor. Alles nützliche Worte, um Himmels willen. Aber je mehr ich mir die tatsächlich eingesetzten Mittel ansehe, desto mehr kommt es mir so vor, als sei der interessante Teil unter die Rahmenebene gewandert.
Die Frage ist nicht mehr nur: Welche Bibliothek verwende ich, um ein Stufenmodell zum Nachdenken zu bringen?
Die eigentliche Frage ist: Wo lebt dieser Agent, wenn er aufhört, ein Demo zu sein?
Denn ein seriöser Agent ist keine Funktion, die ein Modell aufruft und Text zurückgibt. Es ist ein kleines verteiltes System. Es muss den Kontext lesen, Tools verwenden, Code ausführen, Dateien berühren, sich Entscheidungen merken, um Erlaubnis bitten, ordnungsgemäß fehlschlagen, neu starten, Protokolle hinterlassen, darf das Budget nicht verbrennen und darf sich nicht in einen Bulldozer innerhalb des Produktions-Repositorys verwandeln.
Das Gerüst ist das Lenkrad. Die Infrastruktur besteht aus der Straße, den Bremsen, der Garage, der Versicherung und der Person, die weiß, wo die Schlüssel sind.
Weil jetzt viel darüber geredet wird
In den Jahren 2023 und 2024 war das Gespräch sehr modellzentriert. Welches LLM? Wie viel Kontext? Wie viel kostet es? Wie gut kann er programmieren?
In den Jahren 2025 und 2026 hat sich das Gespräch verlagert. Die Modelle sind gut genug, um echte Arbeit zu leisten, aber deshalb werden die langweiligen Teile sichtbar: Laufzeit, Sicherheit, Konnektoren, Identität, Beobachtbarkeit, Codeausführung, Bereitstellung, Rollback.
Es ist der natürliche Übergang von der Magie zur Technik.
Wenn ein Agent nur eine Antwort generieren muss, reicht ein Chat. Wenn Sie eine Pull-Anfrage öffnen, eine Datenbank abfragen, ein CRM aufrufen, einen Job starten, auf einer Website navigieren, Slack lesen, Code kompilieren und ein Dokument aktualisieren müssen, benötigen Sie ein Betriebssystem dafür.
Nicht im wörtlichen Sinne. Im organisatorischen Sinne.
Das erste Stück: eine Laufzeit, in der der Agent bestehen bleiben kann
Ein Agent arbeitet oft in Schritten. Schauen Sie sich den Zustand an, wählen Sie eine Aktion, verwenden Sie ein Werkzeug, beobachten Sie das Ergebnis, aktualisieren Sie den Plan, wiederholen Sie den Vorgang.
Wenn sich diese Schleife innerhalb einer einzelnen HTTP-Anfrage befindet, liegt sofort ein Problem vor. Einige Aktionen sind langsam. Einige warten auf menschliche Eingaben. Einige scheitern und müssen erneut versucht werden. Einige müssen eine Bereitstellung oder einen Timeout überstehen.
Hier kommen dauerhafte Arbeitsabläufe, Warteschlangen, Jobhintergründe und Zustandsautomaten ins Spiel. Sie sind nicht gerade glamourös, aber sie machen den Unterschied zwischen einem Agenten, der bei einer Vorführung schlau wirkt, und einem Agenten aus, den man arbeiten lassen kann, während man Kaffee trinken geht.
Für mich muss die Agentenlaufzeit ganz konkrete Fragen beantworten:
- Wo speichere ich den Zustand zwischen einem Schritt und dem anderen?
- Was passiert, wenn der Prozess mittendrin abbricht?
- Kann ich innehalten und um Genehmigung bitten? – Kann ich einen Lauf noch einmal abspielen, um zu verstehen, warum er diese Entscheidung getroffen hat?
- Kann ich Dauer, Speicher, Tools und Kosten begrenzen?
Vercel treibt diesen Bereich mit KI-SDKs, Funktionen, Workflows und Tools zum Erstellen von Agenten in Webanwendungen stark voran. Aber es geht nicht nur um Vercel. Der Punkt ist, dass der Agent ein betriebsbereites Zuhause und keinen einzelnen Endpunkt benötigt.
Der zweite Teil: Sandbox, da der Agent in der Lage sein muss, schmutzig zu werden, ohne kaputt zu gehen
Sobald ein Agent Code schreibt oder Befehle ausführt, wird eine Sandbox benötigt.
Es scheint ein technisches Wort zu sein, aber die Idee ist häuslicher Natur: Man gibt ihm eine Werkbank. Es kann Dateien öffnen, Abhängigkeiten installieren, Tests ausführen, Experimente durchführen und Ausgaben generieren. Wenn er etwas falsch macht, haben Sie den Schaden eingedämmt. Wenn es funktioniert, fördern Sie das Ergebnis.
An agentic sandbox should have some properties:
- isoliertes Dateisystem;
- CPU-, Speicher- und Zeitlimits;
- kontrolliertes Netzwerk;
- Geheimnisse werden nur bei Bedarf montiert;
- vollständige Protokolle;
- Möglichkeit zum Exportieren von Artefakten;
- Sauberes Zurücksetzen zwischen den Läufen, falls erforderlich.
Vercel Sandbox geht genau in diese Richtung: isolierte Umgebungen zum Ausführen von Code, zum Installieren von Abhängigkeiten, zum Arbeiten mit Dateien und zum Erstellen von Artefakten, ohne alles in der Hauptanwendungslaufzeit auszuführen.
Diese Sache ist wichtiger als es scheint. Viele Agentenprototypen springen direkt vom Modell zum realen System. Das Modell kann ein Werkzeug aufrufen. Werkzeuge können Dinge tun. Es scheint alles elegant, bis der erste falsche Befehl, die erste Abhängigkeit am falschen Ort installiert und das erste Token in einem Protokoll landet.
Der Sandkasten ist die erwachsene Art zu sagen: Mach weiter, aber hier drin.
Der dritte Teil: MCP und das Steckerproblem
Das Model Context Protocol ist zu einem der interessantesten Teile des Ökosystems geworden, weil es versucht, etwas zu standardisieren, was sonst schnell unüberschaubar wird: wie ein Modell externe Tools entdeckt und nutzt.
Ohne einen Standard ist jede Integration eine kleine Insel. Ein Connector für GitHub auf die eine Art, einer für Slack auf eine andere Art, einer für Datenbanken mit unterschiedlicher Semantik, einer für die Browser-Automatisierung, der wie nichts aussieht.
MCP schlägt eine gemeinsame Sprache zwischen Client und Server vor: Tools, Ressourcen, Eingabeaufforderungen, Autorisierungen, Transport, Erkennung. Es löst Governance und Sicherheit nicht auf magische Weise, aber es gibt eine Grammatik.
Und Grammatik ist wichtig. Wenn ein Agent eine Verbindung zu vielen Tools herstellen kann, stellt sich nicht nur die Frage: „Kann er das?“ Das Problem ist: „Versteht er, was er tun kann, mit welchen Grenzen, für wen und welche Spuren hinterlässt?“
Für mich ist MCP kein Hype, weil es „Tool-Calling“ durchführt. Das haben wir bereits gemacht. Es ist ein Hype, weil es den Schwerpunkt von der Einzelintegration auf den operativen Werkzeugkatalog verlagert.
In einer guten Agentenarchitektur wird MCP zu einer Art Patchpanel:
- GitHub für Code und Probleme;
- Nachlässigkeit für den Konversationskontext;
- Linear oder Jira für geplante Arbeiten;
- schreibgeschützte Datenbank für Analysen;
- Browser- oder Scraper-gesteuert für externe Websites;
- Dokumentenspeicherung;
- isolierte Ausführungsumgebungen;
- Interne Systeme mit strengen Berechtigungen offengelegt.
Das Knifflige daran ist, dass ein richtlinienfreier Werkzeugkatalog nur eine elegantere Möglichkeit ist, Chaos zu stiften.
Das vierte Stück: Identität und Berechtigungen
Dies ist der Bereich, in dem viele Demos die Augen verschließen.
Ein Agent handelt im Namen einer Person. Es muss also klar sein, wer Gegenstand der Klage ist.
Verwendet es Benutzerberechtigungen? Von einem Dienstkonto? Von einem Arbeitsplatz? Haben Sie temporären oder dauerhaften Zugang? Können Sie alles oder nur einige Ressourcen lesen? Kannst du schreiben? Können Sie stornieren? Kann er echten Menschen eine SMS schicken?
Wenn Sie diese Fragen nicht gut beantworten, werden Sie früher oder später zu einem Assistenten mit Hausschlüsseln und ohne Erinnerung daran, wer sie ihm gegeben hat.
Die Faustregel, die mir gefällt, ist diese: Der Agent muss in der Lage sein, weniger zu tun als der Mensch, nicht mehr als der Mensch. Und wenn er etwas Riskanteres tun muss, muss er innehalten und nachfragen.
Dies bedeutet OAuth, tokenbezogen, Geheimnisverwaltung, Prüfprotokoll, Tool-Richtlinie, Zulassungsliste, Genehmigungsschritt. Nicht sehr romantisches Zeug. Notwendiges Zeug.
Das fünfte Stück: Erinnerung und Kontext, aber ohne Müll anzusammeln
Agenten brauchen Gedächtnis, aber Gedächtnis ist gefährlich, wenn es zum Dachboden wird.
Es gibt mindestens drei Arten von Gedächtnis:
- Speicher ausführen: Was ist bei dieser Ausführung passiert?
- Projektgedächtnis: Konventionen, Entscheidungen, Zwänge;
- persönliches oder Teamgedächtnis: Vorlieben, Ton, Rituale, Prozesse.
Alles in die Eingabeaufforderung einzufügen ist die Abkürzung. Es funktioniert, bis es nicht mehr funktioniert. Der nützliche Speicher muss gepflegt werden: indiziert, aktualisiert, abgelaufen, überprüft, zitierfähig gemacht.
Ein Agent, der sich schlecht erinnert, ist schlimmer als ein Agent, der sich nicht erinnert. Weil er selbstbewusst spricht.
Daher muss die Infrastruktur Abruf, Anleitungsdateien, Wissensdatenbank, Einbettung bei Bedarf, aber auch Reinigung umfassen. Wir brauchen eine Erinnerungskultur: Was kommt herein, wer genehmigt es, wann verfällt es, wie korrigiere ich es.
Das sechste Stück: Beobachtbarkeit, Bewertung und Wiedergabe
Wenn ein Agent einen Fehler macht, reicht das „Called the Model“-Protokoll nicht aus.
Sie möchten die Route sehen. Welchen Kontext erhielt er? Welche Tools standen zur Verfügung? Für welches Tool haben Sie sich entschieden? Mit welchen Argumenten? Welche Antwort haben Sie bekommen? Wie viel hat es gekostet? Wo ist es hängengeblieben? Hat der Mensch irgendetwas gutgeheißen? Handelt es sich bei dem Fehler um einen Modell-, Tool-, Eingabeaufforderungs-, Daten- oder Berechtigungsfehler?
Hier ähneln die Agenten eher verteilten Systemen als Chatbots.
Sie benötigen lesbare Spuren, nicht nur Textprotokolle. Sie müssen in der Lage sein, einen Lauf erneut abzuspielen. Es ist notwendig, zwei Versionen desselben Agenten hinsichtlich bekannter Aufgaben zu vergleichen. Wir müssen Regressionen messen: Sie antworten nicht nur besser, sondern schließen auch das richtige Ticket, ohne unerwünschte Dateien zu berühren.
Agentische Auswertungen sind schwieriger als Textauswertungen, da sie Aktionen beinhalten. Es reicht nicht aus, eine erwartete Zeichenfolge zu vergleichen. Man muss Abläufe, Nebenwirkungen, Qualität des Artefakts, Zeit, Kosten und Anzahl menschlicher Eingriffe berücksichtigen.
Das Lustige ist, wir kommen immer wieder dorthin zurück: Software-Engineering. Tests, Umgebungen, Traces, Rollbacks. Nur dass der Code jetzt auch darüber entscheidet, was als nächstes zu tun ist.
Das siebte Stück: Human Interfaces
Der Agent muss nicht nur in einem Chat leben.
Manche Agenten benötigen ein Board. Andere eine Seite mit Status und Protokoll. Andere von einer „Genehmigen“-Schaltfläche. Weitere Inline-Kommentare. Wieder andere einer CLI.
Die Benutzeroberfläche ändert das Verhalten. Wenn die einzige Möglichkeit, einen Agenten zu kontrollieren, darin besteht, eine lange Nachricht zu schreiben, wird der Benutzer dem Agenten vage Anweisungen geben. Wenn er jedoch Plan, Unterschiede, Quellen, Risiken und nächste Maßnahmen erkennt, kann er gezielt eingreifen.
Zu einer anständigen Agenten-Infrastruktur gehören Kontrolloberflächen:
- aktueller Status;
- bearbeitbarer Plan;
- hergestellte Artefakte;
- diff;
- Genehmigungsanfragen;
- Chronologie;
- Stopptaste;
- Schaltfläche „Wiederholen“;
- sichtbare Berechtigungen.
Es scheint trivial, ist es aber nicht. Der Unterschied zwischen „gruseliger KI“ und „zuverlässigem Assistenten“ besteht oft nur darin, dass letzterer einem zeigt, wo er in der Lage ist.
Der mentale Stapel
Wenn ich es heute zeichnen würde, wäre der minimale Agentenstapel dieser:
- Modell: Argumentation, Generierung, Werkzeugaufruf, ggf. multimodal.
- Orchestrierung: Schleife, Schritt, Planer, Richtlinie, Human-in-the-Loop.
- Dauerhafte Laufzeit: Workflow, Warteschlange, Wiederholung, Pause, Fortsetzen.
- Sandbox: Codeausführung, isoliertes Dateisystem, Einschränkungen, Artefakte.
- Tool-Schicht: MCP, interne API, Browser, Datenbank, Repository.
- Identitätsschicht: OAuth, Umfang, Geheimnis, Audit, Richtlinie.
- Speicherschicht: Projektkontext, Abruf, Anweisungen, Ablauf.
- Beobachtbarkeit: Trace-, Replay-, Evaluierungs-, Kosten- und Qualitätsmetriken.
- Produktoberfläche: Chatten Sie bei Bedarf, Dashboard bei Bedarf, überprüfen Sie, wenn es darauf ankommt.
Das Agenten-Framework deckt hauptsächlich Punkt 2 und einen Teil von Punkt 1 ab. Der Rest ist die eigentliche Arbeit.
Was ich in der Praxis tun würde
Wenn mir ein Team sagen würde: „Wir wollen Agenten in der Produktion“, würde ich nicht mit zehn Agenten beginnen.
Ich würde mit einem kleinen, sich wiederholenden und beobachtbaren Arbeitsablauf beginnen. Zum Beispiel: Wartungs-PRs öffnen, Dokumentation von geschlossenen Problemen aktualisieren, eine wöchentliche Überprüfung vorbereiten, doppelte Fehler selektieren, Tests für betroffene Dateien erstellen.
Dann würde ich ganz klare Grenzen setzen:
- kein Schreiben ohne Zweige oder Sandkasten;
- keine Geheimnisse in der Eingabeaufforderung;
- Werkzeuge in der Zulassungsliste;
- menschliche Zustimmung zu externen Handlungen;
- obligatorische Protokollierung und Rückverfolgung;
- Budget pro Lauf;
- Ausgabe immer überprüfbar.
Erst dann würde ich expandieren.
Agenten scheitern nicht, nur weil die Models etwas falsch machen. Sie scheitern, weil wir sie in vage Umgebungen mit verwirrenden Berechtigungen und theatralischen Erwartungen bringen.
Meine Lektüre
Agentische Infrastruktur ist im besten Sinne langweilig.
Es ist nicht der Teil, der einen in der Demo zum Klatschen bringt. Es ist der Teil, der es Ihnen ermöglicht, die Demo am Montagmorgen tatsächlich zu nutzen, mit echten Menschen, echten Daten und echten Konsequenzen.
Die Zukunft der Agenten wird nicht nur davon entschieden, wer das beste Vorbild hat. Es wird von demjenigen entschieden, der den besten Ort schafft, an dem er arbeiten kann: isoliert, wenn er experimentiert, verbunden, wenn es nötig ist, immer beobachtbar, mit Kriterien autorisiert und bescheiden genug, um aufzuhören, wenn er es nicht weiß.
Hier hören Agenten auf, ein Spielzeug zu sein, und werden zur Infrastruktur.
Quellen
METADATA
- date: 2026-06-30
- reading: 10 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel