---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 sources2. materializes those sources into callable tools3. exposes those tools to the runtime, the UI, and MCP clients4. 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/platform/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/platform/sdk` 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/kernel/runtime-ses`- `packages/kernel/core`- `packages/sources/openapi`- `packages/sources/mcp`- `packages/clients/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.