OpenClaw-Inspired Self-Evolving AI Assistant for Local-First IDE Workflows

In early 2026, an open-source project called OpenClaw exploded onto the scene, surpassing 230,000 GitHub stars within weeks. It represented a fundamental shift in how we think about AI assistants: not as stateless chatbots, but as persistent, context-aware digital coworkers that run on your own hardware.

I was fascinated by OpenClaw’s architecture, particularly its layered design (Gateway, Agents, Memory, Skills, Heartbeat) and its emphasis on local-first ownership. But as a product manager who primarily works inside a code editor, I did not need a full multi-channel platform with WhatsApp, Telegram, and Docker sandboxing. What I needed was something much lighter: an AI assistant that lives in my IDE, remembers what I care about, and gets better at helping me over time.

So I built Daily Assistant, a lightweight, OpenClaw-inspired personal AI system that runs entirely as Markdown files and Cursor IDE rules. No servers. No daemons. No external dependencies. Just files, rules, and a structured evolution workflow.

This post covers the design thinking, implementation details, and trade-offs behind this project.

What OpenClaw Gets Right

Before diving into what I built, it is worth understanding the system that inspired it.

OpenClaw is a self-hosted AI assistant platform created by Peter Steinberger. It runs on your own hardware (a laptop, Mac Mini, VPS, or Docker container) and connects large language models to the messaging apps you already use. The fundamental shift it represents is treating your AI assistant not as a prompt engineering challenge, but as an infrastructure problem.

OpenClaw’s Architecture

OpenClaw follows a hub-and-spoke architecture where the Gateway acts as the central hub, routing messages from any channel into a shared agent and memory backend:

flowchart TB
    subgraph Channels ["Channels (Spokes)"]
        WA["WhatsApp"]
        TG["Telegram"]
        SL["Slack"]
        DC["Discord"]
        IM["iMessage"]
        WC["WebChat"]
    end

    WA & TG & SL & DC & IM & WC --> Router

    subgraph GW ["Gateway (Hub)"]
        Router["Router"]
        Sessions["Sessions"]
        Auth["Auth"]
        Router --> Sessions --> Auth
    end

    Auth --> Core

    subgraph Agent ["Agent Runtime"]
        Core["Pi Agent"]
        Core --> Tools["Tools"]
        Core --> Sandbox["Sandbox"]
    end

    Core --> Memory

    subgraph Memory ["Memory System"]
        MD["MEMORY.md"]
        Logs["Daily Logs"]
        DB["SQLite + Vectors"]
    end

Cross-cutting: the Memory system (Markdown files as canonical source, SQLite with vector embeddings as derived index) provides context across all layers.

Key OpenClaw Features

• 50+ integrations: WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Microsoft Teams, and more
• Heartbeat system: Agents run 24/7, proactively monitoring tasks at configurable intervals
• Cron jobs: Persistent scheduler for precise timing (daily reports, health checks)
• Multi-agent orchestration: Multiple isolated agents with separate workspaces and sessions
• ClawHub marketplace: 5,700+ community-built skills with semantic search
• Security model: DM pairing, Docker sandboxing, exec approval chains, Tailscale integration
• SOUL.md: A personality definition file that shapes agent behavior across sessions

Why I Built My Own Instead of Using OpenClaw Directly

This was a deliberate product decision, not a case of “not invented here” syndrome. The reasoning came down to four factors.

Safety and Transparency

OpenClaw is a powerful platform, but power comes with attack surface. In February 2026, security researchers discovered the “ClawHavoc” incident: 341 malicious skills on ClawHub were stealing user data, and 283 skills (7.1%) had critical security flaws. While OpenClaw responded quickly with VirusTotal scanning and publisher verification, the incident highlighted a real risk.

My system has zero dependency on external skill registries. Every file is a plain Markdown document that I can read, audit, and version-control with git. There is no binary execution, no Docker container orchestration, and no third-party skill marketplace.

Complexity vs. Need

OpenClaw requires Node.js 22+, a running Gateway daemon (launchd/systemd service), channel configuration (WhatsApp QR pairing, Telegram bot tokens, etc.), and optionally Docker for sandboxing. That is a lot of infrastructure for a single-user, single-device use case.

I work almost exclusively inside Cursor IDE. My assistant does not need to answer WhatsApp messages or manage Discord servers. It needs to remember my preferences, help me think through problems, and improve itself based on how I actually work.

Full Auditability

Every piece of state in my system is a Markdown file:

• SOUL.md defines the assistant’s personality. I can read it in 30 seconds.
• MEMORY.md contains everything the assistant “knows” about me. I can edit or delete any line.
• evolution/CHANGELOG.md tracks every self-modification with timestamps and rationale.

