Das Modell ist nicht das Problem. Der Code drum herum ist es.

Jedes Mal, wenn ein Kunde zu uns kommt und frustriert über seinen KI-Agenten ist, verläuft die Konversation gleich. Sie haben das Modell schon zweimal gewechselt, vielleicht dreimal. Von GPT-4o zu Claude, von Claude zu Gemini, wieder zurück. Der Agent funktioniert immer noch nicht richtig. Sie wollen wissen, welches Modell sie als Nächstes versuchen sollten.

Die Antwort lautet fast immer. gar keines. Das Modell ist nicht das Problem.

Ob ein Agent in der Produktion tatsächlich funktioniert, entscheidet die Infrastruktur, die man drumherum baut. Die Tools, die er aufrufen kann. Der Speicher, auf den er zugreifen kann. Die Berechtigungen, die definieren, was er anfassen darf. Versaut man das, wird kein Model-Upgrade dich retten. Macht man es richtig, schlägt sogar ein mittelmäßiges Modell ein Frontier-Modell auf einer schwachen Grundlage.

Das ist keine Randbemerkung. Das ist, wo ernst zu nehmende KI-Entwicklung das ganze letzte Jahr über angekommen ist. Und es hat echte Konsequenzen dafür, wie Agenturen, Produktteams und Gründer ihre Zeit einteilen sollten.

Was die Infrastruktur tatsächlich macht

Ein KI-Agent ist kein Modell. Es ist ein System. Das Modell ist eine Komponente in einer größeren Architektur, die Tool-Definitionen, Speicherplätze, Abruf-Mechanismen, Orchestrierungs-Logik und Berechtigungsebenen umfasst. Jede dieser Komponenten prägt, was der Agent tun kann, stärker als die Modellgewichte selbst.

Nimm Werkzeugzugriff. Ein Modell hat keine Fähigkeit, auf die Welt einzuwirken, es sei denn, man gibt ihm Tools: APIs, die es aufrufen kann, Datenbanken, die es abfragen kann, Services, in die es schreiben kann. Die Qualität dieser Tool-Definitionen, wie klar sie beschreiben, was ein Tool tut und wann man es einsetzt, beeinflusst direkt, ob das Modell sie korrekt durchdenkt. Eine vage Tool-Beschreibung führt zu falschen Tool-Aufrufen. Eine präzise führt zu zuverlässigem Verhalten. Das Modell hat sich nicht geändert. Die Schnittstelle hat sich geändert.

Bei Memory ist es die gleiche Geschichte. Die meisten Agent-Ausfälle in der Praxis sind keine Reasoning-Fehler. Sie sind Kontext-Fehler. Der Agent hatte keinen Zugriff auf die richtige Information zum richtigen Zeitpunkt. Ob das einen gut strukturierten Vector Store, einen Kurzzeitspeicher oder eine Zusammenfassung früherer Gesprächsschritte bedeutet, die Architektur des Speichers entscheidet darüber, was das Modell wissen kann, wenn es das wissen muss. Ein GPT-3.5-Modell mit exzellentem Abruf schlägt ein Frontier-Modell, das blind operiert.

Berechtigungen sind das, worüber die Leute am wenigsten sprechen und am häufigsten etwas falsch machen. Was kann der Agent lesen? Was kann er schreiben? Was erfordert menschliche Bestätigung? Diese Grenzen sind nicht nur Sicherheitsbarrieren, sie sind funktionales Design. Ein Agent, der ohne Kontrollpunkt in die Produktion schreiben kann, ist kein mächtiger Agent. Er ist ein Risiko. Ein Agent mit gut durchdachten Berechtigungsgates ist einer, den man tatsächlich einsetzen kann.

Wo Agenturen das falsch gemacht haben

Die Agenturwelt hat eine besondere Variante dieses Problems. Es gibt einen kommerziellen Anreiz, mit dem Modell zu starten, weil Modelle Namen haben, Benchmarks und Pressemitteilungen. Einem Kunden zu sagen, dass man Claude 3.5 Sonnet oder GPT-4o nutzt, signalisiert etwas. Ihm zu sagen, dass man drei Wochen in Retrieval-Architektur und Permission-Schema-Design investiert hat, ist schwerer in ein Proposal zu packen.

Also machen es die meisten Agenturen nicht. Sie setzen ein fähiges Modell auf eine dünne Infrastruktur auf, zeigen eine Demo, die unter kontrollierten Bedingungen funktioniert, und übergeben sie. Der Kunde führt sie dann in der echten Welt aus, wo die Eingaben messier sind und der Kontext reicher und mehrdeutiger ist, und das Ding bricht.

