---
title: "Control Plane Overview"
description: "How the control plane is structured today and how the major pieces fit together."
---

Executor is built around one central idea:

- turn connected systems into a durable, discoverable tool catalog
- run TypeScript against that catalog inside a controlled runtime
- keep connection state, auth, execution, and inspection in one local control plane

## One-line architecture

Executor is a local control plane that:

1. stores connected integrations as sources
2. materializes those sources into callable tools
3. exposes those tools to the runtime, the UI, and MCP clients
4. resolves auth and policy at invocation time

## Major packages

### `apps/executor`

The CLI and daemon manager.

Responsibilities:

- start and stop the local daemon
- submit executions
- resume paused interactions
- seed and inspect sources in development flows

### `packages/server`

The local server shell around the control plane.

Responsibilities:

- mount the HTTP API at `/v1`
- mount the local MCP server at `/mcp`
- serve the web UI

### `packages/control-plane`

The product core.

Responsibilities:

- source connection and lifecycle
- auth and credential state
- persistence
- tool discovery and inspection
- execution management
- policy-aware invocation

### Runtime and codemode packages

These packages provide the execution and tool abstractions:

- `packages/runtime-ses`
- `packages/codemode-core`
- `packages/codemode-openapi`
- `packages/codemode-mcp`
- `packages/react`

## The mental model

The current architecture is easiest to understand if you think of it as an adapter-based compiler pipeline:

- adapters ingest external formats and protocols
- the control plane stores a canonical internal representation
- the runtime executes against that representation

That is why executor has strong internal concepts like:

- source bindings
- recipes and revisions
- materialized operations
- schema bundles
- actor-scoped credentials

Those are not UI concepts. They are the durable internal model that lets executor support multiple integration styles without rewriting the core every time.

## What is intentionally centralized

Executor intentionally centralizes a few things that many products split across multiple services:

- local identity and workspace bootstrap
- source connection state
- secret material references
- tool inspection data
- execution history
- interaction/resume state

This is why the UI, CLI, and local MCP entrypoint can all behave like one system instead of separate tools bolted together.

## Why the architecture is shaped this way

The current implementation optimizes for:

- local-first operation
- strong schema-aware tool usage
- reusable connected integrations
- minimal provider-specific logic in the control plane core
- extensibility through adapters instead of one-off execution paths

The rest of the developer docs explain how those goals show up in the current model.