[Feature]: Autonomous Architecture: Daemon Mode, Heartbeat Loop & Persistent "Soul" Memory #508
Description
Summary
Here is the completed Feature Request, tailored specifically to the OpenWork template you provided. It maps the "OpenClaw-style" backend features (Soul, Heartbeat, Headless) into the required fields.
Title [Feature Request] Autonomous Backend: Headless Daemon Mode with Persistent "Soul" Memory & Heartbeat Loop
Summary Implement a "Server/Daemon Mode" for OpenWork that decouples the core agent logic from the desktop GUI. This includes a configurable "Heartbeat" (event loop) for self-waking and a "Soul" (persistent memory file) that allows the agent to maintain context, identity, and preferences across restarts, enabling true 24/7 autonomous operation on VPS or local servers.
Problem / goal
Currently, OpenWork is session-based and reactive; it requires a user to be present and initiating commands via the GUI. The Goal: Enable OpenWork to function as a "Life Agent" or "Infrastructure Manager" that runs 24/7 in the background (headless). The Outcome: The user can deploy OpenWork on a server (Docker/VPS) to autonomously monitor data, execute scheduled tasks, and refine its own behavior over months without human intervention or an active desktop session.
Primary user(s)
- Bob (IT / power user)
- Susan (non-technical)
- Other team roles
OpenCode primitive alignment
OpenCode primitive alignment Is there an existing OpenCode primitive or API that covers this? If not, why is a thin OpenWork layer still needed? While OpenCode provides the skills (tool execution, API calls), it lacks the Runtime Architecture for autonomy.
Missing Layer: OpenCode scripts execute linearly and exit. We need a "Host Layer" (the OpenWork Daemon) to manage the Event Loop (Heartbeat), handle the State Persistence (reading/writing the soul.md across sessions), and manage the process lifecycle (restart on failure, error handling for long-running jobs). A simple script cannot robustly manage its own infinite loop or self-healing without this architectural wrapper.
Alignment with VISION/PRINCIPLES/PRODUCT
Local-First / Privacy: This enables users to host their own "Always-On" agent on their own hardware, rather than relying on cloud-based autonomous services.
User Agency: Giving the user a "Soul" file they can read and edit ensures the AI's long-term behavior is transparent and fully under user control, preventing "black box" drift.
Extensibility: A headless mode invites a broader ecosystem of integrations (e.g., connecting OpenWork to Home Assistant or IoT setups) beyond just desktop productivity.
Testability
Persistence Test:
Start OpenWork in daemon mode.
Tell it: "My name is Alice."
kill the process.
Restart the process.
Query: "What is my name?" -> Expect: "Alice" (verifies soul.md functionality).
Heartbeat Test:
Configure heartbeat_interval: 1m.
Task: "Log the timestamp to log.txt every heartbeat."
Leave running for 10 minutes.
Verify log.txt has 10 entries (verifies autonomous loop).
Headless Test:
Run inside a Docker container with no display attached.
Send a command via API/MCP.
Verify execution success in logs.
Ready to build it yourself?
No
Additional context
This request aims to bridge the gap between "Task Executors" (current OpenWork) and "Autonomous Agents" (like OpenClaw/Moltbot).
Reference: The concept of a soul.md allows for "Infinite Context" simulation by compressing critical user facts into a file that is always loaded into the system prompt.
Architecture: This likely requires an entry point separate from the Electron/GUI app (e.g., openwork-server binary).