AI Agent Orchestration Platform  ·  View 03 of 32  ·  1 · Context and scope

Control Plane and Execution Plane

The one architectural boundary that everything else on this site depends on.

Editable source SVG draw.io All views
Control Plane · what a run is allowed to be Registries Agent Registry versioned specs Workflow Registry published graphs Tool Registry API Center Model Registry routes and quotas Governance Policy Authoring Rego · versioned Identity and RBAC Entra · scopes Credential Broker Key Vault refs Config Promotion App Configuration Control data Definition Store Azure SQL · HA Bundle Publisher signed · immutable Execution Plane · what a run actually does Orchestration Durable Orchestrator replay-safe Scheduler queue classes Work Queues Service Bus Runtime Runtime Workers stateless · KEDA Policy Sidecar local decisions Session Sandbox Hyper-V isolated Execution data Execution Store Cosmos · partitioned Turn Cache Managed Redis Artifact Store ADLS Gen2 AI Gateway and Tool Broker APIM · shared Observability and Cost Plane Monitor · ADX signed bundle scoped token checkpoint dispatch gateway telemetry Control Plane and Execution Plane — The Governing Boundary Application we own Security / platform Data store Interface / broker Queue / topic event / async synchronous A control-plane outage stops new admissions. Runs already admitted carry a pinned bundle and continue. v 1.0 · owner Data & AI Global Practice · date 2026-08

The decision

  • The control plane owns definitions, configuration, policy, identity, versions and governance. It never runs agent code
  • The execution plane runs agents and workflows. It holds no authoritative definition, only a pinned copy of one
  • The interface between them is a signed, immutable bundle — not a database both sides write to

Why it is worth the extra hop

  • Execution scales on queue depth; the control plane scales on people and CI, which are three orders of magnitude apart
  • Workers can be deployed per region for residency without moving the registries
  • A registry deployment cannot change the behaviour of a run that is already in flight

Consequences accepted

  • A control-plane outage blocks new admissions; in-flight runs continue on their cached bundle
  • Two deployment pipelines and two scaling models to operate rather than one
  • A definition change reaches running workloads only at the next admission, never mid-run