From OpenClaw to Flowwink
The OpenClaw reference model — how it actually works — and how Flowwink adapted it for self-hosted business operations.
What Is Flowwink?
Flowwink is a Business Operating System (BOS) — an open-source, self-hosted platform where every module exposes its capabilities as agent skills over MCP, so any operator can run the business: the built-in FlowPilot, an external agent like OpenClaw, or humans clicking through the UI. Think Odoo meets OpenClaw: the full business platform, shipping with a default operator but never locked to it. Each business runs its own isolated instance (self-hosted or in a managed cloud container), just like n8n or Supabase itself.
The Three Eras of Business Software
First separate tools you operated by hand, then human-driven SaaS, now AI operators: you set direction, the agent runs the business. (The foreword covers the market this shift disrupts.)
FlowWink is built for the agent era. It bundles 68 modules that normally require 5-10 separate SaaS tools:
| Category | Modules |
|---|---|
| Content | CMS (pages), Blog, Knowledge Base, Forms, Content Hub |
| Data | Leads, Deals, Companies, Products, Orders, Bookings, Invoices, Inventory, Consultants |
| Communication | Newsletter, AI Chat, Live Support, Webinars |
| Insights | Analytics, Sales Intelligence |
| System | Global Elements, Federation (A2A), Accounting, Expense Reporting, SLA Monitor |
Quote-to-Cash Lifecycle
FlowWink implements the full Quote-to-Cash lifecycle — from first contact to paid invoice:
Lead Capture → Qualification → Proposal/Quote → Deal Negotiation
↓
Invoice ← Fulfillment ← Order ← Checkout ← ConversionFlowPilot autonomously manages the entire pipeline: qualifying leads, drafting proposals, tracking deals, processing orders, managing inventory, and generating invoices.
Without FlowPilot, Flowwink works as a classic platform. An admin logs in, creates content, manages contacts, sends newsletters — all manually. The platform is a tool.
With FlowPilot, the same platform becomes autonomous. The agent operates the CMS, writes blog posts, qualifies leads, sends newsletters, analyzes performance — all without being asked. The platform becomes a digital employee.
This dual nature — tool when you’re driving, employee when you’re not — plus a third mode in between: any external operator can run the same platform over MCP. That triangle is what makes Flowwink unique. The rest of this chapter dissects how the modes work architecturally.
The Core Insight
OpenClaw’s fundamental insight — shared by all agentic systems that followed — is: the agent is not the model. The agent is the system around the model.
The LLM is a reasoning engine. The agent is the orchestration layer that decides what the LLM sees, what tools it can use, what it remembers, and when it acts.
┌─────────────────────────────────────────────────────┐
│ THE AGENT SYSTEM │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────┐ │
│ │ Memory │ │ Skills │ │ Prompt │ │
│ │ System │ │ Registry│ │ Compiler │ │
│ └────┬────┘ └────┬────┘ └────────┬────────┘ │
│ │ │ │ │
│ └────────────┼────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ LLM (reason) │ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Tool Router │ │
│ └───────┬───────┘ │
│ │ │
│ ┌───────────┼───────────┐ │
│ ▼ ▼ ▼ │
│ Built-in Skills External │
│ Tools (on-demand) (webhooks) │
└─────────────────────────────────────────────────────┘This architectural pattern — separating the reasoning core from skills, memory, surfaces, and infrastructure — is what both OpenClaw and Flowwink converge on. The implementation details differ significantly.
The Breakthrough: Three Text Files
If there is one thing to take from this handbook, it is this:
Peter Steinberger defined an entire autonomous agent — its personality, its operating rules, and its daily routine — in three plaintext files:
SOUL.md,AGENTS.md, andHEARTBEAT.md.
That’s the innovation. Not a framework. Not a database schema. Not a fine-tuned model. Three files that a human can read on a bus, edit in any text editor, and version-control in git.
SOUL.md— who the agent is: values, tone, boundaries, personalityAGENTS.md— how the agent works: operating rules, conventions, safety constraintsHEARTBEAT.md— what the agent does when nobody is watching: the autonomous checklist
Everything else — the skill system, the memory tiers, the A2A protocols, the governance frameworks — builds on top of this foundation. When Flowwink moved from files to a database, when NemoClaw added sandboxing — they all preserved this core abstraction: an agent’s identity and behavior are defined in human-readable documents that the operator can always inspect and change.
This is why OpenClaw matters. Not because it’s the best agent runtime. Because it established the language for defining agents.
Part 1: The OpenClaw Reference Model
All claims in this section are verified against the OpenClaw source code at github.com/openclaw.
How OpenClaw’s System Prompt Works
OpenClaw builds a system prompt from fixed sections. There is no “nine-layer” abstraction — the prompt is assembled directly:
| Section | Purpose | Verified Source |
|---|---|---|
| Tooling | Current tool list + short descriptions | docs/concepts/system-prompt.md:19 |
| Safety | Guardrail reminder against power-seeking behavior | docs/concepts/system-prompt.md:20 |
| Skills | Compact list with file paths; model reads SKILL.md on demand | docs/concepts/system-prompt.md:107-121 |
| Self-Update | How to run config.apply and update.run | docs/concepts/system-prompt.md:22 |
| Workspace | Working directory path | docs/concepts/system-prompt.md:23 |
| Documentation | Local path to docs + ClawHub reference | docs/concepts/system-prompt.md:24 |
| Workspace Files | Injected: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, MEMORY.md | docs/concepts/system-prompt.md:51-67 |
| Sandbox | Sandboxed runtime info (when enabled) | docs/concepts/system-prompt.md:26 |
| Current Date | User-local time + timezone | docs/concepts/system-prompt.md:27 |
| Reply Tags | Optional reply tag syntax | docs/concepts/system-prompt.md:28 |
| Heartbeats | Heartbeat prompt + ack behavior | docs/concepts/system-prompt.md:29 |
| Runtime | Host, OS, node, model, repo root | docs/concepts/system-prompt.md:30 |
| Reasoning | Visibility level + reasoning toggle | docs/concepts/system-prompt.md:31 |
Key constraints:
- Bootstrap files (workspace files) are capped at 20,000 chars per file, 150,000 chars total (
agents.defaults.bootstrapMaxChars,bootstrapTotalMaxChars) - Skills are NOT injected as full instructions — only name, description, and file path. The model reads
SKILL.mdon demand via thereadtool - Sub-agent sessions only inject
AGENTS.md+TOOLS.md(no soul, identity, heartbeat, etc.)
How OpenClaw’s Skill System Works
Skills are file-based. Each skill is a directory containing a SKILL.md file:
~/.openclaw/workspace/skills/
├── weather/
│ └── SKILL.md
├── github/
│ └── SKILL.md
└── canvas/
└── SKILL.mdDiscovery: OpenClaw watches skills/*/SKILL.md for changes and auto-discovers new skills (src/agents/skills/refresh.ts:85-93).
Loading: The system prompt includes a compact list:
<available_skills>
<skill>
<name>weather</name>
<description>Check weather for any city</description>
<location>~/.openclaw/workspace/skills/weather/SKILL.md</location>
</skill>
</available_skills>The model then uses the read tool to load SKILL.md when it decides the skill is relevant. This is lazy loading by design — the full skill instructions are never injected into the system prompt unless the model explicitly reads them.
ClawHub: OpenClaw integrates with ClawHub, a skill/plugin marketplace. Skills can be installed via openclaw plugins install clawhub:<package>.
How OpenClaw’s Memory Works
OpenClaw uses files on disk as its memory system:
| File | Purpose | Verified Source |
|---|---|---|
AGENTS.md | Operational rules, conventions, safety rules | docs/concepts/system-prompt.md:55 |
SOUL.md | Persona, values, tone | docs/concepts/system-prompt.md:56 |
TOOLS.md | Tool preferences, blocked tools | docs/concepts/system-prompt.md:57 |
IDENTITY.md | Name, role, emoji, avatar | docs/concepts/system-prompt.md:58 |
USER.md | User preferences, context | docs/concepts/system-prompt.md:59 |
HEARTBEAT.md | Heartbeat checklist (what to check on each cycle) | docs/concepts/system-prompt.md:60 |
MEMORY.md | Persistent memory (injected every turn) | docs/concepts/system-prompt.md:62 |
memory/*.md | Daily memory files (on-demand via tools, NOT auto-injected) | docs/concepts/system-prompt.md:69-71 |
These files are injected into the context window on every agent turn. This means they consume tokens. OpenClaw’s approach trades token efficiency for simplicity — no database, no vector search, just files.
Working Memory and Skill Budget
Human operators have limited working memory: we can only juggle a handful of items at once before focus degrades. Agents have the same constraint, except the “working memory” is measured in tokens and tool definitions rather than tasks and conversations.
OpenClaw and Flowwink both encode this as explicit skill budgets:
- OpenClaw keeps skills lightweight in the prompt and lazy-loads full instructions via the
readtool. It bundles roughly 50–90 skills out of the box (many more are installable via ClawHub). To stop a large Skill Hub from silently blowing up the context window, its skills loader enforces a configurable ceiling —maxSkillsInPromptandmaxSkillsPromptChars, set viaconfig.skills.limits. Note this is a limit on how many skill summaries (and how many characters) may enter a single prompt, not a count of how many skills the agent has — the cap can sit well above the number actually installed. - Flowwink/FlowPilot gives each autonomous heartbeat a fixed token budget and tracks how much of that budget has been consumed. As usage rises, it progressively trims and compacts tool definitions and narrows the visible skill set instead of letting every skill compete for attention on every loop.
The design lesson is simple: as your agent’s capabilities grow from “a few tools” to “dozens or hundreds of skills,” you must treat skill selection and token budgeting as first-class architecture. A powerful agent is not the one with the most skills installed — it is the one with a small, well-curated working set per decision.
How OpenClaw’s Heartbeat Works
- Default interval: 30 minutes (
docs/gateway/heartbeat.md:23) - Mechanism: The agent receives the prompt: “Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.”
- Autonomy: The agent reads its
HEARTBEAT.mdchecklist and decides what to do. There is no fixed protocol — the model reasons about what needs attention. - Skip logic: If
HEARTBEAT.mdis effectively empty (only headers/whitespace), the heartbeat is skipped to save API calls.
How OpenClaw’s A2A Works
OpenClaw provides intra-process session coordination via three tools:
| Tool | Purpose | Verified Source |
|---|---|---|
sessions_list | List active sessions with metadata | src/agents/tools/sessions-list-tool.ts:43 |
sessions_history | Fetch transcript for another session | src/agents/tools/sessions-history-tool.ts:178 |
sessions_send | Send a message to another session | src/agents/tools/sessions-send-tool.ts:99 |
This enables multi-agent coordination within a single OpenClaw instance. It is NOT Google’s A2A protocol — it is OpenClaw’s own session-level messaging system.
How OpenClaw’s Concurrency Works
- Queue-based: default lane (
main) processes inbound + main heartbeats - Configurable via
agents.defaults.maxConcurrentfor parallel sessions - Sub-agents get isolated sessions with separate context
Part 2: How Flowwink Adapts the Pattern
Everything in this section is Flowwink’s own design. It is inspired by OpenClaw but architecturally different.
The Self-Hosted Shift
OpenClaw is single-user: one human, one agent, files on disk. Flowwink is self-hosted, one instance per business — like Odoo, n8n, or Supabase itself. Each deployment is an isolated Supabase project with its own database, auth, and edge functions. In managed cloud mode, each tenant runs in isolated containers. This is not shared multi-tenancy — it is instance-level isolation.
Row-Level Security (RLS) still matters: within an instance, RLS isolates data between admin roles, public visitors, and internal system processes. But the trust boundary is the instance, not a shared database.
This deployment model changes several architectural decisions:
| Concern | OpenClaw | Flowwink |
|---|---|---|
| Storage | Markdown files on disk | PostgreSQL tables with RLS (per instance) |
| Auth | Channel allowlists | Supabase Auth + JWT |
| Runtime | Node.js Gateway daemon | Deno Edge Functions (Supabase) |
| Protocol | WebSocket control plane | HTTP/SSE |
| Deployment | Single machine | Self-hosted or managed cloud container per business |
| Multi-agent | Session tools within one process | Separate edge functions per surface |
Flowwink’s Edge Functions
Flowwink runs on Supabase Edge Functions (Deno). Each function serves a specific role in the agent system:
| Edge Function | Trigger | Purpose |
|---|---|---|
agent-operate | Admin sends message | Interactive session — admin talks to FlowPilot |
chat-completion | Visitor sends message | Public chat — visitor talks to the public-facing agent |
flowpilot-heartbeat | Cron, owner-set cadence (+ 5-min follow-through sweep) | Autonomous cycle — follow-through pre-pass, then the 7-step protocol (self-heal, propose, plan, advance, automate, reflect, remember) |
agent-execute | Called by reason core | Skill execution gateway — routes to correct handler, enforces approval gating |
agent-reason | Called by any surface | Shared reasoning core — ReAct loop, prompt compilation, tool routing |
signal-ingest | Webhook | External event ingestion — form submissions, payment events, etc. |
agent-card | GET request | A2A discovery — publishes agent capabilities to peers |
a2a-ingest | POST from peer | A2A gateway — authenticates peer, routes to skill or chat |
a2a-outbound | Agent calls peer | A2A outbound — calls external agents |
a2a-discover | Agent needs peer info | A2A discovery — fetches remote Agent Cards |
setup-flowpilot | Admin triggers onboarding | Seeds soul, identity, skills, memory for a new agent |
Key principle: agent-reason is the shared module. agent-operate, chat-completion, and flowpilot-heartbeat all call it with different configurations — scope, streaming mode, and context. No logic duplication.
FlowChat — One Chat Surface, Two Scopes
The always-on chat layer is called FlowChat, and it runs in two scopes that share the same reasoning core but have different capabilities:
┌──────────────────────────────────────────────┐
│ shared reasoning loop │
│ (chat-completion entry point) │
└──────────────────┬───────────────────────────┘
│
┌──────────┴──────────┐
▼ ▼
┌───────────────┐ ┌──────────────────┐
│ FlowChat │ │ FlowChat │
│ admin scope │ │ visitor scope │
│ │ │ │
│ scope: │ │ scope: │
│ internal │ │ external │
│ │ │ │
│ Can: │ │ Can: │
│ - Write blog │ │ - Answer FAQs │
│ - Send email │ │ - Book meetings │
│ - Manage CRM │ │ - Capture leads │
│ - Run reports│ │ - Recommend │
│ - Approve │ │ │
│ actions │ │ Cannot: │
│ │ │ - Modify data │
│ │ │ - Access admin │
│ │ │ - Send emails │
└───────────────┘ └──────────────────┘Admin scope (the business owner, via the admin UI):
- Has access to ALL skills marked
internalorboth - Can draft content, manage CRM, analyze data, send newsletters
- Gated actions follow the skill’s trust level (
auto/notify/approve/blocked)
Visitor scope (website visitors):
- Only has access to skills marked
externalorboth - Can answer questions from knowledge base, book appointments, capture lead info
- Cannot modify any data — read-only + booking
Why this matters: The scope system (internal/external/both) enforces this separation at the architecture level. A visitor can never accidentally access admin tools. An admin can never accidentally expose internal operations to visitors.
And this is where the layering completes: FlowPilot, the opt-in operator module, drives the exact same loop — the only difference is who initiates the turn. A human typing into FlowChat, or the heartbeat acting on an objective. Switch FlowPilot off and FlowChat still works; you lose autonomy, not capability. The Tesla analogy from the platform’s own docs: the platform is the car, FlowChat is the built-in chat with the car, FlowPilot is Autopilot.
Flowwink’s Prompt Architecture
Flowwink assembles its system prompt from 9 ordered layers. This is Flowwink’s design, not OpenClaw’s:
| # | Layer | Purpose | Source |
|---|---|---|---|
| 1 | Core Instructions | Grounding rules, safety, mode identity | Hardcoded |
| 2 | Tool Definitions | What the agent can do | Built-in + DB skills |
| 3 | Skills Registry | Available capabilities | agent_skills table |
| 4 | Model Aliases | Provider routing | AI config resolver |
| 5 | Protocol Specs | Reply directives, output format | Parser rules |
| 6 | Runtime Info | Domain context (CMS schema, data counts) | Domain pack |
| 7 | Workspace Files | Soul, identity, operational rules | agent_memory keys |
| 8 | Bootstrap Hooks | Skill instructions (lazy loaded) | On-demand fetch |
| 9 | Inbound Context | Current conversation + objectives + memory | Session data |
Loading strategy:
- Layers 1-3: loaded at startup (static)
- Layers 4-6: loaded per-session (configurable)
- Layers 7-9: loaded per-turn (dynamic)
Flowwink’s ReAct Loop
The reasoning core uses a ReAct (Reason → Act → Observe) loop. The general pattern is shared with OpenClaw and other agentic systems, but the constants are Flowwink-specific:
Input (message / heartbeat / event)
│
▼
┌─── reason() ────────────────────────────────────┐
│ │
│ 1. Build system prompt (9 layers) │
│ 2. Assemble tools (built-in + DB skills) │
│ 3. Call LLM │
│ │
│ 4. LLM returns response: │
│ ├── Text only → return to surface │
│ └── Tool calls → execute each: │
│ ├── Built-in tool → handlers.ts │
│ └── DB skill → handler router │
│ │
│ 5. Append tool results to conversation │
│ 6. Budget check (tokens, iterations) │
│ 7. If budget OK and more tool calls → go to 3 │
│ 8. Return final response │
│ │
└──────────────────────────────────────────────────┘
│
▼
Response (text / SSE stream / tool results)Flowwink-specific constants:
MAX_ITERATIONS = 6(interactive) /8(heartbeat)MAX_CONTEXT_TOKENS = 80,000SUMMARY_THRESHOLD = 60,000(triggers compaction)
Flowwink’s Handler Abstraction
Flowwink decouples skill definitions from implementations using handler strings. This is Flowwink’s design — OpenClaw does not use this pattern:
| Prefix | Implementation | Example |
|---|---|---|
edge: | Supabase Edge Function | edge:qualify-lead |
module: | In-process handler | module:blog |
db: | Direct database query | db:page_views |
webhook: | External HTTP call | webhook:n8n |
a2a: | Agent-to-agent peer | a2a:SoundSpace |
This means you can change how a skill is implemented without changing the agent’s understanding of what it does.
Flowwink’s Memory Architecture
Flowwink replaces OpenClaw’s file-based memory with a 4-tier PostgreSQL system. This is Flowwink’s design — OpenClaw uses files on disk:
| Tier | What | Storage | Access |
|---|---|---|---|
| L1: Session | Current conversation | In-memory / chat_messages | Linear scan |
| L2: Working | Recent memories (top 20-30) | agent_memory | Key/category filter |
| L3: Long-term | All persisted facts | agent_memory | Full-text search |
| L4: Semantic | Vector embeddings | agent_memory.embedding | pgvector cosine similarity |
The concept categories (soul, identity, agents, facts, preferences) mirror OpenClaw’s workspace files but live in database rows instead of markdown files.
Flowwink’s Three Surfaces
| Surface | Trigger | Mode | Purpose |
|---|---|---|---|
| Interactive | User message | Streaming | Real-time conversation |
| Autonomous | Cron/schedule | Non-streaming | Self-directed operation |
| External | Event/webhook | Non-streaming | Reactive processing |
In Flowwink:
- Interactive =
agent-operate(admin) /chat-completion(visitor) - Autonomous =
flowpilot-heartbeat(cron on an owner-set cadence — default every three hours — plus a 5-minute follow-through sweep) - External =
signal-ingest(webhook endpoint)
All three surfaces share the same reasoning core. This is LAW 10: Unified Reasoning Core. No logic duplication.
Flowwink’s Concurrency Model
Lane-based locking — Flowwink’s design:
heartbeat → lane: "heartbeat" (TTL: 15 min)
operate → lane: "operate:{convId}" (TTL: 5 min)Lane-based locking prevents:
- Two heartbeats running simultaneously
- Multiple operate sessions colliding
- Resource contention on shared state
The lock is time-boxed (TTL) — if the agent crashes, the lock auto-expires. No zombie locks.
Flowwink’s Safety Architecture
| Layer | Mechanism | Purpose |
|---|---|---|
| Skill scope | internal / external / both | Prevent visitor-facing agents from accessing admin tools |
| Approval gating | requires_approval: true | Human must approve destructive actions |
| Self-healing | Auto-quarantine after 3 failures | Prevent cascading failures |
| Token budget | Hard limit on context size | Prevent runaway costs |
| Iteration cap | Max 6-8 tool rounds | Prevent infinite loops |
| Wall-clock timeout | 120s hard abort | Prevent hung processes |
| Grounding rules | Hardcoded in prompt layer 1 | Safety rules that can never be overridden |
Pattern Index — OpenClaw-Inspired Business Processes
The rest of this handbook turns the reference model into concrete, copyable patterns. Each has an owning chapter:
- Specialist QA Claw for your product — a stock OpenClaw auditing your system over
/v1/responses; chapter 3 shows it running in production. - Agentic CMS/CRM (the FlowPilot pattern) — soul, heartbeat, skills, and memory applied to a business platform; Part 2 above and the Flowwink chapters that follow.
- Role-based swarms — multiple specialist Claws provisioned and routed as one workforce; the ClawClass chapter.
- Company-level orchestration — Claws as employees, an orchestration layer (Paperclip) as the company setting objectives, budgets, and governance.
- Secure perimeter and governance — sandboxing, scanning, and audit layers around the agent; chapter 6 maps the ecosystem, chapter 18 the failure modes.
You don’t need to adopt these specific projects. Once you understand the OpenClaw laws and the Flowwink adaptation, you can design your own patterns along the same lines.
Open Questions for Agentic Layers
This handbook is opinionated, but the field is still discovering what “good” looks like. Three questions keep showing up in code, issues, and production stories. How much continuity can you give an agent before memory becomes an unbounded, un-auditable dump — files and tiered databases are two different answers to the same tension. How much freedom should an agent have to rewrite its own soul and skills, and how do you detect and roll back drift when it goes wrong. And when should an agent act unilaterally versus ask for approval, so that humans feel in control rather than out of the loop.
Clawable exists partly to host this conversation. The patterns in this chapter are a snapshot of what works today; the questions are an invitation to push the architecture forward.
Why This Architecture Works
Separation of concerns, applied at the architectural level. Surfaces handle I/O, the reasoning core handles cognition, skills handle capability, memory handles continuity, infrastructure handles reliability. Each layer evolves independently: add channels without touching the reasoning core, add skills without changing memory, upgrade the LLM without rewriting the surfaces. That independence is what makes agentic systems maintainable.
OpenClaw proved the pattern with production deployments worldwide (and a star count in the hundreds of thousands as of the April 2026 snapshot in SOURCES.md). Flowwink is a separate product — a self-hosted Business Operating System, agent-agnostic over MCP, shipping FlowPilot as its built-in, opt-in operator layer.
OpenClaw is the reference model for autonomous agents. Flowwink is a self-hosted business platform that was designed with the same principles from the ground up. Understanding both — and where they differ — is the foundation for building your own agentic system.
Next: the control plane layer — Claude Code, Cursor, thin wrappers, and what creates a real moat. The Agentic Control Plane →