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.
Start here: govern your first tool action. Install, run one local workflow, inspect allowed/denied/unknown outcomes in the CLI and console, then connect a staging tool.
Choose your starting point
| Your goal | Start here |
|---|---|
| Understand the core workflow without cloud credentials | First tool action: one install, setup check, CLI run and browser inspection. |
| Provision local compute/storage and run an agent | Environment walkthrough: editable plans with UI and CLI steps. |
| Govern a tool your team already uses | Integrations: register one staging operation, review, approve, invoke and revoke. |
| Require a different person to approve an action | Action approvals: request, review and execute through the CLI and console. |
| Resume a LangGraph workflow through AOS | LangGraph integration: durable checkpoints and governed action execution. |
| Run AOS for a team | Identity and governance, then deployment and recovery. |
Getting started · Downloads and access · Product questions
End-user guides
| Guide | Outcome |
|---|---|
| Getting started | Download, verify and install the package; run the Python-only reference check. |
| Environment walkthrough: UI and CLI | Customize a plan, provision compute/storage, run an agent and demonstrate governance with shared state. |
| Integrations | Connect model providers, cloud-facing APIs, third-party apps, MCP and A2A through supported contracts. |
| Identity and governance | Configure OIDC claims and roles, edit policy, preflight, review, activate and revoke. |
| Deployment and releases | Configure a shared server/runtime, retain evidence, upgrade and recover. |
| Security and evidence | Review untrusted content and independently verify configured signed exports. |
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 uses HTTP/OpenAPI tool execution. The integration guide describes the other implemented protocol adapters and their qualification limits.
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.
- If the operation requires action approval, a different reviewer approves that exact request. AOS checks the caller, permissions and current 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
Get the package from Downloads, then follow the installation guide.
The package includes the CLI, API, operations console and execution runtime under Apache-2.0. The local walkthrough uses development identity; use the identity guide to configure a shared deployment.
Protect evidence through review
Recorded agent and tool content is untrusted. The audit viewer displays it as text, and configured deployments can export one snapshot with its matching signed checkpoint. Verify the export outside the viewer with a separately approved key and retain it independently.
Read Security and evidence for the CLI commands, key requirements, deployment responsibilities and limits. Signing is not configured by the default local evaluation, and a signature does not prove that an agent’s report is true or that bypass actions were captured.
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.