Compare this to OpenClaw, where state is distributed across ~/.openclaw/ in JSON configs, SQLite databases, credential stores, and session files. That is more powerful, but also harder to audit quickly.

Evolution as a First-Class Concept

OpenClaw has the infrastructure for agents to learn (memory files, SOUL.md, workspace skills), but it does not prescribe a structured evolution workflow. My system makes self-improvement an explicit, trackable process with dedicated directories, reflection templates, and a changelog.

Daily Assistant: System Design

Design Philosophy

The core insight is that Cursor IDE already provides two of OpenClaw’s four layers for free:

• Gateway = Cursor itself (it handles the user interface, message routing, and tool orchestration)
• Agent Runtime = Cursor’s built-in AI agent (it does the LLM reasoning, tool calling, and streaming)

What Cursor does not provide out of the box is the “operating system” layer around the agent: persistent identity, structured memory, and self-improvement mechanisms. That is what Daily Assistant builds.

flowchart TB
    subgraph CursorIDE ["Cursor IDE (provides Gateway + Agent)"]
        Rule[".cursor/rules/assistant.mdc<br/>(Control Plane)"]
    end

    Rule -->|"reads at session start"| Soul["SOUL.md<br/>(Identity & Values)"]
    Rule -->|"reads for context"| Memory["MEMORY.md<br/>(Long-term Memory)"]
    Rule -->|"checks recent logs"| DailyLog["memory/YYYY-MM-DD.md<br/>(Daily Logs)"]
    Rule -->|"triggers on command"| Evolution["evolution/<br/>(Self-improvement)"]
    Rule -->|"uses capabilities"| Skills["skills/<br/>(Reusable Skills)"]
    Rule -->|"runs checklist"| Heartbeat["HEARTBEAT.md<br/>(Health Check)"]

    Evolution -->|"proposes changes to"| Soul
    Evolution -->|"proposes changes to"| Rule
    Evolution -->|"records in"| Changelog["evolution/CHANGELOG.md"]

Project Structure

daily-assistant/
|
+-- .cursor/
|   +-- rules/
|       +-- assistant.mdc           # The control plane: boot sequence,
|                                    # ReAct loop, memory rules,
|                                    # evolution workflow, heartbeat
|
+-- SOUL.md                          # Identity, communication style,
|                                    # values, boundaries, growth mindset
|
+-- MEMORY.md                        # Long-term curated facts: user
|                                    # profile, preferences, projects,
|                                    # conventions
|
+-- HEARTBEAT.md                     # On-demand health check checklist:
|                                    # memory hygiene, open loops,
|                                    # tool status, friction points
|
+-- memory/                          # Daily interaction logs
|   +-- 2026-02-27.md               # (append-only, one file per day)
|   +-- 2026-02-28.md
|   +-- ...
|
+-- evolution/
|   +-- CHANGELOG.md                 # Append-only log of every
|   |                                # self-modification (date, files
|   |                                # touched, rationale)
|   +-- reflections/
|       +-- 2026-02-27.md           # Deeper self-analysis notes from
|       +-- ...                      # explicit "evolve" sessions
|
+-- skills/                          # Project-specific reusable skills
|   +-- (future additions)
|
+-- workflows/                       # Reusable workflow templates
|   +-- (future additions)
|
+-- config/
|   +-- mcporter.json                # External tool config (Exa search)
|
+-- openclaw-design-deep-dive.md     # Reference: OpenClaw architecture
+-- README.md                        # Project documentation

Component Deep Dive

1. The Control Plane: .cursor/rules/assistant.mdc

This is the single most important file in the system. It is a Cursor project rule that gets automatically loaded whenever the project is opened. It functions as the “Gateway” of the system, defining:

Boot Sequence: At the start of every session, the assistant reads SOUL.md (identity), MEMORY.md (long-term context), and the most recent daily logs and reflections. This gives it continuity across conversations.

ReAct Working Loop: For non-trivial tasks, the assistant follows a structured Reason, Act, Observe, Iterate cycle. It prefers fixing root causes over symptoms and verifies its own work.

Memory Responsibilities: Clear rules for what goes where. Stable facts go to MEMORY.md. Session-specific notes go to daily logs. The assistant actively proposes promoting important daily log entries to long-term memory.

Evolution Triggers: Defines the exact conditions under which the assistant can propose self-modifications, and the approval workflow it must follow.

Heartbeat Protocol: Maps user commands like “health check” to the structured checklist in HEARTBEAT.md.

2. Identity Layer: SOUL.md

