The Business Operating System — operable by any agent. Ships with one.
A modular, self-hosted SaaS platform whose every capability is exposed as a skill over MCP. Run it with the built-in vertically-integrated operator FlowPilot, swap in an external one like OpenClaw, mix several in parallel — or run it as a pure SaaS with humans in the loop. The platform doesn't care.
Every business will have an agentic operator. FlowWink is the operating system it runs on — and it lets you bring your own operator.
Give every business a self-hosted, fully-featured SaaS platform that any agent can operate via an open protocol — with a great default operator included, and the freedom to swap it out for whatever the agent ecosystem produces next.
For decades, business software has been a collection of tools you operate manually — CMS, CRM, ERP, email, e-commerce — each requiring human input at every step.
FlowWink is a Business Operating System (BOS): a unified, modular platform where every module (66 across CMS, CRM, commerce, finance, HR, operations) exposes its capabilities as agent skills over MCP. An operator — local or external — turns those skills into autonomous business outcomes.
You set the direction. The operator runs the business. You choose which operator.
┌──────────────────────────────────────────────────────────────┐
│ FlowWink SaaS Platform (always on, agent-agnostic) │
│ • 66 modules · 500+ MCP-exposed skills │
│ • Database + RLS · Automations · Event bus · Workflows │
│ • MCP server — the universal surface for any operator │
└──────────────────────────────────────────────────────────────┘
▲
│ any combination, swap freely
│
┌──────────────────────────────────────────────────────────────┐
│ Operators (opt-in, interchangeable) │
│ • FlowPilot — local, vertically integrated, included │
│ • OpenClaw — external, community-driven (clawable) │
│ • Claude Desktop · Salesforce · Microsoft · Oracle · custom │
└──────────────────────────────────────────────────────────────┘
| Profile | Recommended operator |
|---|---|
| SMB, no agent stack, wants "it just works" | FlowPilot (built-in) |
| Already runs OpenClaw / Claude Desktop / custom MCP | External, FlowPilot off |
| Wants belt-and-braces — local heartbeat + external power | Both, on the same skill catalog |
| Pure SaaS, humans in the loop | Neither — modules work without an agent |
All four are first-class. Disabling FlowPilot does not reduce what FlowWink can do — every skill is still callable over MCP, every automation still fires. See docs/concepts/operator-strategy.md and docs/architecture/mcp-as-platform.md.
Why this matters: the rationale for letting traditional SaaS be orchestrated by agents — and the architecture that makes it work — is the subject of the Agentic Handbook (clawable). FlowWink is the reference implementation.
FlowPilot is not a chatbot, a copilot, or a content suggester. It is an autonomous agent — a persistent process that wakes up on a configurable schedule (default: every 6 hours), reads your business situation, and acts.
┌─────────────────────────────────────────────────────────────────┐
│ THE AUTONOMOUS LOOP │
│ │
│ Evaluate → Plan → Advance → Propose → Automate → Reflect │
│ ↑ │ │
│ └─────────── Remember ← ──────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
| What FlowPilot does | How |
|---|---|
| Writes and publishes blog posts | Researches topics, drafts, SEO-optimizes, schedules |
| Qualifies and enriches leads | Scores, enriches from domain, routes to deals |
| Sends newsletter campaigns | Segments subscribers, drafts, schedules sends |
| Manages product promotions | Creates landing pages, promotional posts |
| Triages support tickets | Auto-categorizes, routes, resolves from Knowledge Base |
| Reviews deal pipeline | Surfaces stale deals, drafts re-engagement |
| Proposes new objectives | Reads site stats, spots gaps, creates its own goals |
| Federates with peer agents | Delegates tasks to external A2A agents via JSON-RPC |
| Evolves its own capabilities | Creates new skills, updates its instructions, reflects |
FlowWink follows an Odoo-inspired modular architecture where each module owns its data, views, and skill seeds. Modules register via defineModule() with typed contracts.
| Category | Modules |
|---|---|
| Content | Website (Pages), Blog, Knowledge Base, Docs, Wiki, Handbook, Media Library, Templates, Forms, Site Migration |
| CRM & Sales | Contacts, Companies, Deals, Quotes, Sales Intelligence, Customer 360, Business Identity, Visitor Intelligence |
| Commerce | E-commerce, Point of Sale, Bookings, Subscriptions, Inventory, Pricelists, Returns / RMA, Shipping, Manufacturing (MRP-light) |
| Finance | Accounting (BAS 2024 / IFRS / US GAAP), Quotes & Invoicing, Expense Reporting, Reconciliation, Purchasing, Fixed Assets, Multi-Currency |
| HR & People | HR & Employees, Payroll, Recruitment, Consultants, Timesheets, Contracts, Documents |
| Operations | Projects, Field Service, Maintenance, Approvals, SLA Monitor, Calendar, Surveys & NPS |
| Communication | Email Router, Newsletter, AI Chat, Live Support, Tickets (Kanban + auto-triage), FlowWork, River, Webinars, WebMeet, Voice |
| Data & Growth | Flowtable (agent data layer), Analytics, Paid Growth |
| System & Operator | FlowPilot, Federation (A2A + MCP), Browser Control, Composio, Developer |
Every module is enabled by the FlowWink Platform template — since the edge
surface was consolidated behind agent-execute, turning a module on costs skill
rows and navigation, not deployment slots.
Each module provides:
- Data layer — Supabase tables + RLS policies + RPCs
- Admin UI — React pages under
/admin/ - Skill seeds — capabilities auto-registered into
agent_skillsand exposed over MCP - Webhook events —
module.actionsignals on the platform event bus
Composite MCP groups (marketing, sales, operations, …) let an external operator request a curated toolkit with ?groups=marketing — no need to know the internal taxonomy.
| Domain | Sample skills |
|---|---|
| CMS & Content | manage_page, manage_blog_post, manage_kb_article, manage_global_block, migrate_url, scrape_url |
| CRM | manage_leads, manage_companies, manage_deals, qualify_lead, enrich_company, process_signal |
| Commerce | manage_product, place_order, record_pos_sale_v2, close_pos_session_v2, manage_subscription |
| Finance | manage_journal_entry, import_bank_image, reconcile_transaction, auto_approve_vendor_invoice, book_expense, mark_paid |
| HR & People | hire_application, auto_allocate_vacation, lock_timesheet_period, manage_contract, manage_employee |
| Procure-to-Pay | generate_expense, submit_expense, approve_expense, book_expense, create_purchase_order, receive_goods |
| Operations | manage_project, manage_task, manage_field_service, sla_check, dispatch_automation_event |
| Communication | send_newsletter_campaign, manage_webinar, upload_document |
| Support | triage_ticket, KB-powered auto-resolve |
| Intelligence | search_web, extract_pdf_text, competitor_monitor, prospect_research |
| Operator-internal (FlowPilot only, not MCP) | objectives, soul, reflect, planning, A2A delegation |
All skills follow Anthropic's MCP best practices: self-describing (Use when: / NOT for:), flat OpenAI-strict-mode-safe JSON Schemas, namespaced. See docs/architecture/mcp-as-platform.md.
Most products bolt search on top of the systems. FlowWink has the memory built in — the same knowledge, different eyes, no extra product and no data leaving your instance.
Six content sources — pages, knowledge base, wiki, docs, handbook, documents — feed a single embedded index. Every grounded surface reads from it:
| Who is asking | What they can retrieve |
|---|---|
| A visitor in the public chat | Public content only — published pages and KB articles |
| Staff in FlowWork | Public and internal — wiki, handbook, documents, contracts, CRM |
| An external agent over MCP | Whatever its key's scopes allow |
Visibility is a property of the content, enforced by row-level security — not a filter the calling surface remembers to apply. A source whose module is switched off stops being indexed (nobody pays to embed content they turned off), and answers carry citations that link back to the record they came from.
Retrieval is the default because it scales; when the index cannot answer — a brand-new instance, a page published a minute ago, no embedding key — grounding falls back to full text rather than to nothing. Degrade, never gate.
See docs/architecture/retrieval-engine.md and docs/architecture/conversation-and-retrieval.md.
FlowPilot is FlowWink's vertically-integrated, local autonomous operator — one of many possible MCP consumers, but the one that ships in the box. It runs inside the platform's trust boundary, which gives it advantages no external operator can replicate: zero-config onboarding, direct DB/event access, brand-aligned defaults, predictable cost.
External operators like OpenClaw instead win on velocity, plugin ecosystem and frontier reasoning. FlowWink supports both — see docs/concepts/operator-strategy.md for the honest trade-off.
1. EVALUATE — Score past actions against real outcomes (traffic, leads, revenue)
2. PLAN — Decompose active objectives into executable steps
3. ADVANCE — Execute the next pending step for each objective
4. PROPOSE — If no active objectives, analyze stats and create new goals
5. AUTOMATE — Detect recurring patterns, suggest or create automations
6. REFLECT — Review recent actions, distill learnings
7. REMEMBER — Save insights to semantic memory for future cycles
Research topic → Write blog post → Create social posts → Schedule newsletter
s1 s2 s3 s4
{{s1.topic}} {{s2.post_id}} {{s3.content}}
- Template variables —
{{stepId.result.field}}passes data between steps - Conditional branching — run a step only if a previous result meets a condition
- Failure modes —
on_failure: continueorstopper step
FlowPilot uses causal correlation to connect actions to business outcomes:
- Traffic metrics, leads, bookings, and revenue signals
- Hard gates for technical failures (timeout, 429, auth errors)
- Skill Scorecard — flags underperforming skills (>60% negative rate)
- Learnings saved to semantic memory for the next planning cycle
FlowPilot delegates subtasks to specialist sub-agents with persistent sessions:
FlowPilot → delegate_task("seo", "analyze /pricing page")
→ delegate_task("content", "write a case study about...")
→ delegate_task("sales", "review stale deals > $10k")
Built-in specialists: seo, content, sales, analytics, email — each maintains conversation history across invocations.
skill_pack_install("E-Commerce Pack") → product_promoter, cart_recovery_check, inventory_report
skill_pack_install("Content Marketing Pack") → content_calendar_view, seo_content_brief, social_post_batch
skill_pack_install("CRM Nurture Pack") → lead_pipeline_review, deal_stale_check, customer_health_digest
FlowWink speaks two open protocols so any operator can connect:
- MCP (Model Context Protocol) — the primary surface. 500+ skills exposed as tools, resources like
flowwink://briefing, group filtering via?groups=marketing. Works with Claude Desktop, OpenClaw, custom MCP clients. - A2A (Agent-to-Agent JSON-RPC 2.0) — peer-to-peer delegation between agents.
┌─────────────┐ MCP / A2A ┌────────────────────┐
│ FlowWink │◄──────────────▶│ Operator │
│ Platform │ tools/call │ • FlowPilot (local)│
│ (modules + │ resources │ • OpenClaw │
│ (modules + │ message/send │ • Claude Desktop │
│ 500+ skills)│ │ • custom │
└────────────────────┘
- Directional connections — peers can be inbound (MCP), outbound (
/v1/responses) or bidirectional (A2A) - Graceful degradation — 503
peer_unavailablehandling when peers are offline - Audit loop — architectural findings from peers auto-convert to platform objectives
- Agent Card —
/.well-known/agent.jsondiscovery endpoint
FlowWink follows the OpenClaw agentic architecture — composable layers with clear separation of concerns:
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ Gateway │ │ Brain │ │ Memory │
│ │ │ │ │ │
│ • Visitor chat │────▶│ • Pilot engine │────▶│ • pgvector │
│ • Admin operate │ │ (ReAct loop) │ │ semantic search│
│ • Webhooks │ │ • resolveAiConfig │ │ • Soul + Identity│
│ • Heartbeat │ │ • tool execution │ │ • Conversation │
│ • A2A ingest │ │ • trace IDs │ │ • Objectives │
└─────────────────┘ └──────┬───────────┘ └─────────────────┘
│
┌────────────────┼────────────────────┐
│ │ │
┌──────▼─────┐ ┌───────▼───────┐ ┌────────▼──────┐
│ Skills │ │ Heartbeat │ │ Workflows │
│ │ │ │ │ │
│ 500+ skills │ │ 7-step loop │ │ DAG chains │
│ Skill Packs │ │ Self-healing │ │ Conditions │
│ A2A peers │ │ Outcome eval │ │ Template vars │
└─────────────┘ └───────────────┘ └───────────────┘
The Pilot engine (_shared/pilot/) is the single engine shared by every surface:
agent-operate— interactive admin sessions (streaming)flowpilot-heartbeat— autonomous scheduled loopchat-completion— visitor-facing AI chata2a-ingest— incoming federation requests
No logic duplication. All surfaces get every capability automatically.
_shared/
├── pilot/
│ ├── reason.ts — Main ReAct reasoning loop
│ ├── prompt-compiler.ts — System prompt assembly
│ ├── handlers.ts — Built-in tool implementations
│ └── built-in-tools.ts — Tool definitions
├── types.ts — Shared type definitions
├── ai-config.ts — Provider routing (OpenAI → Gemini → Local)
├── concurrency.ts — Lane-based locking
├── token-tracking.ts — Budget management
├── trace.ts — Correlation IDs (fp_{ts}_{rand})
└── domains/
└── cms-context.ts — CMS domain pack
OpenAI GPT-4o → Gemini 2.5 Flash → Local LLM (Ollama / LM Studio / vLLM)
FlowPilot routes to whichever provider is configured. Use your own API keys. Run fully offline with a local model. No vendor lock-in.
FlowWink draws inspiration from the best-in-class platforms across every business domain — and unifies them under one autonomous operator.
| Category | Platforms that inspired | FlowWink's BOS module |
|---|---|---|
| Website | WordPress, Webflow, Squarespace, Weebly | Visual block editor, 50+ blocks, headless API |
| CRM & Sales | HubSpot, Pipedrive, Salesforce | Leads, deals, companies — AI-qualified and enriched |
| Email & Marketing | Mailchimp, Klaviyo, ConvertKit | Newsletter with autonomous segmentation and campaigns |
| Booking | Calendly, Acuity | Service bookings with AI follow-up |
| Support | Zendesk, Freshdesk, Intercom | Tickets + live chat with AI triage from Knowledge Base |
| Content & Copy | Jasper, Copy.ai, Surfer SEO | FlowPilot writes, optimizes, and publishes into CMS |
| Automation | Zapier, n8n, Make | Workflow DAGs with conditional branching |
| E-Commerce | Shopify, WooCommerce | Products, orders, inventory, Stripe checkout |
| Finance | QuickBooks, Xero, FreshBooks | Invoicing, double-entry accounting, expenses |
| Time Tracking | Toggl, Harvest, Clockify | Timesheets with project-based tracking |
| ERP | Odoo, ERPNext | Modular architecture — 66 domains, one platform |
| Headless CMS | Contentful, Storyblok, Strapi | REST + GraphQL content API, multi-channel delivery |
The difference: those platforms give you tools. FlowWink gives you an operator that uses the tools.
One operating system. One operator. Self-host free.
| Layer | Technology |
|---|---|
| Frontend | React 18, Vite, TypeScript, Tailwind CSS |
| UI Components | shadcn/ui, Radix UI |
| Backend | Supabase (PostgreSQL + pgvector, Auth, Storage, Edge Functions) |
| Agent Engine | Deno edge functions, OpenAI function-calling format |
| Editor | Tiptap |
| State | TanStack Query |
| AI Providers | OpenAI, Google Gemini, Local LLM (Ollama / LM Studio / vLLM) |
| Federation | A2A JSON-RPC 2.0 protocol |
FlowWink is free to self-host. Your agent, your data, your infrastructure.
git clone https://github.com/magnusfroste/flowwink.git
cd flowwink
npm install
cp .env.example .env
# Edit .env with your Supabase credentials
npm run dev # migrations run automaticallyThe recommended path for a new instance needs no local tooling at all — three dashboards and a push. Proven end-to-end on a fresh instance: 385 migrations, 77 edge functions, storage, cron and a working public site, zero terminal commands.
- Fork this repo and create a Vercel project from your fork.
- Create a Supabase project. From Project Settings → API Keys, copy the Project URL and the publishable key (
sb_publishable_…). - Set two Vercel env vars —
VITE_SUPABASE_URLandVITE_SUPABASE_PUBLISHABLE_KEY— then redeploy. (An unconfigured deploy shows a "connect your backend" page instead of a blank screen, so you always know where you are.) - Pair Supabase's GitHub integration with your fork and pick the production branch. It applies every pending migration and deploys every edge function declared in
supabase/config.tomlon each push. Pairing alone may not fire it — push a commit if nothing happens. - Log in. On a virgin instance the first account automatically becomes admin.
- Admin → Modules → "Sync skills from code" — the one step migrations don't cover, because skills come from the module seeds in the frontend bundle.
- Install a template, add an AI provider key, and (optionally) mint an operator key for an external agent.
Full walkthrough, the verification queries, and the known first-run retry: docs/operators/provisioning-without-cli.md.
A site is four layers, each with its own delivery rail. The CLI-free stack moves three of them with a single fork sync:
| Layer | Source of truth | How it updates |
|---|---|---|
| Schema | supabase/migrations/*.sql |
Fork sync → Supabase GitHub integration applies pending migrations |
| Edge functions | supabase/functions/* |
Same push — every function declared in config.toml redeploys |
| Frontend | this repo | Same push — Vercel rebuilds |
| Skills | src/lib/modules/* (skillSeeds) |
Admin → Modules → "Sync skills from code" after the frontend deploy |
The fourth layer is the one to remember: migrations never touch agent_skills.
The sync button re-runs the module bootstrap from the freshly deployed bundle,
refreshing every skill definition while leaving runtime trust_level overrides
alone. It checks whether a newer build is live and reloads first, so a stale tab
cannot write stale seeds.
Migrations are forward-only by construction: a CI gate blocks any migration timestamped at or below the current head, because a back-dated file is silently skipped by the ledger on instances already past it — the drift class this repo learned the hard way.
Prefer terminal tooling, or maintaining several instances at once?
supabase link --project-ref <your-ref>
supabase db push
supabase functions deploy --project-ref <your-ref>
# Sync skill metadata from code into agent_skills (the step that prevents drift).
DATABASE_URL='postgresql://postgres:<pw>@db.<your-ref>.supabase.co:5432/postgres' \
npm run sync:skills -- --applyMulti-site operators: docs/operators/provisioning-and-updates.md
covers the fleet runbook, the sync:skills tool and fork vs. auto-deploy
topology. See docs/guides/deployment.md for the
full walkthrough.
Start at docs/start-here.md — the curated entry point that routes to operators, builders, agents and reference material.
| Document | What it covers |
|---|---|
| docs/modules/flowpilot.md | FlowPilot agent reference — skills, heartbeat, tools |
| docs/reference/skills-source.md | Skill registry — all registered skills |
| docs/reference/module-api.md | Module contract system, typed schemas, plugin architecture |
| docs/concepts/openclaw-law.md | Agentic architecture laws |
| docs/concepts/prd.md | Product requirements — modules, capabilities |
| docs/concepts/elevator-pitch.md | BOS positioning, vision, competitive landscape |
| docs/guides/setup.md | Supabase setup, environment variables, migrations |
| docs/guides/deployment.md | Supabase Cloud + Vercel deployment walkthrough |
| docs/operators/provisioning-without-cli.md | Stand up an instance with dashboards only — fork, Vercel, Supabase GitHub integration, and how updates flow afterwards |
| docs/operators/provisioning-and-updates.md | Multi-site provisioning, the update runbook, skill-sync & drift prevention |
| docs/operators/local-development.md | Run Supabase locally (OrbStack/Docker) to validate migrations & changes before prod |
| docs/builders/README.md | Architecture, extending the platform, writing skills |
| docs/guides/security.md | RLS policies, auth patterns, security model |
| docs/contributing/test-suite.md | Autonomous test framework (L1–L8) |
| docs/concepts/a2a-communication-model.md | Agent-to-Agent federation protocol |
| docs/pilot/ | Pilot engine internals — architecture, handlers, reasoning |
- Hosted Skill Pack Registry — Import community skill packs from a manifest URL
- Workflow Visualization — Admin UI to view and edit DAG steps visually
- Multi-Tenant Mode — Run FlowWink as a SaaS with per-tenant agent isolation
- Agent Marketplace — Shareable FlowPilot configurations (soul + skills + workflows)
- Expanded A2A Ecosystem — Peer discovery, trust scoring, capability negotiation
Contributions are welcome. Open an issue or submit a pull request. See docs/contributing/contributing.md.
FlowWink is the reference implementation of a thesis: traditional SaaS becomes radically more valuable when it's operable by agents over an open protocol. The handbook explains why, how, and what patterns hold up in production.
📖 clawable — The Agentic Handbook & OpenClaw — Practical guide to building agentic systems, the OpenClaw operator, and the architectural laws FlowWink follows.
Cross-references inside this repo:
docs/concepts/operator-strategy.md— Why FlowPilot is a module, not the coredocs/architecture/mcp-as-platform.md— The rule that keeps modules + MCP independent of any operator, and the MCP endpoints / auth / schemas / group-filter referencedocs/concepts/openclaw-law.md— The 10 inviolable agentic architecture laws
MIT — see LICENSE for details.
Stop managing tools. Start directing outcomes. Bring your own operator — or use the one in the box.
Made in Sweden 🇸🇪