Agenten entscheiden. Code führt aus. Die Arbeit ist zu wissen, wo die Linie verläuft.

In Vorstandsetagen kursiert ein Satz, der nach Zukunft klingt und sich wie eine Rechnung verhält: Agenten werden Anwendungen ersetzen. Er verdient es, ernst genommen zu werden, denn der Teil, der stimmt, ist wirklich neu, und den Teil, der nicht stimmt, bezahlt derjenige, der darauf baut.

Die nützliche Frage ist nicht, ob man Agenten einsetzt. Sie lautet, wo die Linie zwischen dem verläuft, was ein Agent entscheidet, und dem, was Code ausführt. Ziehen Sie sie an der falschen Stelle, und Sie erhalten ein System, das langsam ist, teuer, nicht prüfbar, und das gelegentlich überzeugt von etwas berichtet, das nie stattgefunden hat.

Was sich wirklich geändert hat

Modelle sind in drei Dingen gut geworden, in denen Software historisch schlecht war: eine von Menschen geschriebene Anweisung lesen, sie in Schritte zerlegen, und für jeden Schritt das richtige Werkzeug wählen. Das ist keine kleine Veränderung. Sie erspart es, jede Formulierung vorwegzunehmen, die jemand wählen könnte, und genau das macht herkömmliche Oberflächen starr.

Nicht geändert hat sich alles, was darunter liegt. Eine Steuerregel bleibt eine Steuerregel. Eine Zahlung wird ausgeführt oder nicht. Eine Rechteprüfung hat eine richtige Antwort und keinen Auslegungsspielraum. Diese Dinge waren nie schwierig, weil sie mühsam zu formulieren gewesen wären. Sie waren schwierig, weil sie jedes Mal exakt stimmen müssen, und das hinterher nachweisbar.

Das Gehirn und das Skelett

Der Vergleich, der den Kontakt mit einem echten Projekt übersteht, ist anatomisch. Das Modell ist das Gehirn: Es versteht, wägt ab und entscheidet. Die Werkzeuge sind die Arme: Sie greifen zu und handeln. Der Code ist das Skelett, und ohne es hat das Gehirn nichts zu bewegen.

Skelette machen keinen Eindruck. Niemand führt eines auf einer Konferenz vor. Aber die Analogie lohnt sich, weil sie den Fehlermodus vorhersagt: Ein System aus Gehirn und Armen ohne Skelett bricht nicht dramatisch zusammen. Es funktioniert in der Vorführung, funktioniert eine Woche, und beginnt dann, plausible und falsche Antworten zu liefern, zu Kosten je Anfrage, die niemand eingeplant hat.

Buche mir einen Flug

Das kanonische Beispiel lohnt den Durchgang, denn die Linie verläuft an einer sehr bestimmten Stelle.

Der Agent soll verstehen, dass eine Reise nach Berlin am nächsten Dienstag bedeutet, nach der Vormittagsbesprechung abzufliegen. Er soll Optionen vergleichen, bemerken, dass zwei gesparte Stunden dreihundert Euro kosten, und fragen, ob dieser Tausch sich lohnt. All das ist Urteil über eine mehrdeutige Anfrage, und genau dafür ist ein Modell da.

Der Agent soll die Karte nicht belasten. Nicht weil dem Modell nicht zu trauen wäre, sondern weil eine Kartenbelastung eine Transaktion ist: Entweder sie geschieht einmal, oder die Buchhaltung ist falsch. Sie braucht Idempotenz, eine Wiederholungsstrategie, einen Rückabwicklungsweg und einen Eintrag, der eine Prüfung übersteht. Nichts davon sind Entscheidungen. Es sind Garantien, und Garantien leben im Code.

Wo die Linie verläuft

Das Muster ist nicht willkürlich. Die linke Spalte ist alles, was bei jedem Durchlauf identisch sein muss, hinterher nachweisbar, und auch dann richtig, wenn die Eingabe seltsam ist. Die rechte ist alles, was davon profitiert, den Kontext zu lesen und zu urteilen.

Alles, was man mit einem Unit-Test absichern möchte, gehört nach links.

Der Fehler, den wir immer wieder sehen

Der häufigste Architekturfehler ist, die Geschäftslogik in den Prompt zu legen. Es funktioniert sofort, und genau das macht es gefährlich.

Die Regeln wandern in den System-Prompt, dann die Ausnahmen, dann die Ausnahmen von den Ausnahmen. Sechs Monate später hat der Prompt viertausend Token, jede Anfrage bezahlt sie alle, und niemand kann mit Sicherheit sagen, was das System bei einer ungewöhnlichen Eingabe tut, weil die Antwort nirgends steht, wo sie sich als Logik lesen ließe. Eine Regel zu ändern riskiert, drei andere zu ändern, und kein Test fängt das ab.

Dieselben Regeln als Code sind bei jeder Anfrage günstiger, in einem Pull Request nachlesbar und testbar. Der Prompt tut dann, was er gut kann: entscheiden, welche dieser Regeln auf diese Situation zutrifft.

Der Agent fasst die Datenbank nie an

Wenn es eine Regel gibt, die aus diesem Artikel bleiben soll, dann diese.

Eine Frage wie „welche Kunden haben keine Sicherung?" soll nicht zu SQL werden, das ein Modell schreibt. Sie soll zu einem Aufruf von etwas werden, das bereits existiert:

