OpenFang

Most agent frameworks assume a human sits in the loop, typing prompts and reading replies. OpenFang, from RightNow-AI, takes the opposite stance: it is an agent operating system written in Rust whose agents run on their own schedules, around the clock, without anyone prompting them. Instead of a library you wire into your own app, it is a complete runtime that compiles down to a single binary of roughly 32MB and bundles agent orchestration, memory, channel connectivity and security into one package. The problem it addresses is operational rather than conversational: how do you run autonomous workers that monitor things, gather data and report results continuously, while keeping resource use, auditability and safety under control. It frames agents as long-running background services rather than as a chat interface.

The architecture is built around seven pre-built capability packages the project calls Hands, covering tasks like lead discovery, OSINT collection, forecasting, cited research, social media management, browser automation and short-form video creation. These run on schedules and write to persistent memory backed by SQLite plus vector embeddings, so an agent accumulates state across runs rather than starting fresh each time. What is distinctive is the emphasis on isolation and accountability: tool code executes inside a WebAssembly sandbox with fuel metering and a watchdog, and actions are recorded in a Merkle hash-chain audit trail. The project counts 16 security systems in total, including Ed25519 manifest signing, taint tracking, SSRF protection and prompt-injection scanning. Three native LLM drivers route to a broad set of providers, and 40 channel adapters connect agents to Telegram, Discord, Slack, WhatsApp, Signal and Email.

OpenFang is aimed at developers and small teams who want autonomous agents as a backend service rather than a chat product, and who are comfortable operating Rust binaries from the command line. The bundled Hands map directly to concrete jobs: running daily lead discovery against an ideal-customer profile with scoring and deduplication, watching competitors or topics for changes with sentiment tracking and knowledge graphs, producing cited research reports, or managing an X account with scheduled posts and an approval queue. The broad channel coverage suits teams that already live in messaging tools and want results delivered there. The WASM sandbox and audit trail also make it a plausible fit for anyone who needs to grant agents real-world capabilities, such as browser automation with purchase approval gates, while keeping a tamper-evident record of what each agent did.

The honest caveats are significant. OpenFang is firmly pre-1.0: the project itself warns of rough edges and breaking changes between minor versions, and advises pinning to a specific commit for production rather than tracking releases. That alone rules out workloads that need stable APIs. Activity around the project appeared to slow near a release freeze, which is worth watching for a system this young. The performance numbers are the project's own claims: a cold start under 200ms, around 40MB idle memory and a passing test suite in the thousands, none independently verified here. The breadth is also a double-edged sword: 27 providers, 40 channels and seven Hands are a lot of surface area for a small team to keep reliable, and the project notes that only the Browser and Researcher Hands are the most battle-tested.

Compared with commercial platforms like Relevance AI or Botpress, OpenFang trades managed convenience and polished UIs for self-hosted control, a permissive dual MIT and Apache-2.0 license, and an unusually serious security posture for an open-source agent runtime. The Rust single-binary design, the large test suite and the schedule-driven model all signal real engineering substance rather than a thin wrapper around an LLM. It is worth adopting now if you want a self-hosted, schedule-driven autonomous backend with broad channel coverage and a WASM sandbox, and you can live with pinning commits and absorbing breaking changes. It is too early if you need stable, supported APIs, a long-term compatibility guarantee, or a hosted service with an SLA. For those cases, wait for a 1.0 release or choose a managed alternative.