Inspired directly by OpenClaw’s SOUL.md concept. This file defines five core values:

1. Correctness over speed: Verify before assuming
2. Root-cause thinking: Hypothesize and test, do not patch symptoms
3. Local-first and privacy: Keep data on-device, explain any external calls
4. Evolvability: Treat own behavior as refactorable code
5. Honesty about uncertainty: Label guesses as guesses

It also defines explicit boundaries: no destructive commands without confirmation, no silent changes to core files, no fabricated facts.

3. Memory System: MEMORY.md + memory/

A two-tier memory architecture:

flowchart LR
    subgraph ShortTerm ["Short-term (Daily Logs)"]
        D1["memory/2026-02-27.md"]
        D2["memory/2026-02-28.md"]
        D3["memory/2026-03-01.md"]
    end

    subgraph LongTerm ["Long-term (Curated)"]
        Mem["MEMORY.md"]
    end

    D1 -->|"promote important facts"| Mem
    D2 -->|"promote important facts"| Mem
    D3 -->|"promote important facts"| Mem

    Mem -->|"loaded every session"| Agent["Agent Context"]
    D3 -->|"latest log loaded"| Agent

• Daily logs (memory/YYYY-MM-DD.md): Append-only, one file per day. Captures decisions, TODOs, experiments, and session notes. High volume, moderate signal.
• Long-term memory (MEMORY.md): Curated, stable facts. User profile, preferences, project context, conventions. Low volume, high signal. Updated only when daily log entries prove to be persistent.

This mirrors OpenClaw’s approach (Markdown files as canonical source) but skips the SQLite vector index. For a single-user system where the assistant reads files directly, full-text file reading is sufficient.

4. Health Checks: HEARTBEAT.md

A structured checklist with five sections:

1. Memory Health: Is MEMORY.md current? Any daily log facts to promote? Any stale entries?
2. Open Loops: Unresolved TODOs, parked questions, temporary decisions that became permanent
3. Tools and Integrations: Run agent-reach doctor, check external channel status
4. Workflows and Friction: Identify repeated manual steps, propose automation
5. Evolution Hooks: Flag patterns that warrant a full reflection session

Unlike OpenClaw’s Heartbeat (which runs on a timer, e.g. every 30 minutes), this is pull-based. The user triggers it when they want a status check. This is a deliberate trade-off: no background process needed, but no proactive monitoring either.

5. Self-Evolution: evolution/

This is the most distinctive component of the system. The evolution workflow follows a structured five-step process:

flowchart TD
    Trigger["User says 'evolve'<br/>or assistant notices<br/>recurring friction"]
    ReadLogs["Read recent daily logs<br/>and past reflections"]
    Identify["Identify patterns:<br/>- Repeated pain points<br/>- Re-derived instructions<br/>- User work habits"]
    Draft["Draft reflection in<br/>evolution/reflections/YYYY-MM-DD.md"]
    Propose["Show proposals to user:<br/>- SOUL.md changes<br/>- New rules<br/>- New skills/workflows"]
    Approve{"User approves?"}
    Implement["Implement changes"]
    Log["Append to<br/>evolution/CHANGELOG.md"]

    Trigger --> ReadLogs
    ReadLogs --> Identify
    Identify --> Draft
    Draft --> Propose
    Propose --> Approve
    Approve -->|Yes| Implement
    Approve -->|No / Revise| Draft
    Implement --> Log

Key design principle: the assistant never silently changes its own identity or rules. Every modification goes through explicit user approval and gets logged with a timestamp and rationale. This creates a fully auditable evolution trail.

Feature Comparison: Daily Assistant vs. OpenClaw

Where Daily Assistant Wins

• Radical simplicity: The entire system is ~10 Markdown files. Anyone can understand it in 5 minutes. There is no build step, no runtime, no package manager.
• Total transparency: Every piece of state is a plain text file. Nothing is hidden in a database or binary format. Git diff shows exactly what changed and when.
• Structured evolution: Self-improvement is not an afterthought. It has dedicated directories, a formal workflow, and an auditable changelog.
• IDE-native: Designed specifically for the Cursor IDE workflow. The assistant is context-aware about your code, files, and terminal, not just chat messages.
• Zero attack surface: No external skill registry, no network listeners, no Docker containers, no credential stores.

Where OpenClaw Wins

