Keyboard shortcuts

Press ← or β†’ to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Managed control plane β€” design preview

πŸ—ΊοΈ Design preview β€” planned, not available. The AI Agent Assembly managed control plane (Cloud) is not running. There is no workspace to provision, no console to log into, and no service, support, or compliance commitment attached to it. Nothing on this page is an offer or a contractual commitment.

This page is for enterprise platform, security, and procurement readers who need to know what the managed control plane does not yet provide, so they can plan against the open-source stack instead of against an unavailable service.

An earlier version of this page documented the managed platform as if it were operating: a region list with data-residency guarantees, tenant provisioning paths, per-tier quotas, SSO and SCIM configuration walkthroughs, a console budget form, an availability-and-support SLA table, card and invoice billing setup, and the handling of Data Processing Agreements and Business Associate Agreements. None of those had a running service, an approved commercial policy, or a legal review behind them, so they were removed rather than reworded into softer promises.

Every removed claim is listed in the SaaS claim publication checklist, together with the owner who must approve restoring it and the evidence that approval requires. Source of truth & status carries the canonical maturity label for Cloud and for every other area of this hub.


What runs today instead

Governance enforcement is open source and does not depend on the managed control plane. The gateway, the policy engine, the sidecar proxy, the eBPF sensor, the SDK shims, and the aasm CLI are Apache-2.0 and can be run locally.

ConcernWhere it is documented today
Running the gateway, proxy, sensor, and CLIcore docs
Bringing up a limited-function stack with Docker ComposeDocker & containers
Health probes and Prometheus metrics for that stackSelf-host observability
The policy rule schema the gateway evaluates againstPolicy reference
Spend capsPolicy reference β†’ budget β€” per-agent and per-organisation USD limits declared in policy
Authentication that exists todayAPI keys, as described in Open core boundary
Which capabilities are open source and which are intended for the commercial tierOpen core boundary

The console budget form this page previously described did not match the budget schema the gateway actually validates against. Policy reference is the source of truth for budget behaviour.


The control-plane design this is intended for

Everything in this section is design intent. It names no region, tenant format, quota, plan, price, SLA, or date, because none of those exist β€” see what this page does not publish.

The managed control plane is intended to add the operator-management capabilities that sit on the commercial side of the open core boundary: identity federation, directory-driven user provisioning, longer-lived and higher-assurance audit storage, audit export into external security tooling, and regional deployment control. The reason managed delivery is the intent rather than a self-managed distribution of the same code: multi-tenant infrastructure and on-call operation are what a self-managed install does not get for free.

The dependency that shapes the design: enforcement does not wait on the control plane. The gateway, policy engine, proxy, and SDK shims a team runs today are the same ones a managed workspace would run underneath β€” the control plane is intended to add operator management around them, not to replace them.


What this page does not publish, and why

Because the managed control plane is not running, this hub does not publish:

  • Regions, region selection, or data-residency guarantees.
  • Tenant or workspace provisioning steps, or a tenant-identifier format.
  • Plan or tier names, prices, or per-tier quotas for agents, policies, or audit-log retention.
  • SSO (SAML 2.0 / OIDC) or SCIM 2.0 configuration instructions, endpoints, or supported-operation matrices.
  • A console role model, or group-to-role mapping instructions.
  • Availability, uptime, or support-response commitments, or service credits.
  • Billing, invoicing, payment-method, purchase-order, or payment-terms instructions.
  • Compliance certifications, or the availability of a DPA or a BAA.

Publishing any of these before the corresponding service, owner approval, and evidence exist would present an unavailable service as a defined one. The publication checklist names the evidence required for each.


What must be true before any of this is published

This hub does not decide when a planned area becomes available; the SaaS claim publication checklist does, one claim class at a time. Each register row names the evidence required and the approval owner who must sign the specific wording.

Two things gate the whole page rather than one row: the managed control plane running and carrying real tenants, and the status map moving this area off πŸ—ΊοΈ Planned. Until both hold, no register row can be satisfied, because every one of them requires evidence produced by a running service.


Evidence

  • Maturity: Source of truth & status’s Cloud (SaaS control plane) row β€” πŸ—ΊοΈ Planned.
  • Claim record: this page’s AA-PAGE-META carries a single ADR 0033 Β§6 Planned claim, with platforms: [] and no availability value β€” the metadata form for a capability present in no published artifact.
  • Removed claims and their restoration conditions: the publication checklist register.
  • There is no implementation to link: the cloud repository is private and outside this hub’s public content boundary. A design deep-dive here would describe a system no reader can verify.


Last reviewed: 2026-09-07 Β· AI Agent Assembly Team


Last updated: 2026-09-07 by AI Agent Assembly Team