# Die API ist der Vertrag. Der Agent entscheidet, sie aufzurufen;
# der Code entscheidet, was das bedeutet und wer fragen darf.
@router.get("/customers/without-backup")
def kunden_ohne_sicherung(user: User = Depends(current_user)):
    if not user.can("read:customers"):
        raise Forbidden()
    return repository.kunden_ohne_sicherung(tenant=user.tenant)

Der Agent wählt das Werkzeug. Der Code setzt durch, wer fragen darf, über welchen Mandanten, und was die Frage bedeutet. Ändert sich das Rechtemodell, ändert sich eine Funktion, und alle Aufrufer erben das, der Agent eingeschlossen.

Andersherum geschrieben, mit einem Modell, das Abfragen gegen die Datenbank erzeugt, lebt das Rechtemodell in einem Prompt, und ein Prompt ist ein Vorschlag.

Es ist dieselbe Grenze, über die wir in dem KI-Assistenten, der nur liest, was der Nutzer lesen darf geschrieben haben: Der Assistent ist nie sicherer als die Schicht darunter.

Wofür MCP da ist

Das Model Context Protocol ist der Teil davon, der sich am schnellsten bewegt hat, und es lohnt sich, genau zu sagen, welches Problem es löst.

Davor sprach jeder Assistent mit jedem Werkzeug auf seine eigene Weise. Ein Modell an ein internes System anzubinden hieß, einen Adapter für dieses Modell zu schreiben, und ihn für das nächste erneut zu schreiben. MCP normiert dieses Gespräch: Das Werkzeug beschreibt, was es kann, und jeder Client, der das Protokoll spricht, kann es nutzen.

Das Repository der Spezifikation wurde im September 2024 öffentlich, die Sammlung der Server folgte im November. Diese Sammlung trägt heute mehr als achtzigtausend Sterne auf GitHub, was weniger über Qualität aussagt als darüber, wie sehr der Standard gefehlt hat.

Architektonisch zählt, dass MCP eine Beschreibungsschicht ist, keine Ausführungsschicht. Es sagt einem Modell, was ein Werkzeug tut und wie man es aufruft. Es macht das Werkzeug nicht sicher, nicht richtig und nicht prüfbar. Das bleibt Eigenschaft dessen, was hinter dem Endpunkt liegt, also Eigenschaft Ihres Codes.

Wo das wirklich hilft

Die ehrliche Fassung des Nutzens ist schmaler als die Werbung und brauchbarer.

Ein Agent verdient seinen Platz dort, wo die Eingabe mehrdeutig und die Handlung begrenzt ist. Die E-Mail eines Lieferanten lesen und vorschlagen, zu welcher Bestellung sie gehört. Die Beschreibung eines Problems in die richtige Abfrage über Systeme verwandeln, die kein gemeinsames Schema haben. Einen Vertrag lesen und die Klauseln markieren, die von der Vorlage abweichen. In jedem Fall ist der schwierige Teil die Deutung, und die Handlung danach läuft durch Code, der identisch liefe, hätte ein Mensch auf die Schaltfläche geklickt.

Er verdient nichts dort, wo die Eingabe bereits strukturiert und die Regeln bereits bekannt sind. Hat ein Formular acht Felder und besteht die Validierung aus einer Liste von Bedingungen, fügt ein Agent Latenz, Kosten und Unsicherheit hinzu und gibt nichts dafür.

Was das für die Architektur bedeutet

Agenten sind eine neue Schicht, kein Ersatz für die darunter. Der Stapel, den wir bauen, sieht aus wie zuvor, mit einer Ergänzung obenauf:

Die API-Schicht ist der Ort, an dem sich das entscheidet. Sie gab es schon vor den Agenten, und wenn sie ordentlich gebaut wurde, braucht sie fast nichts, um sie zu bedienen: Sie weiß bereits, wer fragt, was diese Person sehen darf, und was jede Operation bedeutet.

Das ist der unbequeme Befund für alle, die hoffen, Agenten machten die alte Arbeit überflüssig. Sie machen sie wertvoller. Eine Organisation mit sauberen APIs und einem echten Rechtemodell setzt in Wochen einen Agenten davor. Eine Organisation ohne beides ist nicht langsam, weil ihr Agenten fehlen. Sie ist langsam, weil das Fundament nie gebaut wurde, und ein Modell obendrauf macht das sichtbarer, nicht weniger sichtbar.

Der Teil, der gut altert

Werkzeuge werden sich ändern. Das Modell, das heute in Produktion läuft, wird zweimal ersetzt sein, bevor dies alt ist, und das Protokoll kann ebenfalls ersetzt werden.

Was sich nicht ändern wird, ist die Arbeitsteilung. Das Urteil auf der einen Seite, die Garantien auf der anderen. Systeme, die beides getrennt halten, tauschen das Modell, ohne die Regeln anzufassen, und ändern die Regeln, ohne etwas nachzutrainieren. Systeme, die beides mischen, müssen beides neu bauen, sobald eines von beidem sich bewegt.

Wir schrieben kürzlich, dass die KI die Syntax gelöst hat, das Urteil aber nicht. Dies ist die architektonische Fassung desselben Befunds. Die besten Systeme, die heute mit Agenten gebaut werden, sind nicht die, die ihre Software ersetzt haben. Es sind die, die wussten, welche Hälfte es wert war, behalten zu werden.