<div class="hero">
  <div class="hero-panel">
    <div class="hero-kicker">AAAX Kernel</div>
    <h1>Governed multi-system runtime for agentic software.</h1>
    <p>AAAX is an exokernel-style control plane built on top of <code>sssn</code> and <code>lllm</code>. It does not replace either framework. It gives them a stable operating layer for module docking, mediated capabilities, action authorization, lifecycle control, and first-class application composition.</p>
    <p><a href="/getting-started/">Get started</a> or jump straight to the <a href="/architecture/overview/">architecture overview</a>.</p>
  </div>
  <div class="hero-panel">
    <h2>Stack</h2>
    <div class="stack-block">Productive Suite and other AAAX applications
|
AAAX
|
LLLM and other LibOS adapters
|
SSSN</div>
    <div class="hero-grid" style="margin-top: 0.9rem;">
      <div class="hero-card">
        <strong>What AAAX owns</strong>
        Governance, trust, docking, lifecycle, mediated actions.
      </div>
      <div class="hero-card">
        <strong>What AAAX does not own</strong>
        Transport semantics, raw LLM runtime semantics, or provider APIs.
      </div>
      <div class="hero-card">
        <strong>First citizen</strong>
        Productive Suite is the reference AAAX application, not a kernel dependency.
      </div>
      <div class="hero-card">
        <strong>Default LibOS</strong>
        LLLM is the default application runtime, loaded in strict boot mode.
      </div>
    </div>
  </div>
</div>

## Why AAAX exists

`sssn` gives you systems, channels, transport, and topology. `lllm` gives you tactics, packages, prompts, and runtime loading. AAAX sits above both and answers the missing operating questions:

- Which modules may join the constellation?
- Which side effects are allowed?
- Which resources are capability-mediated rather than topology-mediated?
- How do you revoke, pause, or drain a module coherently?
- How do you expose a stable application contract without coupling that contract to framework internals?

## The six kernel functions

1. Constellation management for docking and wiring systems.
2. Capability issuance for mediated resources such as executors and remote channels.
3. Action gate authorization for side-effecting requests.
4. Module loading under policy.
5. Lifecycle control for revoke, pause, resume, and drain.
6. Bootstrap of the default LibOS and protocol channels.

## Current implementation status

The current package implements the first kernel slice:

- bootstrap, kernel, config, and CLI entry points
- governance channels and mailbox replies
- default rule policy engine
- capability manager and action gate
- module loader with a minimal LLLM-backed `TacticSystem`
- cooperative lifecycle handling
- tests for boot, docking, capability issuance, action gating, and non-Productive-Suite boot paths

## Design contract

!!! note
    AAAX does not pretend local in-process topology is the same thing as cryptographic capability enforcement. Local SSSN wiring is still topology-based. AAAX capabilities are for mediated resources and AAAX-owned execution paths.

!!! note
    AAAX treats `lllm` as a LibOS, not as a kernel. The bridge forces deterministic boot and avoids ambient runtime discovery by default.

## Install

```bash
pip install aaax
```

Then launch a kernel with a TOML config:

```bash
aaax launch aaax.toml
```

## Next steps

- Read [Getting Started](getting-started.md) for installation and boot.
- Read [Kernel Functions](architecture/kernel-functions.md) for the control-plane model.
- Read [Framework Boundaries](architecture/framework-boundaries.md) for upgrade isolation and subsystem contracts.
