Claude Code, Cursor, Cline, Roo, Windsurf, Copilot — what they actually are, how they work, and what the thin wrapper problem reveals about moats in the AI era.

The Agentic Control Plane — The Layer Between You and the Model

Every tool in this category shares the same secret: the model isn’t the product. The orchestration layer around it is. Understanding this distinction is the difference between building something defensible and building something that disappears when the next model drops.

Before we go deeper into how Flowwink implements the OpenClaw reference model, we need to place OpenClaw in its broader context. Most readers of this handbook already use one of the tools in this chapter daily — Claude Code, Cursor, Cline, or Roo. They feel very different from each other. But architecturally, they are variations on the same thing: a control plane sitting above a model.

Understanding what that means — and why the control plane, not the model, is where value is created — directly shapes how you think about building Flowwink, ClawStack, or any agentic system of your own. The lesson from this chapter carries forward through everything that follows.

What “Agentic Control Plane” Actually Means

“Control plane” is a networking term. In a network, the control plane is the layer that decides how data should flow — the routing logic, the policies, the orchestration. The data plane is what actually moves the data.

Applied to AI agents: the model is the data plane — it processes tokens and generates responses. The control plane is everything around it: what context the model sees, what tools it can call, what permissions govern those calls, how results feed back into the loop.

Claude Code, Cursor, Cline, Roo, Windsurf, Copilot — they are all control planes sitting above a model. The model changes. The control plane is the product.

This is not a subtle distinction. It is the central business and architectural question of the current moment.

The Landscape (April 2026)

Tool	Type	Architecture	Model approach	Moat
Claude Code	Terminal agent	Agentic loop + React/Ink TUI	Claude-native, Messages API	Deep Anthropic integration, CLAUDE.md, Teams
Cursor	AI-native IDE	Fork of VS Code + agent layer	Model-agnostic, Chat Completions	IDE depth, codebase indexing, $2.5B valuation
Windsurf	AI-native IDE	Codeium-based IDE	Acquired by OpenAI ($3B)	Folded into OpenAI ecosystem
Cline	VS Code extension	Agentic loop, XML tool format	Model-agnostic, 59k stars	Open-source, extensibility
Roo	VS Code extension	Multi-agent, role-driven	Model-agnostic, 23k stars	Custom modes, agentic orchestration
GitHub Copilot	IDE + chat	GitHub integration + agent	Mostly GPT-4o / o1	GitHub ecosystem, enterprise distribution
Devin	Autonomous coder	Full autonomy, cloud-hosted	Proprietary	Deep autonomy, long-horizon tasks

The consolidation signal: OpenAI acquired Windsurf for $3 billion in early 2026. Key Windsurf executives and engineers moved to Google in a separate $2.4B talent deal. The control plane layer is being fought over at the acquisition level — which tells you the value is real.

How Claude Code Actually Works

The architecture blog post from March 31, 2026, is the most detailed public description of any agentic coding tool. What it reveals is closer to OpenClaw than to a “chat wrapper with a code plugin”:

The Agentic Loop

You type a goal
        │
        ▼
Claude reasons →  produces text + tool_use blocks
        │
        ▼
Tools execute (Bash, Read, Write, Edit, Glob, Grep, Task...)
        │
        ▼
tool_result fed back to Claude
        │
        ▼
Claude decides: more tools, or final response?
        │
        └──► loops until final text response with no tool_calls

Key detail: Claude can chain multiple tool calls per turn. A single API call can return several tool_use blocks — read three files, run a grep, and edit a function — all executing in sequence without separate requests. This is the Messages API tool_use content block model in practice.

The Tool System — ~26 built-in tools

Each tool has:

Input schema (Zod-validated before execution)
Permission check (allow / deny / ask)
Execution logic
UI renderer (terminal display)

The meta-tools are where it gets architecturally interesting:

Task — spawns a subagent: a child conversation with its own isolated context, runs tools, returns a summary. This is how Claude Code paralelizes work. Identical to OpenClaw’s sessions_spawn.
MCP — loads additional tools from Model Context Protocol servers at runtime. Your project can define custom tools; they appear in Claude’s palette alongside built-ins.

The Permission Model — 5 layers

1. Tool-level checkPermissions()
   (Bash checks destructive commands, Write checks paths)
        ↓
