Building a self-hosted multi-agent runtime

Systems such as OpenClaw and Hermes made personal agents feel possible. I wanted to understand every important layer before I trusted one with my own routines, messages, and work.

That led to Friday OS. It began as a small Claude Agent SDK experiment and grew into a private runtime with chat interfaces, voice, persistent memory, retrieval, tools, skills, automations, specialist subagents, and a dashboard for seeing what was happening.

I wanted ownership before autonomy.

Trust meant knowing which capabilities were available, what the system remembered, where a request came from, and how to stop or recover a task. It also meant accepting that using hosted models and services creates boundaries I still need to secure carefully.

I did not start with a grand architecture. I added a component when a real need appeared, then pulled repeated behaviour back into the shared runtime.

Autonomy is useful when I can see what the system remembers, what it can do, and how to undo a bad change.

The system grew from one route into a shared spine.

A central Agent SDK wrapper now handles model turns, streaming, sessions, tools, and usage logging. Telegram, Discord, iMessage, and browser voice all connect to that same runtime. Each channel has its own delivery details, while the agent behaviour remains consistent.

Warm sessions keep conversations responsive. Queues and rate-limit handling protect longer tasks. In-flight records make interrupted work visible so it can be inspected or recovered instead of quietly disappearing.

Memory needed two speeds.

A small user context holds details that should be available on every turn. Longer-term memories live in a vector database and return only when they are relevant. This keeps the prompt useful without asking the model to carry an ever-growing personal archive into every conversation.

A daily three-pass consolidation process reviews new memories, challenges weak or duplicated entries, and promotes the details that deserve to persist. The goal is better context over time, with a record I can still inspect and edit.

Specialists only helped when the boundary was real.

Earlier versions included named resident agents: Iris for content, Forge for web development, and Scout for research. Their different instructions and personalities helped me learn where specialization improved the work.

Keeping every specialist permanently active created extra state and operational overhead. The current system centres on Friday as the main operator and creates focused subagents for the task at hand. The useful roles remain, with fewer moving parts to monitor.

What I mean when I say the system learns

Friday OS saves explicit preferences, recalls relevant memories, consolidates repeated evidence, and can reuse skills that encode a successful way of working. Those mechanisms let its context improve through use.

I describe the current system as adaptive and self-maintaining. It does not independently rewrite its core code and prove that the new version is better. A stronger claim needs evaluation: retrieval quality, task success, correction rates, and safe rollback when a change makes the system worse.

Trust came from the operational details.

The dashboard exposes activity, memory, schedules, queues, and failures. Checkpointed operations preserve a path back when the system changes its own files. Rate limits, retries, and recovery paths matter more in daily use than a polished one-turn demo.

Publishing it forced a clean boundary.

The private deployment still owns conversations, memories, credentials, and personalized instructions. The public edition contains the runtime, neutral templates, synthetic configuration, deny-by-default capability boundaries, and a clean Git history.

The source is now available in the public repository, alongside setup, architecture, privacy, security, and testing documentation. It is a starter for building a fresh system, rather than an export of the one that held my private data.

Friday OS is still ongoing. Its value so far is practical: one system shaped around how I work, and an architecture I can question when something behaves unexpectedly.