KI-Agenten können planen. Sie können logisch schlussfolgern. Sie können Code schreiben. Aber bitte sie, ein Bild zu generieren, mit Quellenangaben im Web zu suchen, ein Video zu erstellen, Assets in der Cloud zu speichern oder eine Seite zu veröffentlichen – und sie stoßen an eine Wand. Nicht weil das Modell nicht intelligent genug wäre. Sondern weil der Agenten-Architektur eine Ebene fehlt.
Diese fehlende Ebene heißt Capability Runtime.
Wo die KI-Agenten-Architektur heute versagt
Ein moderner KI-Agenten-Stack besteht typischerweise aus drei Ebenen:
- Die Modellebene – Claude, GPT, Gemini. Die Reasoning-Engine.
- Das Agenten-Framework – die Schleife, die plant, Werkzeuge aufruft, beobachtet und iteriert.
- Die Werkzeuge – MCP-Server, APIs, SDKs, die den Agenten handeln lassen.
Die ersten beiden Ebenen sind schnell gereift. Claude Code und Cursor verfügen über ausgefeilte Agenten-Schleifen. Modelle verarbeiten Kontextfenster mit über 200.000 Token.
Die dritte Ebene – die Werkzeuge – ist der Schwachpunkt.
Jedes Werkzeug, das ein Agent benötigt, lebt hinter einer anderen API. Jede API hat ihre eigene Authentifizierung, ihre eigenen Ratenlimits, ihr eigenes SDK, ihr eigenes Ausgabeformat. Um einem einzigen Agenten fünf Fähigkeiten zu geben (Bildgenerierung, Video, Websuche, Speicherung, Veröffentlichung), konfigurierst du fünf separate Dienste, verwaltest sechs API-Schlüssel und verbrennst über 24.000 Token allein für Werkzeugbeschreibungen.
Das ist keine Werkzeugebene. Das ist eine Werkzeuglast.
Was eine Capability Runtime leistet
Eine Capability Runtime ist ein einzelnes CLI-Tool (oder API), das zwischen deinem Agenten und den Dutzenden von Diensten sitzt, die er benötigt. Statt dass dein Agent jeden Dienst direkt anspricht:
Agent → Bild-API → Agent → Video-API → Agent → Such-API → Agent → Speicher-API
Spricht der Agent mit einem einzigen Endpunkt:
Agent → Capability Runtime → (Bild, Video, Suche, Speicher, Veröffentlichung)
Die Runtime übernimmt Modellauswahl, Authentifizierung, Formatkonvertierung, Ratenbegrenzung und strukturierte Ausgabe – der Agent muss sich darum nicht kümmern.
Warum das wichtig ist: Die Token-Mathematik
Das ist keine Abstraktion um der Abstraktion willen. Es hat messbare Auswirkungen auf die Agenten-Performance.
Jeder MCP-Server oder API-Client, mit dem sich dein Agent verbindet, registriert seine Werkzeuge im Kontext des Agenten. Jedes Werkzeug enthält Name, Beschreibung und Parameterschema. Ein einzelner MCP-Server fügt typischerweise 3.000–8.000 Token an Werkzeugbeschreibungen hinzu.
Mit fünf separaten Werkzeugen (Bildgenerierung + Videogenerierung + Websuche + Cloud-Speicher + Veröffentlichung) reden wir von 15.000–40.000 Token, die verbrannt werden, bevor dein Agent eine einzige Codezeile schreibt.
Eine Capability Runtime konsolidiert diese Werkzeuge in einem Endpunkt. Aus fünf Sätzen von Werkzeugbeschreibungen wird einer. Der Token-Overhead sinkt von 24.000+ auf etwa 2.000.
In einer Claude-Sonnet-4-Sitzung mit einem 200K-Kontextfenster werden so 11 % des Kontexts freigegeben – für echtes Reasoning, Codegenerierung und Konversationsverlauf.
Die drei Probleme, die eine Capability Runtime löst
1. Credential-Zersplitterung
Jede einzelne API benötigt ihren eigenen Schlüssel. Fünf Fähigkeiten bedeuten fünf Schlüssel, die erstellt, gespeichert, rotiert und widerrufen werden müssen. Eine Capability Runtime gibt dir eine einzige Anmeldeinformation, die alles abdeckt.
2. Inkonsistente Ausgaben
Eine API liefert JSON. Eine andere liefert Plaintext. Eine weitere streamt Binärdaten. Dein Agent muss jedes Format verarbeiten. Eine Capability Runtime liefert strukturiertes, konsistentes JSON – unabhängig vom zugrunde liegenden Dienst.
3. Wartungsdrift
APIs ändern sich. Ratenlimits verschieben sich. Modelle werden eingestellt. Wenn jede Fähigkeit separat verdrahtet ist, wartest du fünf Konfigurationen. Eine Runtime verarbeitet Aktualisierungen intern – dein Agent ruft einfach weiter denselben Endpunkt auf.
Capability Runtime vs. MCP-Server: Unterschiedliche Ebenen
Hier wird die Terminologie oft verwechselt. MCP-Server (Model Context Protocol) sind eine Transportebene – sie definieren, wie Agenten sich mit Werkzeugen verbinden. Eine Capability Runtime ist eine Bündelungsebene – sie entscheidet, welche Werkzeuge verfügbar sind und wie sie präsentiert werden.
Sie ergänzen sich. Du kannst MCP-Server für spezialisierte Integrationen nutzen (die interne Datenbank deines Unternehmens, einen Slack-Bot, einen Jira-Connector) und eine Capability Runtime für die Standardfähigkeiten, die jeder Agent braucht (Suche, Bild, Video, Speicher, Veröffentlichung).
Der hybride Ansatz sieht so aus:
- Spezialisierte Werkzeuge → einzelne MCP-Server (Datenbank, Slack, CRM)
- Standardfähigkeiten → Capability Runtime (Bild, Video, Suche, Speicher, Veröffentlichung)
Praxisbeispiel: Eine Landing Page erstellen
Ohne Capability Runtime passiert Folgendes, wenn du deinen Agenten bittest, "eine Landing Page für unser neues Feature zu erstellen":
- Agent schreibt HTML/CSS ✅
- Agent benötigt ein Hero-Image – stoppt. Du konfigurierst die Replicate-API, generierst das Bild manuell und gibst die URL zurück an den Agenten.
- Agent benötigt Wettbewerbsrecherche – stoppt. Du konfigurierst Brave Search, führst Suchanfragen aus, fügst Ergebnisse ein.
- Agent erstellt die Seite – fertig. Jetzt deployst du manuell auf Netlify.
- Der Agent hätte die Schritte 2–4 selbst erledigen können, wenn er die Werkzeuge gehabt hätte.
Mit einer Capability Runtime:
- Agent schreibt HTML/CSS ✅
- Agent ruft
image generate "hero für SaaS-Dashboard"auf – erhält eine CDN-URL zurück ✅ - Agent ruft
search "Wettbewerbspreise Q2 2026"auf – erhält zitierte, strukturierte Ergebnisse ✅ - Agent ruft
drive upload ./build/auf – Assets mit öffentlichen URLs gespeichert ✅ - Agent ruft
page deploy ./build/auf – Seite ist live ✅
Eine Sitzung. Ein Agent. Kein menschlicher Engpass.
Worauf man bei einer Capability Runtime achten sollte
Wenn du Capability Runtimes bewertest, sind folgende Punkte entscheidend:
- Breite: Deckt sie die Fähigkeiten ab, die deine Agenten tatsächlich benötigen? Bild, Video, Suche, Speicherung und Veröffentlichung sind die Grundlage.
- Agenten-Kompatibilität: Funktioniert sie mit deinem Agenten? Claude Code, Cursor, Codex, Windsurf, Gemini CLI.
- Ausgabeformat: Strukturiertes JSON. Dein Agent sollte kein HTML parsen oder Binärströme verarbeiten müssen.
- Credential-Modell: Ein Konto, ein Authentifizierungsablauf, ein zu verwaltender Schlüssel.
- Token-Effizienz: Wie viele Token fügt sie deinem Kontext hinzu? Weniger ist besser.
Die fehlende Ebene hat jetzt einen Namen
Dem KI-Agenten-Stack fehlte bisher ein Name für diese Ebene. Man nennt es "Werkzeugintegration" oder "MCP-Konfiguration" oder "API-Verdrahtung". Nichts davon erfasst, was es wirklich ist: eine Runtime, die Agenten Fähigkeiten verleiht, die sie nativ nicht besitzen.
Eine Capability Runtime ist kein Ersatz für MCP. Sie ist kein Ersatz für Modell-APIs. Sie ist die Ebene, die zwischen dem Reasoning deines Agenten und der Welt sitzt, mit der er interagieren muss – und aus "Das kann ich nicht" ein "Erledigt" macht.
Zuletzt aktualisiert: Mai 2026