OpenFang

Die meisten Agent-Frameworks setzen einen Menschen in der Schleife voraus, der Prompts tippt und Antworten liest. OpenFang von RightNow-AI vertritt die Gegenposition: Es ist ein Agent-Betriebssystem in Rust, dessen Agenten nach eigenem Zeitplan rund um die Uhr laufen, ohne dass jemand sie anstößt. Statt einer Bibliothek, die man in die eigene App einbaut, ist es eine vollständige Laufzeitumgebung, die zu einer einzigen Binary von etwa 32MB kompiliert und Agent-Orchestrierung, Memory, Kanal-Anbindung und Sicherheit in einem Paket bündelt. Das adressierte Problem ist operativ statt konversationell: Wie betreibt man autonome Worker, die Dinge überwachen, Daten sammeln und fortlaufend Ergebnisse melden, während Ressourcenverbrauch, Nachvollziehbarkeit und Sicherheit unter Kontrolle bleiben. Agenten gelten hier als langlaufende Hintergrunddienste, nicht als Chat-Oberfläche.

Die Architektur baut auf sieben vorgefertigten Fähigkeitspaketen auf, die das Projekt Hands nennt und die Aufgaben wie Lead-Findung, OSINT-Sammlung, Prognosen, belegte Recherche, Social-Media-Management, Browser-Automatisierung und Kurzvideo-Erstellung abdecken. Sie laufen nach Zeitplan und schreiben in ein persistentes Memory auf Basis von SQLite plus Vektor-Embeddings, sodass ein Agent Zustand über Läufe hinweg aufbaut, statt jedes Mal neu zu starten. Besonders ist die Betonung von Isolation und Rechenschaft: Tool-Code läuft in einer WebAssembly-Sandbox mit Fuel-Metering und Watchdog, und Aktionen werden in einem Merkle-Hash-Chain-Audit-Trail festgehalten. Das Projekt zählt insgesamt 16 Sicherheitssysteme, darunter Ed25519-Manifest-Signierung, Taint-Tracking, SSRF-Schutz und Prompt-Injection-Scanning. Drei native LLM-Treiber leiten an viele Provider weiter, und 40 Kanal-Adapter verbinden Agenten mit Telegram, Discord, Slack, WhatsApp, Signal, E-Mail und weiteren.

OpenFang richtet sich an Entwickler und kleine Teams, die autonome Agenten als Backend-Dienst statt als Chat-Produkt wollen und die mit Rust-Binaries auf der Kommandozeile umgehen können. Die mitgelieferten Hands bilden konkrete Jobs direkt ab: tägliche Lead-Findung gegen ein Ideal-Customer-Profil mit Scoring und Deduplizierung, Beobachtung von Wettbewerbern oder Themen auf Veränderungen mit Sentiment-Tracking und Knowledge-Graphs, das Erstellen belegter Recherche-Berichte oder das Verwalten eines X-Accounts mit geplanten Posts und Freigabe-Queue. Die breite Kanal-Abdeckung passt zu Teams, die ohnehin in Messaging-Tools arbeiten und Ergebnisse dort geliefert bekommen wollen. Die WASM-Sandbox und der Audit-Trail machen es zudem zu einer plausiblen Wahl für alle, die Agenten reale Fähigkeiten geben wollen, etwa Browser-Automatisierung mit Kauf-Freigaben, und dabei einen manipulationssicheren Nachweis brauchen, was jeder Agent wirklich getan hat.

Die ehrlichen Vorbehalte sind erheblich. OpenFang ist klar Pre-1.0: Das Projekt warnt selbst vor Ecken und Kanten sowie Breaking Changes zwischen Minor-Versionen und rät, für den Produktivbetrieb auf einen festen Commit zu pinnen statt Releases zu folgen. Das allein schließt Workloads aus, die stabile APIs brauchen. Die Aktivität rund um das Projekt schien nahe einem Release-Freeze nachzulassen, was bei einem so jungen System Beachtung verdient. Die Performance-Zahlen sind die eigenen Angaben des Projekts: ein Kaltstart unter 200ms, rund 40MB Leerlaufspeicher und eine Testsuite im Tausenderbereich, nichts davon hier unabhängig geprüft. Die Breite ist zudem zweischneidig: 27 Provider, 40 Kanäle und sieben Hands sind viel Oberfläche für ein kleines Team, und das Projekt merkt an, dass nur die Hands Browser und Researcher am ausgereiftesten sind.

Im Vergleich zu kommerziellen Plattformen wie Relevance AI oder Botpress tauscht OpenFang gemanagten Komfort und polierte Oberflächen gegen selbstgehostete Kontrolle, eine freizügige duale MIT- und Apache-2.0-Lizenz und eine für eine quelloffene Agent-Laufzeit ungewöhnlich ernste Sicherheitshaltung. Das Rust-Single-Binary-Design, die große Testsuite und das zeitplangesteuerte Modell signalisieren echte Engineering-Substanz statt eines dünnen LLM-Wrappers. Eine Adoption lohnt sich jetzt, wenn man ein selbstgehostetes, zeitplangesteuertes autonomes Backend mit breiter Kanal-Abdeckung und WASM-Sandbox will und mit dem Pinnen von Commits sowie Breaking Changes leben kann. Zu früh ist es, wenn man stabile, unterstützte APIs, eine langfristige Kompatibilitätsgarantie oder einen gehosteten Dienst mit SLA braucht. Für solche Fälle sollte man auf ein 1.0-Release warten oder eine gemanagte Alternative wählen.