• Multi-channel reach: One assistant, accessible from WhatsApp, Telegram, Slack, Discord, iMessage, and more. You can talk to it from your phone while away from your computer.
• Always-on proactivity: Real Heartbeat (runs every 30 minutes) and Cron (precise scheduling) enable proactive monitoring without user prompting.
• Deep tool integration: Browser control (Chromium CDP), Canvas/A2UI, mobile device nodes (camera, screen recording, location), system notifications.
• Mature security model: Docker sandboxing per session, exec approval chains, DM pairing for unknown senders, Tailscale network isolation.
• Community ecosystem: 800+ active developers, 15,000+ daily skill installations, growing marketplace.
• Scalable memory: SQLite with vector embeddings enables semantic search over large memory stores. Plain file reading does not scale to thousands of daily logs.

What I Deliberately Left Out

• No background execution: cannot proactively alert you about anything
• No multi-device access: works only inside Cursor on one machine
• No voice interface: text-only interaction
• Memory search is sequential file reading, which will slow down as daily logs accumulate over months
• No sandboxing: the assistant has the same filesystem access as Cursor itself

These were scoping decisions, not oversights. Each one reduced complexity without reducing value for the target use case: a single user, working in a single IDE, who cares more about transparency and self-improvement than channel reach.

Use Cases and Workflow Examples

Research and Document Synthesis

Scenario: I need to research a technical topic, synthesize findings from multiple sources, and produce a structured document.

sequenceDiagram
    participant User
    participant Assistant
    participant Web as Web Search / Exa
    participant FS as Filesystem

    User->>Assistant: "Search for OpenClaw's unique<br/>design and workflow, summarize<br/>into a detailed doc"
    Assistant->>Web: Search multiple queries in parallel<br/>(English + Chinese sources)
    Web-->>Assistant: Results from docs, blogs,<br/>technical analyses
    Assistant->>Web: Fetch full articles for<br/>deeper detail
    Web-->>Assistant: Complete article content
    Assistant->>FS: Write structured Markdown<br/>document with 13 chapters
    FS-->>Assistant: File saved
    Assistant->>User: "Document created at<br/>openclaw-design-deep-dive.md"
    Assistant->>FS: Append to today's daily log:<br/>"Created OpenClaw research doc"

The assistant decomposes the research goal into parallel search queries (English and Chinese), fetches full articles rather than snippets, synthesizes a structured document with diagrams and citations, and logs the session output in the daily memory log.

Project Scaffolding from a Design Reference

Scenario: I have a reference architecture document and want to turn it into a working project structure with all the right files and conventions.

sequenceDiagram
    participant User
    participant Assistant
    participant Plan as Plan Mode
    participant FS as Filesystem

    User->>Assistant: "Build this workflow into<br/>the daily-assistant project"
    Assistant->>Plan: Switch to Plan mode<br/>(complex task, needs design)
    Plan->>User: Present architecture diagram,<br/>file structure, component specs
    User->>Plan: Approve plan
    Plan->>Assistant: Switch to Agent mode<br/>(begin implementation)
    Assistant->>FS: Create .cursor/rules/assistant.mdc
    Assistant->>FS: Create SOUL.md
    Assistant->>FS: Create MEMORY.md + memory/
    Assistant->>FS: Create HEARTBEAT.md
    Assistant->>FS: Create evolution/ tree
    Assistant->>FS: Update README.md
    Assistant->>User: "All 6 components created.<br/>System is ready."

The assistant recognizes this is an architectural task, switches to Plan mode first, presents a structured plan with diagrams for user review, and after approval implements each component systematically while tracking progress via a todo list.

Self-Evolution Session

Scenario: After a week of daily use, I ask the assistant to review itself and propose improvements.