2. Settings allowlist/denylist
   (glob patterns: Bash(npm:*), Read(~/project/**)
        ↓
3. Sandbox policy
   (managed restrictions on paths, commands, network)
        ↓
4. Active permission mode
   (default / acceptEdits / plan / bypassPermissions / auto)
        ↓
5. Hook overrides
   (PreToolUse hooks can approve, block, or modify)

Sound familiar? This is the same philosophy as OpenClaw’s tool policy (TOOLS.md) + Flowwink’s skill scope (internal/external/requires_approval). All three systems independently converged on layered, human-override-able permissions. This is not coincidence — it is the correct answer to the governance problem.

The Memory System

CLAUDE.md — persistent instructions per project, loaded into every system prompt. This is OpenClaw’s AGENTS.md by another name.
Auto-memory files (~/.claude/memory/) — patterns accumulated across sessions
Session history — ~/.claude/sessions/, resumable and forkable

The architectural parallel to OpenClaw is exact: both use workspace files as the long-term memory layer, both inject them into the system prompt, both allow the agent to modify them.

Teams — True Parallelism

Claude Code has a Teams system built on tmux: a lead agent creates a team, members get separate tmux panes with isolated Claude sessions, and they communicate through a shared message bus.

This solves the same problem as Flowwink’s A2A architecture: one agent coordinating multiple specialized agents on parallel workstreams. Different surface, same pattern.

The Thin Wrapper Problem

Here is the uncomfortable question every founder in this space faces: is your product a thin wrapper?

A thin wrapper is a product that is entirely dependent on a foundation model’s capabilities. It has no logic, data, or user experience that the model couldn’t replicate directly. If Claude or GPT-5 adds the feature you built into their base product, your business evaporates.

The Lovable Case Study

Lovable is valued at $6.6 billion (March 2026) and is actively acquiring companies. It builds full-stack apps from natural language prompts. The product is genuinely impressive.

But the honest question: what is Lovable’s moat?

The model does the code generation (Claude)
The hosting is Supabase / Vercel
The UX is a chat interface with a preview pane
The integrations are standard (Stripe, auth, etc.)

If Anthropic ships a “build me an app” feature in Claude.ai — which they could — what does Lovable have?

The thin wrapper verdict: Lovable, Bolt, and v0 are largely execution environments on top of frontier models. Their current moat is distribution, brand, and user habit. The product quality is real. The defensibility is uncertain.

What Creates a Real Moat

Compare with tools that have genuine defensibility:

Cursor ($2.5B): Built an AI-native IDE from scratch (not just a VS Code extension). Deep codebase indexing that understands your entire repo. The IDE is the product — switching cost is high once your team is embedded.

Claude Code: Anthropic is the model provider. The product doesn’t have to fight the model’s capabilities — it is the model’s capabilities, delivered through a control plane Anthropic controls. No disintermediation risk.

Cline/Roo (open-source): No revenue model to defend. Community-owned. Extensible by design. The moat is ecosystem: the thousands of MCP integrations, custom tools, and operator configurations that make it the most flexible foundation.

Flowwink/FlowPilot: Business data as moat. The agent learns from 18 months of your leads, your content performance, your customer interactions. That accumulated context is not portable. The model can be swapped; the learned business knowledge can’t.

The Pattern

Real moats in the agentic layer come from three sources:

Deep integration — you own the environment where the agent operates (Cursor owns the IDE, Claude Code owns the terminal, Flowwink owns the CMS/CRM)
Accumulated data — the agent’s memory is your data, not the model’s weights
Ecosystem lock-in — community, integrations, and configurations that can’t be replicated by a model update

A thin wrapper has none of these. A defensible agentic product has at least one.

”Anyone Could Have Built Claude Code”

This observation deserves a direct answer, because it’s both true and irrelevant.

Yes — technically, any developer with access to Anthropic’s API and a few months of focused work could have built something in the direction of Claude Code. The architecture is not complex. The concepts (agentic loop, tool system, CLAUDE.md, permission model) are all described in this handbook.

The same is true of most transformative products. Anyone could have built Spotify after the MP3 player existed. Anyone could have built Airbnb after Craigslist proved demand for peer-to-peer rentals. The technical barrier is not the real barrier.

What matters is:

Who recognized the problem worth solving: Anthropic understood that models needed a properly architected terminal agent, not a chat plugin
Who made the design decisions: streaming-first, hook-extensible, layered permissions — each is a considered tradeoff, not obvious in advance
Who built the community: Claude Code’s CLAUDE.md ecosystem, its MCP integrations, its operator community — these took time and focus
Who has the feedback loop: running at scale with real developers gives Anthropic signal no one else has

The real lesson: the window to build a defensible agentic product is open right now precisely because the concepts are known but the implementations are still forming. The developer who reads this handbook and builds the equivalent of Claude Code for their vertical — healthcare, legal, manufacturing — before the foundation labs do it themselves, will own that space.

The window closes. It always does.

The Convergence

Looking across Claude Code, Cline, Roo, OpenClaw, and Flowwink, the same architecture emerges independently:

Concept	Claude Code	OpenClaw	Flowwink
Workspace config	`CLAUDE.md`	`AGENTS.md`	`agent_memory:agents`
Soul/identity	Auto-memory	`SOUL.md`	`agent_memory:soul`
Tool permissions	5-layer model	`TOOLS.md` + policy	skill scope + approval gates
Memory	`~/.claude/sessions/`	`memory/*.md`	PostgreSQL + pgvector
Subagents	`Task` tool	`sessions_spawn`	`agent-execute` parallel
Heartbeat	—	`HEARTBEAT.md` cron	12h Supabase cron
Skills	MCP servers	`SKILL.md` + ClawHub	`agent_skills` DB table

These are not coincidences. This is the architecture of an autonomous agent. Everyone building in this space discovers it.

The question is not whether you’ll arrive at this architecture. It’s whether you’ll arrive at it before or after the competition, and whether you’ll build something defensible on top of it.

The control plane is the product. The model is the commodity. The developer who understands what goes in the control plane — and builds it deeply, with real data and real integrations — is the developer who builds something that lasts.

Next: the ten design laws that emerged from building FlowPilot in production. The 10 Laws →

The Agentic Control Plane