Die Lösung ist nie, das Modell zu wechseln. Die Lösung ist, zurückzugehen und die Infrastruktur neu zu gestalten. Aber zu diesem Zeitpunkt ist die Beziehung angespannt und das Budget aufgebraucht.

Bei Studio Hyra haben wir bewusst beschlossen, das umzukehren. Bevor wir die Modellauswahl anfassen, kartografieren wir die operative Ebene: Welche Tools braucht dieser Agent, welche Memory-Architektur passt zum Use Case, wo müssen Menschen im Loop bleiben. Die Modellauswahl kommt danach. Sie ist fast immer der einfachste Teil des Projekts.

Drei Dinge, die Agent-Performance wirklich voranbringen

Tool-Schema-Design. Das JSON-Schema, das du für jedes Tool schreibst, ist ein Prompt in Verkleidung. Wenn das Description-Feld vage ist, wird das Modell danebentreffen. Schreib Tool-Beschreibungen so, als würdest du das Tool einer intelligenten Juniorin erklären, die keine Nachfragen stellen kann. Schreib auf, was das Tool tut, was es nicht tut, und wann man es einem ähnlichen Tool vorzieht. Das allein eliminiert eine große Kategorie von Agent-Fehlern.

Retrieval vor Generation. Für jeden Agent, der in einem wissensintensiven Bereich operiert, verdient der Retrieval-Schritt so viel Aufmerksamkeit wie der Generation-Schritt. Chunking-Strategie, Embedding-Modellwahl, Reranking, Metadaten-Filterung: diese Entscheidungen verstärken sich. Eine Retrieval-Pipeline, die das richtige Dokument 90% der Zeit findet, produziert einen dramatisch anderen Agent als eine, die 60% trifft, egal welches Generation-Modell dahinter sitzt.

Explizite menschliche Kontrollpunkte. Agenten, die unbegrenzt handeln können, erwecken kein Vertrauen. Sie produzieren Unbehagen, und das zu Recht. Wenn man explizite Bestätigungspunkte designt, an denen der Agent innehält und einen Menschen fragt, bevor er schreibt, löscht oder sendet, wird aus einem unvorhersehbaren System ein vertrauenswürdiges. Das Ziel ist nicht Automatisierung um ihrer selbst willen. Das Ziel ist zuverlässige Ergebnisse. Manchmal heißt das, der Agent stoppt und wartet.

Was das für deine Zeiteinteiling bedeutet

Wenn du ein KI-Produkt baust oder Agenten in einen Workflow integrierst, ist die praktische Folgerung direkt: Hör auf, Modell-Leaderboards zu prüfen, und fang an, deine Infrastruktur zu prüfen.

Frag, wo dein Agent in der Produktion ausfällt. In den meisten Fällen wirst du eins von drei Dingen finden: Er hat das falsche Tool aufgerufen, weil das Schema mehrdeutig war; er hat eine veraltete oder irrelevante Antwort gegeben, weil der Retrieval-Schritt danebengegriffen hat; oder er hat etwas getan, das er nicht hätte tun sollen, weil die Berechtigungsebene unterspecifiziert war.

Keiner dieser Fehler wird durch ein besseres Modell behoben. Alle werden durch besseres Engineering behoben.

Das ist eigentlich gute Nachricht. Modell-Fähigkeiten sind größtenteils außerhalb deiner Kontrolle. Du nimmst, was die Labs dir geben, und die Labs updaten nach eigenem Plan. Die Infrastruktur liegt ganz in deiner Hand. Dort zeigt sich Handwerk. Dort entscheidet sich, ob ein Agent, der sich gut präsentiert, oder einer, der zuverlässig in der Produktion läuft, gemacht oder verloren wird.

Frontier-Modelle sind beeindruckend. Aber der fähigste Agent, den wir dieses Jahr gebaut haben, läuft auf einem Modell, das nicht das neueste oder größte ist. Er läuft auf einer Infrastruktur, die vier Wochen brauchte, um richtig zu werden. Das ist die Arbeit.

Der Wechsel, der sich lohnt

Die Branchen-Konversation um KI-Agenten bewegt sich langsam in diese Richtung. Infrastruktur-Unternehmen bauen bessere Tooling-Primitive. Evaluation-Frameworks reifen. Memory und Retrieval werden zu erkannten Disziplinen, nicht zu Nachgedanken.

Für Builder, die in der Model-Swapping-Schleife festsitzen, ist die Umrahmung simpel: Behandel das Modell als Commodity-Input und die Infrastruktur als Produkt. Da sitzt die Differenzierung. Da lohnt sich deine Zeit.

Wenn du durchsprechen willst, wie das für einen bestimmten Use Case aussieht, findest du uns leicht.