Control Plane

The term comes from networking. A router splits into a data plane that forwards packets at speed and a control plane that decides the routes those packets follow. Cloud platforms generalized the split. In Kubernetes, the control plane (the API server, scheduler, controllers, and the etcd store) makes global decisions about the cluster and reconciles its desired state, while the workloads themselves run in the data plane. AWS draws the same line: control planes handle the administrative create, read, update, and delete operations, and data planes deliver the service's primary function.

Agentic systems borrow the same separation. Each agent runs tasks and calls tools in the data plane. The control plane sits above them and sets how they are deployed, how they coordinate, and the rules that bound their behavior. It exists for the same reason it did in networking: the work and the decisions about the work have different requirements. Agents need room to act, while the organization needs consistent policy, scoped permissions, and a record of what happened. Keeping those concerns in one coordination layer is what lets a team grant autonomy without losing control.

A platform team needs the same dependency upgrade applied across forty services, so they assign the job to an agentic workflow. The control plane decides the order the repos are handled, gives each agent a short-lived token scoped to only the one repository it is working on, and tracks which services are done, in progress, or failed. When an agent finishes a change, the control plane checks the policy for that repo: low-risk services merge once CI passes, but the two services that touch billing hit a governance gate that routes the pull request to a human. No agent makes that routing decision on its own. The control plane does.