Pattern: Control Plane Separation

Pattern: Control Plane Separation

Category: Orchestration Source: Internal usage (Paperclip integration, RD-0015) Status: Active

When to Use

When a multi-agent system grows complex enough that the coordination concerns (who does what, when, at what cost, with what governance) need to be separated from the execution concerns (skills, knowledge, processes, tools). Applicable when:

  • You manage 10+ specialized agents with reporting hierarchies
  • Recurring tasks need autonomous scheduling (heartbeats, cron)
  • Cost tracking and budget enforcement matter
  • You need a dashboard view across all agents without disrupting their workflows
  • Clients need governance, audit trails, and approval gates over agent operations

How It Works

Two layers operate independently but connect:

┌─────────────────────────────────┐
│  CONTROL PLANE                  │
│  Orchestration platform         │
│  ─────────────────────────      │
│  • Org chart + reporting lines  │
│  • Task queue + inbox per agent │
│  • Budget caps + cost tracking  │
│  • Heartbeat scheduler (cron)   │
│  • Approval gates + governance  │
│  • Audit trail (immutable logs) │
│  • Dashboard (web/mobile)       │
└──────────┬──────────────────────┘
           │ triggers (heartbeat / assignment / mention)
           │ injects env: API_URL, API_KEY, RUN_ID, TASK_ID
           │
┌──────────▼──────────────────────┐
│  EXECUTION PLANE                │
│  Agent runtime + knowledge base │
│  ─────────────────────────      │
│  • Skills / slash commands      │
│  • Role definitions (role.md)   │
│  • Processes (documented SOPs)  │
│  • Production lines             │
│  • Memory + shared state        │
│  • Domain knowledge (KB)        │
└─────────────────────────────────┘

Lifecycle of a task:

  1. Task is created in control plane (manually, by another agent, or via API)
  2. Task is assigned to an agent and enters their inbox
  3. Heartbeat fires (timer, assignment trigger, or manual invoke)
  4. Control plane spawns the agent's runtime (e.g., Claude Code session) with:
    • Environment variables: PAPERCLIP_API_KEY, PAPERCLIP_TASK_ID, PAPERCLIP_WAKE_REASON
    • Working directory pointed at the execution plane (the repo)
    • Injected coordination skill (agent can call back to read inbox, update status, delegate)
  5. Agent executes using its skills and knowledge from the execution plane
  6. Agent updates task status via API (done, blocked, delegated)
  7. Control plane logs results, costs, and audit trail
  8. Agent process exits — resources freed until next heartbeat

Key principle: the execution plane is unaware of the control plane except through injected context. Skills, processes, and knowledge don't need modification. The control plane wraps them.

Example

The Talent Factory uses this pattern:

  • Control plane: Paperclip instance at localhost:3100 — models 11 factory workers (Oscar, Clara, Elena, Pablo, Riley, etc.) with full org hierarchy, 46 issues (requests + CI backlog), 3 cascading goals, per-agent budgets
  • Execution plane: Talent Factory repo (C:\Projects\talent-factory) — contains all skills (/rd-scan, /qa-regression, /maint-health), role definitions, production line blueprints, knowledge base

When Paperclip triggers Riley's weekly heartbeat:

  1. Paperclip spawns a Claude Code session pointing at the TF repo
  2. Riley checks inbox → sees "CI-0028: Scan cadence enforcement"
  3. Riley runs /rd-scan using skills from the execution plane
  4. Results are written to the TF repo (technology radar, watch list)
  5. Riley updates the Paperclip task status to "done" via API
  6. Paperclip logs the run cost, duration, and audit trail

The TF repo doesn't know Paperclip exists. /rd-scan works identically whether triggered by heartbeat or by the CEO typing it manually.

Tradeoffs

Pro Con
Execution plane stays clean — no orchestration logic in skills Two systems to maintain and keep in sync
Agents work the same whether triggered manually or by heartbeat Control plane is a dependency — if it's down, no scheduled work runs
Dashboard gives CEO-level visibility without disrupting workflows Initial setup overhead: must model org chart, wire adapters, configure heartbeats
Budget enforcement prevents runaway costs Agents need a coordination skill to talk back to control plane
Audit trail captures who did what, when, at what cost Task data lives in two places (repo files + control plane DB)
Mobile/remote monitoring without terminal access Learning curve for the control plane platform

Related Patterns

  • Orchestrator-Workers — the control plane acts as a meta-orchestrator, but workers retain autonomy
  • Multi-Agent Coordination — the execution plane is itself a multi-agent system; control plane adds governance
  • Quality Gates — approval gates in the control plane complement quality gates in the execution plane
  • Shared State — the repo is the shared state; the control plane adds a task-level coordination layer

Factory Usage

  • Paperclip + Talent Factory — primary implementation. Paperclip is the control room; TF repo is the factory floor.
  • Client delivery potential — clients buying multiple digital talents could use this pattern: Paperclip as their control plane, our digital talents as the execution plane. Pre-built company templates via Clipmart marketplace.

Anti-Patterns

  • Merging the planes — putting orchestration logic (task queues, budgets, heartbeats) into the skill layer creates coupling and makes skills non-portable
  • Duplicating knowledge — storing role definitions or process docs in both planes leads to drift; the execution plane is the single source of truth
  • Over-scheduling — heartbeats every 5 minutes on 11 agents burns budget without value; match frequency to actual work cadence