Agent = Model + Harness: Warum der production-ready Harness den eigentlichen Unterschied macht
Wenn ein KI-Agent in einer realen Umgebung scheitert, lautet die erste Reaktion fast immer „wir brauchen ein besseres Modell". Das ist die falsche Diagnose. In den allermeisten Fällen liegt das Problem nicht am Modell — es denkt brillant. Das Problem liegt im Harness: der Softwareinfrastruktur rund um das Modell, die es von etwas, das antwortet, in etwas verwandelt, das zuverlässig handelt.
Genau das ist auch die Formel, auf der wir aufbauen:
Agent = Model + Harness
Dasselbe Modell, aber ein besserer Harness — bessere Ergebnisse. Genau hier ist OpenKBS stark: Wir bauen einen production-ready, scalable, secure Harness. Dieser Beitrag erklärt, was das bedeutet, warum es für das Geschäft relevant ist und wie sich die beiden Schichten — das Modell und der Harness — in der Plattform ergänzen.
Was ein Harness eigentlich ist
Wenn das Modell das Gehirn ist, dann ist der Harness der Körper. Das Gehirn kann denken, aber ohne Körper kann es nichts greifen, keine Tür öffnen und das Ergebnis seiner Handlung nicht überprüfen. Der Harness ist alles, was zwischen „das Modell hat entschieden, was zu tun ist" und „die Handlung ist sicher, nachvollziehbar und wiederholbar geschehen" steht:
- die Tools, die das Modell aufrufen kann;
- die isolierte Umgebung (sandbox), in der der Code ausgeführt wird;
- der Speicher und die Ablage, die zwischen Sitzungen erhalten bleiben;
- die feedback loops, die es dem Agenten erlauben, das Ergebnis zu sehen und zu korrigieren;
- guardrails — die Grenzen, die den Agenten daran hindern, Schaden anzurichten;
- die Nachvollziehbarkeit (observability), die jeder Handlung eine Audit-Spur verleiht.
Das Modell allein ist stateless — es nimmt Text entgegen und gibt Text zurück. Alles andere, was einen Agenten in der Produktion nützlich macht, ist der Harness.
Warum die meisten Fehler vom Harness kommen, nicht vom Modell
Das ist die zentrale Erkenntnis: Die meisten operativen Fehler von KI-Agenten kommen vom Harness, nicht vom Modell selbst. Die typischen Symptome haben nichts mit der Intelligenz des Modells zu tun:
- Context rot — der Kontext läuft über oder wird verunreinigt, und das Modell verliert den Faden;
- Tool overload — zu viele, schlecht beschriebene Tools, zwischen denen das Modell den Überblick verliert;
- Fragile Verdrahtung — manuell zusammengesetzte Integrationen, die bei der ersten Änderung brechen;
- Latenz — jeder Schritt durchläuft überflüssige Netzwerk-Hops;
- Irrelevantes Retrieval — der Speicher liefert den falschen Kontext zurück;
- Schwache Verifikation — der Agent prüft das Ergebnis seiner Handlung nicht;
- Fehlende guardrails — nichts stoppt den Agenten, wenn er einen Fehler macht.
Keines dieser Probleme wird durch einen Modellwechsel gelöst. Sie alle werden durch einen besseren Harness gelöst. Deshalb macht ein starker Harness mittelmäßige Modelle nützlich, während ein schwacher Harness selbst die besten verschwendet.
Schicht 1 — Das Modell: Vertrauen durch zero data retention
Wir bauen keine Modelle. Und das ist eine bewusste Entscheidung: Die besten Modelle wechseln alle paar Monate, und an einen einzigen Vendor gebunden zu sein, ist ein strategisches Risiko. Stattdessen bieten wir Zugang zu allen großen Anbietern — OpenAI, Anthropic, Google — über einen einheitlichen AI-Proxy, der in unserer EU-Infrastruktur betrieben wird.
Der Unterschied liegt in den Bedingungen, unter denen das geschieht:
- Zero data retention. Die Anfragen laufen über die Anbieter unter Vereinbarungen zur Null-Datenspeicherung — nichts wird geloggt, nichts wird gespeichert und nichts wird zum Training von Modellen verwendet. Die Daten des Kunden verbleiben nicht beim Anbieter.
- Keine API-Schlüssel zu verwalten. Der Kunde jongliert nicht mit Schlüsseln von OpenAI, Anthropic und Google — der Zugang läuft über eine einzige Kennung und eine einzige Abrechnung in Credits.
- Konsolidierung der Lieferkette. Statt eines separaten Vertrags, einer separaten Risikobewertung und eines separaten Audits für jeden AI-Vendor arbeitet der Kunde mit einem einzigen Anbieter. Für regulierte Branchen ist das ein direkter Vorteil unter NIS2 und AI Act — drastisch weniger zu bewertende Anbieter.
Mit anderen Worten: Modelle bietet jeder an. Wir lösen den Teil, der in einer Enterprise-Umgebung wirklich ins Gewicht fällt — das Vertrauen.
Schicht 2 — Der Harness: hier liegt unsere Stärke
Ein production Harness besteht aus erkennbaren Bausteinen. Die Stärke von OpenKBS liegt darin, dass jeder von ihnen auf einer verwalteten, isolierten und zertifizierten Infrastruktur umgesetzt ist — nicht als manuell zusammengesetzter Prototyp, sondern als Plattform.
| Baustein des Harness | Umsetzung in OpenKBS |
|---|---|
| System prompts / Kontext | Lambda-Funktionen — Kontext und Logik sind Code, versioniert bei jedem Deployment |
| Tools | Project API: Worker, S3, E-Mail, MQTT, Datenbank — fertige Tools, die der Agent aufruft |
| Sandboxes (Isolation) | Lambda-microVM-Isolation + dedizierter AWS-Account pro Kunde + on-demand EC2-Worker für schwere Aufgaben |
| Filesystem | S3-Objektspeicher mit presigned URLs — zeitlich und im Umfang begrenzt |
| Memory (Speicher) | Verwaltetes PostgreSQL (Aurora/Neon), Point-in-time-Restore bis zu 35 Tage, 6 Kopien in 3 Zonen |
| Feedback loops | Agent-Loop in Lambda: tool_use → Ausführung → Beobachtung → Wiederholung und Korrektur |
| Guardrails | Multi-Tenant-Isolation, injizierte Secrets, Credit-Limits, OWASP security audit, AES-256 / TLS 1.2+ |
| Observability | CloudWatch-Logs, Worker-Logs, Usage Collector, administratives Audit-Journal |
| Modellzugang | AI-Proxy — alle Vendor, zero retention, einheitliche Abrechnung, keine Schlüsselverwaltung |
Das ist keine Liste von Ambitionen — das ist die Infrastruktur, die bereits unter jedem Projekt der Plattform liegt. Der Entwickler startet von einem fertigen Harness, statt ihn für jeden Agenten von Grund auf zusammenzubauen.
Scalable von Haus aus
Lambda-Funktionen skalieren automatisch von null bis zu Tausenden gleichzeitiger Ausführungen. Schwere Aufgaben (Videoverarbeitung, ML, Batch) gehen an on-demand Worker mit sekundengenauer Abrechnung. Die Datenbank wählt die richtige Engine je nach Last. Es gibt keine Kapazitätsplanung und keine Server zu warten.
Secure by Design
Jeder Kunde ist auf AWS-Account-Ebene physisch isoliert — eine harte Grenze, durchgesetzt von AWS IAM, keine logische Trennung. Secrets werden beim Deployment injiziert, niemals im Code. Der Zugang läuft über JWT und per-Project-Schlüssel mit automatischer Rotation. Jede neue Version durchläuft ein strukturiertes Sicherheitsaudit.
Production-ready bedeutet compliant
In einer regulierten europäischen Umgebung hat „production-ready Harness" noch eine weitere Bedeutung: compliant Harness. Hier verschmelzen die Stärke des Harness und die regulatorische Konformität zu einem.
- EU data residency — alle Ressourcen liegen standardmäßig in der AWS-Region eu-central-1 (Frankfurt). Die Daten verlassen die EU nicht.
- Geerbte Zertifizierungen — die Infrastruktur baut auf AWS mit über 150 unabhängig auditierten Zertifizierungen auf (ISO/IEC 27001, SOC 2 Type II, C5 des BSI), einschließlich der Mitgliedschaft in der deutschen kritischen Infrastruktur (KRITIS).
- Security audit bei jeder Version — statische Analyse auf OWASP Top 10, Prüfung auf SQL-Injection, XSS, CSRF, SSRF, command injection und CVE-Schwachstellen vor der Produktion; die Berichte stehen dem Regulator zur Verfügung.
- Dedizierter und übertragbarer Account — bei Vertragsende wird der gesamte AWS-Account an den Kunden übertragen. Nichts wird migriert, keine proprietären Formate, kein Vendor-Lock-in.
Derselbe Harness, der Agenten zuverlässig macht, macht sie auch auditierbar. Die Details zu NIS2 und AI Act sind in unseren separaten Beiträgen beschrieben — NIS2 und die KI-Transformation des Fertigungssektors und AI Act und die Konformität für Unternehmen.
Was das für das Geschäft bedeutet
Die meisten Unternehmen bauen heute nicht einen einzigen KI-Agenten. Sie bauen Dutzende. Und ohne gemeinsame Infrastruktur verwandelt sich das schnell in agent sprawl — verstreute, unverbundene Agenten, die kein Team zuverlässig verwalten, auditieren oder warten kann.
Der gemeinsame, production-ready Harness löst genau das:
- Vom Demo zur Produktion. Der Prototyp, der auf dem Laptop läuft, und das System, das echtem Datenverkehr in einer regulierten Umgebung standhält, sind zwei verschiedene Dinge. Der Unterschied ist der Harness.
- Governance. Ein einziger Ort für Observability, Secrets, Limits und Audit — statt dass jeder Agent das Rad neu erfindet.
- Geschwindigkeit ohne Risikoübernahme. Die Teams konzentrieren sich auf die Logik des Agenten, nicht auf Isolation, Skalierung und Konformität — diese kommen fertig.
Das Fazit ist einfach: Erfolg in der Produktion erfordert, das Harness-Engineering als eigene Disziplin zu behandeln, gleichwertig in ihrer Bedeutung zur Wahl des Modells. Das ist die Disziplin, in der OpenKBS stark ist.
Nächster Schritt
Wenn Ihre Organisation von KI-Prototypen zu echten, production Agenten übergeht — insbesondere in einer regulierten Branche — nehmen Sie Kontakt mit uns auf. Wir betrachten Ihren konkreten Anwendungsfall und zeigen Ihnen, wie ein production-ready Harness für Ihr Geschäft aussieht: isoliert, skalierbar, sicher und standardmäßig konform.
Die beschriebenen Enterprise-Dienste — dedizierter AWS-Account, Sicherheitsaudit und Prüfung von KI-generiertem Code — sind Teil des Enterprise-Plans von OpenKBS.
Der vorliegende Beitrag hat informativen Charakter und stellt keine Rechtsberatung dar.