AOS Core helps engineering teams govern agent-initiated tool actions: check identity and permissions, apply policy, approve capabilities, dispatch execution, and retain evidence of the outcome.
The CLI and API are the primary interfaces. The operations console is optional.
Release status: active development. These guides describe the 0.2.0-rc5 evaluation candidate. They do not declare general availability or production readiness.
Getting started · Downloads and access · Product questions
What is the product?
AOS Core is a governance control plane with an execution runtime. It works alongside your agent framework, models, tools and infrastructure. The control plane decides whether a governed action may proceed; the runtime performs authorized work through configured providers and reports evidence.
The first workflow covered here is HTTP/OpenAPI tool execution. Other protocols and deployment options require their own validation before you rely on them.
The components
| Component | What it does |
|---|---|
| Control plane | Manages identities, registered capabilities, policies, approvals and execution records. |
| Runtime | Receives authorized work, calls the configured provider and reports the result. |
| CLI and API | Let operators and automation configure the product and inspect outcomes without the console. |
| Evidence | Links requests, authorization decisions, execution receipts and reported outcomes. |
How a governed action works
- Register a tool’s declared capability and review its contract.
- An authorized reviewer approves the exact capability and policy digests.
- An agent or operator requests a declared operation.
- AOS checks the caller, permissions and applicable policy before dispatch.
- The configured runtime executes permitted work and reports the outcome.
- Operators inspect the receipt and supporting evidence, including any uncertainty.
Only actions routed through AOS are governed by it. Direct credentials or network paths around AOS must be restricted separately in your environment.
Understand the outcomes
| Outcome | What to do |
|---|---|
| Completed successfully | Review the recorded result and evidence for the requested action. |
| Denied or failed | Inspect the reason and receipt. A denied request should not reach the provider; an execution failure may require further investigation. |
| Unknown | Reconcile with the provider and runtime records before attempting the action again. A lost response does not prove that nothing happened. |
An idempotency key identifies one logical request. It is not proof that an external effect occurred, and it is not a substitute for investigating unknown outcomes.
Start through the CLI
After receiving and verifying an evaluation package, follow the Getting started guide. It installs the package in an isolated Python environment, runs a local reference workflow, and exports allowed, denied and unknown outcomes.
For an authenticated installation, the main operator commands are:
aos product account status
aos product capability list
aos product runtime nodes
aos product runtime workloads
aos product billing status
aos product --help
These commands require the server URL, tenant and token file for that installation. The getting-started guide supplies those values for the disposable local example.
Product access
The intended commercial model is paid access, with complimentary access available only when explicitly issued by the product team. Pricing, package limits and the customer delivery service are being finalized. The presence of these public guides does not grant a product subscription or a permanent free entitlement.
The current evaluation candidate uses development-only identity and local state. Its internal evaluation labels are not the commercial offer.
Preparing for production
The initial production target is self-hosted Linux with PostgreSQL, HTTPS and an external OIDC identity provider. A deployment also needs runtime identity, provider credentials managed outside source files, explicit network access, reviewed policies, backups, monitoring and tested recovery.
Kubernetes installation packaging exists, but the chosen deployment must pass independent installation, security and recovery checks before it is supported. Model, provider and infrastructure costs are separate unless an offer explicitly includes them.
Use the Downloads page to check release availability. For product or deployment questions, use the contact form and describe your workflow without including tokens or credentials.
