> ## Documentation Index
> Fetch the complete documentation index at: https://docs.skrmir.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> AiOS layered architecture, core components, and key system flows.

# Architecture

AiOS uses a layered architecture across platform delivery and automated agent access.

This page is the **runtime topology view** of the system: it explains access, control, and execution responsibilities at runtime.
It is not the only source for code-layer responsibilities; for the **code-dependency view**, use [Layered Architecture Design](/en/platform/architecture/layered-architecture).

## Layered Design

### Control Layer

* config center for environment and policy management
* scheduler for infra and agent execution resources
* observability center for logs, metrics, and event streams

### Execution Layer

* k3s cluster runtime for AI apps and services
* Agent runtime pool for Codex/Claude/opencode sessions

### Access Layer

* future CLI for automation and CI/CD
* Web UI for visual operations and coordination
* API integration layer (optional)

## Core Data Flow

1. user submits deployment or agent tasks via Web/API and later CLI/UI
2. control layer validates policy and performs scheduling
3. execution layer runs workloads and produces runtime outputs
4. observability layer feeds state back to Web/API and later CLI/UI

## How to Read This Together with Code Layering

* `Access / Control / Execution` answers who enters, who decides, and who executes at runtime.
* `Interface / Usecase / Domain / Infrastructure` answers how code dependencies and responsibilities should be structured.
* The two views complement each other and should not be flattened into one single layer model.

## Current Runtime Mode Notes

The current `cmd/aios` binary serves both as a bootstrap/development bring-up entry and as the persistent control-plane startup path once PostgreSQL is wired.

* `bootstrap`: allows startup without PostgreSQL, but should be read as a bring-up and validation path rather than the full persistent capability set
* `persistent`: requires PostgreSQL and enables the control-plane surfaces that depend on durable task and repository state

For console reads that depend on persistent task access, bootstrap should not be interpreted as "the system simply has no data." Those surfaces are currently persistent-only.

## Planned CLI Reference Commands (Not Yet Implemented)

The repository does not currently ship these commands. They remain illustrative of how a future runtime entrypoint would consume the same platform status and diagnostic capabilities.

```bash theme={null}
aios status
aios infra cluster status
aios agent status
aios diagnose export --output ./aios-diagnose.tar.gz
```

## Related Pages

* [Platform Overview](/en/platform/index)
* [Application Delivery Overview](/en/platform/application-delivery)
* [Layered Architecture Design](/en/platform/architecture/layered-architecture)
* [Configuration Reference](/en/platform/config-reference)