The OpenClaw reference model — how it actually works — and how Flowwink adapted it for multi-tenant business operations.

From OpenClaw to Flowwink — Reference Model and Adaptation

This chapter separates fact from design. Every claim about OpenClaw is verified against its source code. Every Flowwink extension is clearly marked.

What Is Flowwink?

Before diving into architecture, the reader needs context: what does Flowwink actually do?

Flowwink is a B2B SaaS platform — a digital operating system for businesses. It bundles capabilities that normally require 5-10 separate SaaS tools:

Module	What it does
CMS	Pages, layouts, themes — the company’s web presence
Blog	Articles, categories, SEO, scheduled publishing
CRM	Contacts, companies, leads, deals pipeline, engagement scoring
Forms	Contact forms, surveys, lead capture with conditional logic
Newsletter	Subscriber management, campaign creation, send + tracking
Booking	Appointment scheduling with availability rules
E-Commerce	Products, orders, inventory, checkout
Webinars	Event registration, reminders, follow-up
Tickets	Support ticket system with priority and assignment
Knowledge Base	FAQ and docs powering the public chat agent
Analytics	Site stats, page views, conversion tracking

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 — is what makes Flowwink unique. The rest of this chapter dissects how both 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.

Part 1: The OpenClaw Reference Model

All claims in this section are verified against the OpenClaw source code at /Users/mafr/Code/github/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.md on demand via the read tool
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.md

Discovery: 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.

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.md checklist and decides what to do. There is no fixed protocol — the model reasons about what needs attention.
Skip logic: If HEARTBEAT.md is 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.maxConcurrent for 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 Multi-Tenant Shift

OpenClaw is single-user: one human, one agent, files on disk. Flowwink is multi-tenant: many businesses, each with their own agent, data isolated via Supabase Row-Level Security (RLS).

This changes everything:

Concern	OpenClaw	Flowwink
Storage	Markdown files on disk	PostgreSQL tables with RLS
Auth	Channel allowlists	Supabase Auth + JWT
Runtime	Node.js Gateway daemon	Deno Edge Functions (Supabase)
Protocol	WebSocket control plane	HTTP/SSE
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`	12h cron	Autonomous cycle — 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.

The Dual-Agent Architecture

Flowwink runs two separate agent surfaces that share the same reasoning core but have different capabilities:

┌──────────────────────────────────────────────┐
│              agent-reason.ts                  │
│         (shared reasoning module)             │
└──────────────────┬───────────────────────────┘
                   │
        ┌──────────┴──────────┐
        ▼                     ▼
┌───────────────┐    ┌──────────────────┐
│  FlowAgent    │    │  Public Chat     │
│  (admin)      │    │  (visitors)      │
│               │    │                  │
│  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   │
└───────────────┘    └──────────────────┘

FlowAgent (admin-side, agent-operate):

Triggered by the business owner via the admin UI
Has access to ALL skills marked internal or both
Can draft content, manage CRM, analyze data, send newsletters
Destructive actions require approval (requires_approval: true)

Public Chat (visitor-side, chat-completion):

Triggered by website visitors
Only has access to skills marked external or both
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.

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,000
SUMMARY_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 (12h cron)
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

Why This Architecture Works

This architecture works because it separates concerns:

Surfaces handle I/O (how the agent communicates)
Reasoning core handles cognition (how the agent thinks)
Skills handle capability (what the agent can do)
Memory handles continuity (what the agent knows)
Infrastructure handles reliability (how the agent runs)

Each layer can evolve independently. You can add new channels without touching the reasoning core. You can add new skills without changing the memory system. You can upgrade the LLM without rewriting the surfaces.

This is the principle that makes agentic systems maintainable: separation of concerns at the architectural level.

OpenClaw proved the pattern with 346k+ GitHub stars and production deployments worldwide. Flowwink adapted it for multi-tenant business operations — same brain, different body.

OpenClaw is the reference. Flowwink is the adaptation. 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 →

From OpenClaw to Flowwink