sequenceDiagram
    participant User
    participant Assistant
    participant Logs as memory/*.md
    participant Evo as evolution/

    User->>Assistant: "Review yourself"
    Assistant->>Logs: Read last 7 daily logs
    Assistant->>Evo: Read past reflections
    Assistant->>Assistant: Identify patterns:<br/>1. User often asks for bilingual<br/>2. Memory promotion is manual<br/>3. Research tasks follow<br/>same 3-step pattern
    Assistant->>Evo: Write reflection to<br/>evolution/reflections/2026-03-05.md
    Assistant->>User: "Here are 3 proposals:<br/>1. Add auto-promote rule<br/>2. Create research workflow<br/>3. Adjust SOUL.md tone"
    User->>Assistant: "Approve #1 and #2,<br/>skip #3"
    Assistant->>Evo: Implement changes
    Assistant->>Evo: Append to CHANGELOG.md:<br/>"Added auto-promote rule<br/>and research workflow template"
    Assistant->>User: "Evolution complete.<br/>2 changes applied."

The assistant reads recent interaction history for patterns, drafts a structured reflection with specific and actionable proposals, waits for explicit user approval on each proposal, implements approved changes, and logs everything in the changelog.

On-Demand Health Check (Heartbeat)

Scenario: I want to make sure nothing has fallen through the cracks.

sequenceDiagram
    participant User
    participant Assistant
    participant HB as HEARTBEAT.md
    participant Mem as MEMORY.md
    participant Logs as memory/*.md
    participant Tools as agent-reach

    User->>Assistant: "Heartbeat"
    Assistant->>HB: Load checklist (5 sections)
    Assistant->>Mem: Check: is MEMORY.md current?
    Assistant->>Logs: Check: any unresolved TODOs?
    Assistant->>Tools: Run: agent-reach doctor
    Tools-->>Assistant: 7/12 channels active
    Assistant->>Logs: Check: any repeated friction?
    Assistant->>User: Report:<br/>- MEMORY.md: needs 2 updates<br/>- Open TODOs: 3 items<br/>- Tools: 7/12 channels OK<br/>- Friction: research flow<br/>  could be a workflow

Roadmap

These are concrete improvements organized by feasibility and impact.

Phase 1: Near-Term (Weeks)

Phase 2: Medium-Term (Months)

Phase 3: Long-Term (Quarters)

The OpenClaw Hybrid Vision

The most interesting long-term direction is combining both systems:

flowchart TB
    subgraph IDE ["Cursor IDE (Daily Work)"]
        DA["Daily Assistant<br/>(rules + memory + evolution)"]
    end

    subgraph OC ["OpenClaw Gateway (Background)"]
        HB["Heartbeat (every 30min)"]
        Cron["Cron Jobs"]
        Channels["WhatsApp / Telegram"]
    end

    subgraph Shared ["Shared State"]
        MemMD["MEMORY.md"]
        DailyLogs["memory/*.md"]
        Soul["SOUL.md"]
    end

    DA <-->|"reads/writes"| Shared
    OC <-->|"reads/writes"| Shared
    HB -->|"proactive alerts"| Channels
    Cron -->|"scheduled tasks"| DailyLogs

In this model, Daily Assistant handles the IDE-centric workflow (coding, research, documentation), while OpenClaw handles everything that needs to happen when I am away from my computer (notifications, scheduled checks, multi-channel access). Both systems share the same Markdown-based memory layer, so context is never lost.

Lessons Learned

Start with the workflow, not the technology

I did not start by asking “what framework should I use?” I started by asking “what does my actual daily workflow look like, and where does an AI assistant add the most value?” The answer was: inside my IDE, where I spend 8+ hours a day. That immediately ruled out 80% of OpenClaw’s feature set and pointed toward a much simpler solution.

Transparency is a feature, not a constraint

Making every piece of state a readable Markdown file is not a limitation. It is a product advantage. I can audit my assistant’s memory in 30 seconds. I can edit its personality with a text editor. I can see exactly how it evolved over time by reading git log. This level of transparency builds trust in a way that database-backed systems cannot.

Evolution needs structure, not just capability

OpenClaw gives agents the capability to learn (memory files, personality configs, workspace skills). But capability without process leads to ad-hoc, hard-to-audit changes. By adding a formal evolution workflow with reflections, proposals, approvals, and a changelog, I turned a vague “the AI learns” promise into a concrete, trackable process.

The best v1 is the one you actually use

A full OpenClaw deployment would have taken me a day to set up and would have required ongoing maintenance. My Daily Assistant took about 2 minutes to set up and started providing value immediately. The “worse” technology choice was the better product choice because I actually use it every day.

Design for composability, not completeness

By keeping the system simple and file-based, I preserved the option to integrate with OpenClaw later (the hybrid vision described above). If I had built a complex custom system with its own database and daemon, integrating with OpenClaw would be much harder. Simple, file-based systems compose well.

Conclusion

Building Daily Assistant taught me that the most impactful AI products are not always the most technically impressive ones. OpenClaw is a remarkable piece of engineering with 230,000+ stars for good reason. But for my specific use case (single user, single device, IDE-centric workflow), a handful of Markdown files and a well-designed Cursor rule delivered more daily value than a full platform deployment would have.

The key insight is that AI assistant architecture is not one-size-fits-all. OpenClaw optimizes for multi-channel reach, always-on availability, and community ecosystem. Daily Assistant optimizes for transparency, simplicity, and structured self-improvement. Both are valid product choices for different user contexts.

If you are a product manager, developer, or anyone who spends most of their day in a code editor, I would encourage you to try this approach. Fork the repo, customize the SOUL.md to match your working style, and see what happens when your AI assistant starts remembering and evolving.

Project repository: daily-assistant Inspired by: OpenClaw (235K+ stars)