Managed SaaS onboarding β design preview
πΊοΈ Design preview β planned, not available. The AI Agent Assembly managed SaaS platform has no public signup, no published plans or prices, and no service commitments. Nothing on this page is purchasable or usable today, and nothing here is an offer, a quote, or a contractual commitment.
This page is for readers evaluating whether to wait for a managed workspace or to start on the open-source stack now. It deliberately does not contain onboarding steps.
An earlier version of this page walked through managed-workspace onboarding: tier selection, quotas, region selection, console screens, credential issuance, support channels, procurement, and legal-agreement handling. Those instructions described a service that is not running, so they were removed rather than restated in vaguer language. The SaaS claim publication checklist records each removed claim, the owner who must approve restoring it, and the evidence that approval requires.
For the canonical maturity and visibility label of every area of this hub β including Cloud β see Source of truth & status.
What you can run today
The open-source stack is what ships. It is Apache-2.0, public, and versioned as
v0.0.1-rc (see the compatibility matrix for the exact
component versions that work together).
| To do this | Go here |
|---|---|
| Run the gateway, policy engine, proxy, or CLI | core docs |
| Instrument a Python agent | Python SDK docs |
| Instrument a TypeScript agent | Node SDK docs |
| Instrument a Go agent | Go SDK docs |
| Run a limited-function stack locally with Docker Compose | Docker & containers |
| Read the policy rule schema the gateway evaluates against | Policy reference |
| Step through a working governed agent end to end | examples repo |
The self-hostable stack is limited-function and intended for local evaluation and development. Open core boundary describes which capabilities are in the open-source core and which are intended for the commercial tier.
The onboarding journey this is designed for
Everything in this section is design intent. It names no plan, price, quota, region, retention period, console screen, tenant-identifier format, availability commitment, or date, because none of those exist β see what this page does not publish.
The managed service is intended to deliver 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 enforcement path itself is Apache-2.0 and needs none of them.
The dependency that shapes the whole journey: enforcement does not wait on the control plane. A team adopting the managed service later runs the same gateway, policy engine, proxy and SDK shims it runs today; the managed service is intended to add operator management around them, not to replace them. That is why the available path above is not a stopgap.
What this page does not publish, and why
The managed service is not running, so this hub does not publish:
- Plan or tier names, prices, or what any plan includes.
- Agent, policy, or retention quotas.
- Regions, region selection, or data-residency guarantees.
- Availability, uptime, or support-response commitments.
- Billing, invoicing, purchase-order, or procurement-timeline instructions.
- Onboarding steps that reference a console, signup form, or credential screen.
- Compliance certifications, or the availability of a DPA or BAA.
Each of these is tracked in the publication checklist with the evidence needed to publish it. Publishing any of them before that evidence exists would misrepresent the product.
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 service running and carrying real traffic, 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 Operations (running & onboarding) row β πΊοΈ Planned.
- Claim record: this pageβs
AA-PAGE-METAcarries a single ADR 0033 Β§6Plannedclaim, withplatforms: []and noavailabilityvalue β 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
cloudrepository is private and outside this hubβs public content boundary. A design deep-dive here would describe a system no reader can verify.
Related documentation
- Source of truth & status β which areas ship today and which are planned
- Open core boundary β the open-source / commercial split
- Managed control plane β design preview β planned, not available
- SaaS claim publication checklist β what must be evidenced before managed-service claims return
Open the examples repo and step through a governed
LangChain, LlamaIndex, or bare-OpenAI agent end-to-end.
Registering interest is not a purchase, a reservation, or a commitment by either side. The open-source stack above works today.
Last reviewed: 2026-09-07 Β· AI Agent Assembly Team
Last updated: 2026-09-07 by AI Agent Assembly Team