Über die Modelle, die hinter Sprach-KI stehen, wird viel geschrieben. Sie werden im Quartalstakt besser, austauschbar und günstiger. Was darüber selten gesagt wird: Ob ein KI-Agent im Betrieb einer Firma zuverlässig arbeitet oder stillschweigend Schaden anrichtet, entscheidet fast nie das Modell. Es entscheidet die Architektur darum herum. Genau dort liegt das, was wir gebaut haben, und dieser Beitrag zeigt es offen, mit Diagrammen, einem fairen Vergleich und zwei nachrechenbaren Modellen.
Der Betrieb als Schichtmodell, nicht als ein Programm
Die These: das Modell ist austauschbar, die Architektur nicht
Ein Sprachmodell allein ist ein Ratgeber ohne Gedächtnis und ohne Hände. Es beantwortet, was man es fragt, und vergisst es danach. Ein Agent, der wirklich Aufgaben übernimmt, braucht mehr: er muss sich erinnern, was gestern geschah, mehrere Zuständigkeiten trennen, ohne sich selbst in die Quere zu kommen, prüfen, ob sein eigenes Ergebnis stimmt, und bei allem, was Geld kostet oder nach außen geht, an der richtigen Stelle innehalten. Das sind keine Eigenschaften eines Modells. Das sind Eigenschaften eines Systems.
Wir setzen auf ein führendes kommerzielles Sprachmodell auf und tauschen es aus, wenn ein besseres kommt. Der Wert liegt in den Schichten darum herum, und die gehören uns. Das ist auch der Grund, warum diese Architektur nicht veraltet, wenn nächstes Jahr ein neues Modell erscheint.
Fünf Schichten, eine Verantwortungskette
Der Betrieb ist in fünf Schichten aufgebaut. Jede löst genau ein Problem, das eine Schicht darunter nicht lösen kann. Von unten nach oben:
Jede Schicht löst ein Problem, das die darunter offen lässt
Der Punkt ist die Reihenfolge. Ein System, das erst das Modell nimmt und dann Werkzeuge dranhängt, aber die Schichten drei bis fünf auslässt, ist genau das System, das in der Praxis scheitert. Und das ist die Mehrheit.
Woran autonome Agenten in der Praxis scheitern
Die Fehler sind nicht spektakulär, sondern leise, und genau deshalb teuer. Vier Muster kommen immer wieder vor.
Vergesslichkeit. Ein Agent ohne belastbares Gedächtnis beginnt jede Sitzung bei null. Er fragt Dinge zweimal, widerspricht seiner eigenen Auskunft von gestern und trifft Entscheidungen ohne den Zusammenhang, der sie erst richtig macht. Ein Recall-Schritt vor jeder Antwort ist die Gegenmaßnahme, nicht ein größeres Kontextfenster.
Kollisionen. Sobald mehrere Läufe dieselben Ressourcen anfassen, etwa ein Bankkonto, können zwei gleichzeitig dieselbe Zahlung auslösen. Ohne Koordination ist das kein hypothetisches Risiko, sondern eine Frage der Zeit, wie die erste der beiden Rechnungen weiter unten zeigt.
Ungeprüfte Ausgaben. Ein Modell, das eine Aufgabe für erledigt erklärt, hat sie nicht geprüft. Ob eine Datei wirklich geschrieben, eine Nachricht wirklich versendet, ein Betrag wirklich angekommen ist, muss ein eigener Schritt bestätigen. Wer der Erfolgsmeldung des Modells glaubt, baut auf Sand.
Lieferketten-Risiko. Viele Frameworks beziehen Fähigkeiten aus offenen Marktplätzen. Für den bekanntesten Agenten-Marktplatz haben Sicherheitsforscher 2026 dokumentiert, dass ein zweistelliger Prozentsatz der veröffentlichten Erweiterungen bösartig war, von Zugangsdaten-Dieben bis zu untergeschobenen Anweisungen, bei niedriger Hürde zum Veröffentlichen. Ein Agent mit Zugriff auf Konten und Postfächer darf solchen Code nicht ungeprüft laden. Wir laden ihn gar nicht.
Der Vergleich
Nüchtern und an Architektur-Eigenschaften entlang, nicht an erfundenen Messwerten. Verglichen wird unser Betrieb mit einem verbreiteten Open-Source-Agenten-Framework und mit der Gruppe der generischen Baukästen, mit denen Teams Agenten selbst zusammensetzen.
| Eigenschaft | Unser Betrieb | OpenClaw | Generische Baukästen |
|---|---|---|---|
| Dauerhaftes Gedächtnis mit Recall vor jeder Antwort | fest eingebaut | Speicher vorhanden, Recall nicht erzwungen | Sache des Entwicklers |
| Schutz gegen gleichzeitiges Doppelhandeln | Sperre und gemeinsames Brett | nicht vorgesehen | selbst zu bauen |
| Verifikation als eigener Pflichtschritt | vor jeder Erfolgsmeldung | optional | optional |
| Menschliche Freigabe vor Unumkehrbarem | an festen Toren | je nach Konfiguration | selbst zu verdrahten |
| Werkzeugzugriff über offenen Standard | durchgängig | ja | teils |
| Lieferketten-Vertrauen | kein Fremdcode aus Marktplätzen | Marktplatz mit belegten Vorfällen | abhängig von den Paketen |
| Lückenlose Protokollierung jeder Geldbewegung | Standard | nicht durchgängig | selbst zu bauen |
Architektur-Eigenschaften, keine Messwerte
Kein Baustein hier ist Zauberei. Jeder ließe sich in jedem Framework nachbauen. Der Unterschied ist, dass sie bei uns von Anfang an zusammengehören und keine Option sind, die man vergessen kann.
Zwei Rechnungen, offen als Modell
Die folgenden Zahlen sind keine gemessenen Benchmarks, sondern durchgerechnete Modelle mit offengelegten Annahmen. Sie zeigen die Größenordnung, um die es geht, und jeder kann sie nachrechnen.
1 · Warum Koordination kein Luxus ist
Angenommen, mehrere Läufe am Tag fassen dasselbe Bankkonto an, jeder belegt es für rund drei Minuten, verteilt über ein aktives Fenster von sechzehn Stunden. Die Wahrscheinlichkeit, dass sich an einem Tag mindestens zwei überschneiden und damit doppelt handeln könnten, steigt mit ihrer Zahl schnell an.
Zahlen ansehen
| Läufe/Tag | ohne | mit |
|---|---|---|
| 4 | 3,7 % | 0 % |
| 6 | 9,0 % | 0 % |
| 8 | 16,1 % | 0 % |
| 11 | 29,2 % | 0 % |
| 14 | 43,5 % | 0 % |
Bei elf Läufen am Tag, wie sie in einem realen Betrieb vorkommen, liegt die Wahrscheinlichkeit einer Überschneidung an einem einzelnen Tag schon bei rund dreißig Prozent. Über einen Monat gerechnet ist eine Kollision damit nahezu sicher. Das gemeinsame Brett drückt diese Kurve auf die Nulllinie, weil nie zwei Läufe zugleich zugreifen können. Das ist der Unterschied zwischen einer Doppelzahlung, die irgendwann passiert, und einer, die nicht passieren kann.
2 · Warum Verifikation die Fehlerquote bricht
Angenommen, ein autonomer Arbeitsschritt liefert in zehn Prozent der Fälle ein Ergebnis, das falsch ist, ohne dass es sofort auffällt. Ein unabhängiger Prüfschritt fängt einen Teil davon ab. Was durchrutscht, ist das Produkt aus beidem.
Zahlen ansehen
| Prüf-Trefferquote | Restfehler |
|---|---|
| 0 % | 10 % |
| 50 % | 5 % |
| 80 % | 2 % |
| 95 % | 0,5 % |
Der Effekt ist unscheinbar und entscheidend zugleich. Eine Prüfung, die auch nur vier von fünf stillen Fehlern fängt, senkt die durchrutschende Quote von zehn auf zwei Prozent. Deshalb ist Verifikation bei uns kein optionaler Feinschliff, sondern ein eigener Pflichtschritt vor jeder Erfolgsmeldung.
Ein besseres Modell macht die einzelne Antwort klüger. Erst die Architektur macht aus vielen Antworten einen Betrieb, dem man Konten und Postfächer anvertrauen kann.
Was das für einen Kunden bedeutet
Der Unterschied ist nicht akademisch. Wer einen Agenten einsetzt, der nur aus Modell und Werkzeugen besteht, bekommt eine beeindruckende Demonstration und ein unkalkulierbares Risiko. Wer die fünf Schichten hat, bekommt einen Betrieb, der sich erinnert, sich nicht selbst in die Quere kommt, seine eigenen Ergebnisse prüft und bei allem Kritischen auf ein menschliches Ja wartet.
Genau diese Architektur bauen wir, und genau sie bieten wir an: nicht ein Modell zum Ausprobieren, sondern einen Betrieb, der Verantwortung tragen kann. Wie die offenen Protokolle unter der Werkzeugschicht dafür die Grundlage bilden, steht im Beitrag zum Agenten-Protokoll-Stack. Warum Leitplanken über den Nutzen entscheiden, im Beitrag zu Guardrails, und wie oft autonome Läufe ohne sie in der Praxis abbrechen, im Beitrag zu den Abbruchquoten.