Control Plane

The layered architecture of control plane and data plane originated in network device design, where the control plane is responsible for decision-making and coordination, and the data plane is responsible for actual execution.

In the plugin, checking a tool means authorizing the AI to autonomously invoke those capabilities, providing explicit boundary control.

Whether the scalability of hierarchical networks is limited by the topology itself or by the implementation of the control plane, the original HN post did not reach a conclusion.

In the enterprise software context, a control plane usually refers to a unified interface or service layer for centrally managing configuration, permissions, policies, auditing, and costs.

The value of a control plane becomes apparent as the complexity of the agent system increases.

This control plane design only solves the control problem; it cannot prove that a company can run itself, and humans remain responsible for setting direction and stepping in when needed.

The control plane should complete, in order before execution, schema validation, permission checks, idempotency and retry limits, and a persistent state log, and only then reach the external system or API.

In production, inference and execution authority should be separated: the model only proposes action requests, and deterministic application logic validates inputs, checks permissions and records results.

The control plane mints a per-run token, an HMAC signature based on the run id and expiration time, valid for 30 minutes and restricted to a single run.

The author designed the system starting from one rule: the coordinating Agent's service must never be able to read code.

The system consists of two components: the control plane is responsible for managing error messages, configuration, and run history; the Runner is the user's own GitHub Actions runner, which holds the code and the AI keys.

The control plane, as a GitHub App, has only two permissions, Metadata: read and Actions: read & write, and has no Contents permission, so it cannot clone repositories or read files.

The control plane starts workflows via workflow_dispatch, which is the technical fulcrum that makes the rule "the coordinator can never read code" achievable.

In current benchmarks, the recall plane has been extensively benchmarked, while the control plane is far from adequately covered when faced with production systems actually deployed.

The recall plane corresponds to the read path, and its metrics are usually recall, precision, and latency; the control plane corresponds to the write path and lifecycle management, including adding, superseding, revoking, expiring, and purging facts, as well as mechanisms for propagating and acknowledging expired state.

The data plane is responsible for actually forwarding each request, emphasizing low latency and high throughput; the control plane does not touch user requests themselves and is only responsible for distributing and updating configuration.

TheYgent is a local-first AI Agent platform with a two-plane architecture: the inference plane runs models (engine processes, model weights, model registry, API credentials), and the control plane orchestrates Agents (graph runtime, Agent registry, sessions, triggers, MCP servers, retrieval sources, secrets and run traces).

TheYgent's architectural rule is that the control plane never imports the engine, contains no MLX, vLLM or llama.cpp bindings at all, and accesses inference capability only through the inference plane's OpenAI-compatible HTTP API.

In cloud service architecture, the control plane handles configuration, monitoring, billing and policy distribution, while the data plane directly carries users' business requests.

The concept of control plane originates from network engineering, used to distinguish the data plane (responsible for forwarding packets according to rules) from the control plane (responsible for computing routing policies, maintaining topology state, and issuing forwarding tables).