Design-Prinzipien, Performance, Security, Scaling und Resilience — und warum die meisten Agenten-Plattformen genau an diesen Stellen scheitern.
Es gibt seit einigen Monaten eine neue Familie von KI-Agenten-Runtimes, die im deutschsprachigen Raum gerne unter dem Sammelbegriff „Claws“ oder auch mal „Clawz“ diskutiert wird: OpenClaw (ehemals MoltBot, persönliches Experimentier-Framework), PaperClip (das Agentic-Framework von Sebastian Küpers und der Serviceplan-Gruppe), Hermes-Agent und unsere eigene Variante HybridClaw. Was diese Systeme verbindet, ist ein architektonischer Bruch mit der ersten Welle von Agenten-Plattformen: weg von monolithischen Cluster-Setups, hin zu schlanken, lokal ausführbaren Runtimes, die in Sekunden booten und trotzdem produktiv betrieben werden können.
In diesem Artikel geht es um die Architektur und die Design-Prinzipien, die HybridClaw von der Konzeption her zu einer Lightweight Runtime machen — und warum genau das die Voraussetzung dafür ist, Performance, Security, Scaling und Resilience überhaupt sauber lösen zu können.
Warum „Lightweight“ das richtige Modell für Agenten ist
Die erste Generation von Agenten-Plattformen hat sich am Beispiel klassischer Microservice-Stacks orientiert: Kubernetes, Service Mesh, ein eigener Cluster für Vector-DB, ein eigener für die Queue, ein dritter für Observability. Das funktioniert für Hyperscaler und für hochfrequentierte Endkunden-APIs gut. Für Agenten ist es das falsche Modell.
Ein Agent ist kein zustandsloser Request-Handler. Ein Agent ist näher an einem langlaufenden Prozess, der Skills komponiert, Tools aufruft, Modelle befragt, Browser steuert und dabei eine Trajektorie aufbaut, die später für Evals, Replay und Audit gebraucht wird. Wenn man dieses Konstrukt in einen klassischen Microservice-Stack presst, optimiert man die falsche Achse: man bekommt Hochverfügbarkeit für Komponenten, die selten ausfallen, und gleichzeitig keine vernünftigen Antworten auf die Fragen, die im Agenten-Betrieb wirklich wehtun — „Welches Skill-Update hat letzte Woche die Performance versaut?“, „Welcher Tool-Call hat das falsche Steuerkennzeichen gesetzt?“, „Können wir den Lauf von Dienstag 11:43 reproduzieren?“
HybridClaw geht den umgekehrten Weg. Die Runtime ist ein einzelnes Binary (Go-style), das auf dem Laptop in unter einer Sekunde startet. Kein Cluster, kein Kubernetes, kein Helm-Chart als Voraussetzung. Produktivumgebungen skalieren auf mehrere Worker-Prozesse, aber das ist eine Option, kein Eintrittspreis. Wer Agenten anfangen will, kommt ohne DevOps-Team aus. Wer sie produktiv betreiben will, hat denselben Code-Pfad — nur mit mehr Workern und einer Control Plane darüber.
Diese Architektur-Entscheidung ist kein Selbstzweck. Sie ist die Grundlage für sechs konkrete Design-Prinzipien, die alle weiteren Eigenschaften der Runtime bestimmen.
Die sechs Design-Prinzipien im Detail
1. Lightweight by default
Single Binary, kein Cluster, kein State-Store als Pflicht. Die Runtime selbst hat keinen geteilten Mutable State — Koordination passiert über die HybridAI Control Plane (Queue + Leader Election), wenn ein Multi-Node-Setup gefahren wird. Bis dahin reicht eine SQLite oder das lokale Filesystem.
2. Local-first Execution
Agenten laufen, wo die Daten liegen. Skills, Tool-Calls und Browser-Automatisierung führen standardmäßig in der User-Umgebung aus. Keine Klartextdaten verlassen den Perimeter ohne explizites Routing durch die Control Plane. Das ist nicht nur ein DSGVO-Feature, das ist auch ein Latenz-Argument: Wer Browser-Automation aus dem RZ über die Public Cloud auf einen lokalen ERP-Login routen will, hat schon verloren.
3. Deterministische Skills
Skills sind versionierte, content-addressed Manifeste. Gleicher Input + gleiche Skill-Version = gleiche Trajektorie. Das ist der Punkt, an dem viele Agenten-Frameworks heimlich schummeln: Sie schreiben den System-Prompt zur Laufzeit aus drei Templates zusammen, ziehen Werte aus Umgebungsvariablen, und hoffen, dass es reproduzierbar bleibt. Tut es nicht. Wenn Skills nicht deterministisch addressierbar sind, sind Evals nicht aussagekräftig und Rollbacks nicht sicher. HybridClaw behandelt Skills wie Code-Artefakte: signiert, versioniert, hash-identifizierbar.
4. Sandboxed Tool Use
Jedes Tool läuft in einem isolierten Execution-Context mit expliziten Capability Grants. Browser-Automation, File-Access, Shell-Commands — alle durch signierte Manifeste und Runtime-Policy abgesichert. Default-Deny. Ein Skill, das Mails schreiben können soll, bekommt keinen Shell-Access. Ein Skill, das Logs analysiert, kommt nicht an die Mail-API. Das klingt banal, ist aber in der Praxis der Punkt, an dem die meisten Agenten-Demos in echten Compliance-Reviews durchfallen.
5. Content-addressed Artifacts
Trajektorien, Skill-Outputs und Audit-Records sind content-addressed. Jeder Eintrag bekommt einen Hash, der seinen Inhalt eindeutig identifiziert. Die Einträge sind miteinander verkettet — Manipulationen werden erkannt. Das macht Traces reproduzierbar, replayable und manipulationsfest. Es ist die Voraussetzung dafür, dass man einem Betriebsprüfer in 7 Jahren beweisen kann, was ein Agent wann gemacht hat. Ohne diese Eigenschaft sind Audit-Logs hübsche Tabellen ohne juristischen Wert.
6. Observable Everything
Jeder Span, jeder Tool-Call, jede Modell-Invocation emittiert strukturierte Telemetrie by default. Nicht als Plugin, nicht als optionale Extension, nicht als „das machen wir später“. Operators bekommen Dashboards mit Latenz, Cost-per-Task, Eval-Scores und Safety-Incidents out of the box. Wer ein Agenten-System ohne diese Telemetrie betreibt, betreibt blindes Vertrauen — und das ist im Enterprise-Kontext keine Strategie.
Performance & Scaling: Vom Laptop in die Worker-Flotte
Skalierbarkeit ist bei Agenten-Runtimes selten ein Problem der reinen Request-Rate. Eine Agenten-Flotte mit fünfzig parallel laufenden Agenten ist nicht das, was klassische Web-Backends in den Schweiß treibt. Schwierig wird es, weil Agenten lang laufen, unvorhersagbar viele Tool-Calls machen und Modell-Antworten streamen, statt sie abzuwarten. HybridClaw adressiert das auf fünf Ebenen.
Agent-Level Concurrency. Jeder Agent hat seine eigene Task-Queue. Ein langlaufender Tool-Call — sagen wir, eine Browser-Session, die 90 Sekunden auf eine Bestätigungsseite wartet — blockiert keine Schwester-Agenten. Das ist kein triviales Pattern; viele frühe Agent-Frameworks haben hier eine globale Queue gehabt und sind genau daran gescheitert.
Batched LLM Calls. Wenn mehrere Agenten gleichzeitig dasselbe Modell befragen, werden in-flight Prompts gebündelt, wenn der Provider das zulässt. Senkt Cost und Latency für High-Volume-Workloads spürbar. Bei 100+ Anfragen pro Minute an dasselbe Modell ist das nicht „nice to have“, sondern entscheidet über die Token-Rechnung am Monatsende.
Multi-Layer Cache. Skill-Outputs, Retrieval-Ergebnisse und Tool-Responses werden auf drei Ebenen gecached: in-memory für den aktuellen Task, on-disk für den Agenten-Prozess, und Worker-übergreifend bei explizitem Opt-in. Letzteres ist absichtlich kein Default — Cache-Coherence zwischen Workern ist eine der häufigsten Fehlerquellen in verteilten Agenten-Systemen.
Worker Scaling. Horizontale Skalierung passiert durch zusätzliche Worker-Prozesse. Koordination läuft über die HybridAI Control Plane (Queue + Leader Election) — nicht in der Runtime selbst. Das ist die Architektur-Entscheidung, die das Single-Binary-Versprechen am Leben hält: Die Runtime weiß nichts von anderen Workern. Sie macht nur ihren Job. Der Cluster-Aspekt liegt bewusst eine Ebene höher.
Streaming Everywhere. Model-Outputs, Tool-Results und Channel-Responses streamen End-to-End. Es wird nicht erst auf eine vollständige Completion gewartet, bevor der nächste Schritt anläuft. Das senkt nicht nur die wahrgenommene Latenz im Chat-Interface — es ermöglicht auch, dass Folge-Tools schon arbeiten, während das Hauptmodell noch denkt.
Security: Vom feindlichen Input ausgehen
Agenten-Plattformen multiplizieren den Blast-Radius jedes Security-Fehlers. Ein klassischer Chatbot, der ein Modell jailbreaked bekommt, generiert maximal peinlichen Text. Ein Agent, der jailbroken wird, kann Mails verschicken, Rechnungen bezahlen, Tickets anlegen, Datenbanken schreiben. Wer Agenten ernsthaft betreibt, muss von feindlichen Inputs ausgehen — sowohl von außen (Prompt Injection in einer eingehenden Mail) als auch von innen (ein Modell, das halluziniert und sich für autorisiert hält).
HybridClaw legt sechs Security-Schichten übereinander, die alle Default-on sind:
Secrets Vault. Tools sehen nie Raw-Credentials. Passwörter, API-Keys, OAuth-Tokens werden per ID referenziert und zur Laufzeit über die Control Plane aufgelöst. Auch im Audit-Log und in den Trajektorien tauchen nur die IDs auf, nie der Klartext. Wer Logs grept, findet keine Secrets.
RBAC & Capability Grants. Berechtigungen werden per Agent, per Skill, per Tool vergeben. Default-Deny: Was nicht explizit erlaubt ist, ist verboten. Das gilt auch für scheinbar harmlose Dinge wie Network-Access.
Sandboxed Execution. File-Access, Shell-Commands und Browser-Automation laufen in isolierten Kontexten ohne Host-Network-Access by default. Ein Skill, der eine PDF parst, kommt nicht ans Internet — es sei denn, ihm wird genau diese Capability explizit verliehen.
Signed Skill Manifests. Skills werden gegen signierte Manifeste verifiziert, bevor sie laufen. Keine unsignierten Code-Paths in Production. Das verhindert Supply-Chain-Angriffe über manipulierte Skill-Updates — ein Risiko, das in der Branche systematisch unterschätzt wird.
Human-in-the-Loop Gates. High-Impact-Actions — Überweisungen, Massendeletes, externe Mails an Kunden — können menschliche Freigabe verlangen. Konfigurierbar pro Skill, audit-gelogged. Wer einen Agenten 10.000 Euro überweisen lassen will, sollte das mit einem zweiten Klick bestätigen müssen.
Tamper-evidentes Audit-Log. Jede Aktion ist content-addressed und chained. Operators können beweisen, was ein Agent gemacht hat, wann, unter welcher Autorität, mit welcher Skill-Version, mit welchem Input, mit welchem Output, in welcher Latenz, zu welchen Kosten. In der Managed Cloud wird der Log zusätzlich in einen externen Append-only-Store gespiegelt und 7 Jahre revisionssicher aufbewahrt.
Resilience: Failure als Default-Case
Hier liegt einer der wichtigsten Unterschiede zwischen Demo-Agenten und produktiven Agenten: Produktive Agenten scheitern. Modelle timen aus, Tools geben unerwartete Fehler zurück, Netzwerke partitionieren, ein Lieferant ändert seine API ohne Vorwarnung. Wer Agenten nur für den Happy Path baut, baut Spielzeug.
HybridClaw behandelt Failure als Default-Case, nicht als Edge-Case. Konkret:
| Failure Mode | Runtime Behavior |
|---|---|
| Transienter Model-Error | Exponential Backoff; bei wiederholten Fehlern Fallback auf konfiguriertes Alternativ-Modell. |
| Tool-Exception | Fehler wird in der Trajektorie erfasst; Agent kann retrien, anderes Tool wählen oder eskalieren. |
| Worker-Crash | Task wird requeued; idempotente Skills resumen vom letzten Checkpoint. Non-idempotente Skills warten auf manuelle Replay-Entscheidung. |
| Schlechte Skill-Version | Eval-Gate blockiert Deploy, wenn der Regression-Score eine Schwelle überschreitet. Wenn doch durchgerutscht: Rollback ist ein einziger Befehl. |
| Dead-Letter Queue | Tasks, die das Retry-Budget überschreiten, landen in einer DLQ für menschliche Inspektion — werden nie still verworfen. |
| Cost-Runaway | Per-Agent-Budgets begrenzen den Spend. Soft-Limits warnen, Hard-Limits stoppen neue Tasks bis zur manuellen Aufhebung. |
Der letzte Punkt ist in der Praxis derjenige, der bei den meisten Konkurrenz-Plattformen fehlt — und der die teuersten Schäden anrichtet. Ein Agent, der in einer Schleife hängt und in vier Stunden 8.000 Euro an Token-Kosten produziert, ist kein theoretisches Szenario. Wir haben das in echten Setups gesehen. Cost-Runaway-Protection gehört auf dieselbe Ebene wie Security und Audit, nicht in das „Premium-Tier“.
Self-Hosted Runtime, Managed Control Plane — oder beides
Architektonisch klar zu trennen sind in HybridClaw zwei Ebenen: die Runtime (Open Source, leicht, selbst hostbar) und die Control Plane (gemanagt, in der EU gehostet, mit Compliance-Features).
Die Runtime kümmert sich um Agent-Execution, Skill-Manifeste, Tool-Sandboxing, Browser-Automation, lokale Trajektorien-Erfassung und die Multi-Channel-Adapter (Discord, Teams, WhatsApp, E-Mail, Web, Terminal). Sie ist auf GitHub frei verfügbar, kann lokal laufen, kann auf der eigenen Infrastruktur betrieben werden.
Die Control Plane kümmert sich um RAG und Memory, das Company Brain, RBAC, den Secrets Vault, das Audit-Log, die Observability-Dashboards, die Skill-Evals und Deploy-Gates, die Budget-Kontrollen, das EU-Hosting und die DSGVO- sowie AI-Act-Konformität. Sie liegt auf hybridai.one und wird von uns betrieben.
Beide Ebenen sind unabhängig deploybar. Die häufigsten Konstellationen, die wir bei Kunden sehen:
- Vollständig Managed Cloud. Schnellster Weg in die Produktion, Operations bei uns, EU-Hosting auf Hetzner.
- Self-Hosted Runtime + Managed Control Plane. Datenkontrolle auf dem Kunden-Perimeter, aber kein eigenes Audit-Storage- oder Eval-Setup nötig.
- Vollständig Self-Hosted. Maximale Kontrolle, alles auf eigener Infrastruktur, lokale Modelle via Ollama oder vLLM, bis zu 80% Token-Ersparnis gegenüber Cloud-LLMs.
- Hybrid Deployment. Managed-Cloud-Agenten delegieren sensible Aufgaben an Self-Hosted-Agenten. Funktioniert über das Agent-to-Agent-Messaging.
Wichtig: Skills und Memory sind portabel zwischen den Deployments. Wer in der Managed Cloud anfängt und später migriert, muss nicht alles neu bauen.
Fazit: Lightweight ist kein Mangel, sondern eine Entscheidung
Wer „Lightweight Runtime“ hört, denkt vielleicht an „Spielzeug“ oder „nicht enterprise-tauglich“. Das wäre ein Missverständnis. Lightweight heißt hier: keine Komplexität, die der Use-Case nicht rechtfertigt. Ein Agent braucht keinen Kubernetes-Cluster, um Rechnungen zu klassifizieren. Ein Agent braucht keine zwölf Microservices, um eine SAP-Buchung vorzubereiten. Was er braucht, ist ein sauberes Skill-Modell, signierte Manifeste, isolierte Tools, ein tamper-evidentes Audit-Log und Telemetrie, die zeigt, ob er den Job macht oder nicht.
Genau das ist HybridClaw. Eine Open-Source-Runtime, die in unter einer Sekunde bootet, die mit einem einzigen Binary auskommt und die trotzdem alle Eigenschaften mitbringt, die man für den produktiven Betrieb in einem regulierten Umfeld braucht. Die Control Plane darüber ist optional — aber für jeden, der DSGVO-Konformität, Audit-Logs über 7 Jahre und EU-Hosting nicht selbst bauen will, die deutlich entspanntere Variante.
Wer sich die Architektur im Detail anschauen will: hybridclaw.io/architecture. Wer direkt loslegen will: GitHub für Self-Hosted, hybridai.one für die Managed Cloud. Demo gibt’s auf der re:publica 26 in Berlin live — wir lassen dort einen HybridClaw-Agenten ein Buch schreiben. Mal sehen, wie weit er kommt.