Clear boundaries.
Connected responsibilities.
Explore the layers designed to turn a request into a plan, an allowed action and a verified outcome.
Defines the goal and permission; takes control when needed.
Turns a request into a goal, scope and success criteria.
Owns the observe → decide → execute → verify loop.
Produces plans, diagnoses, visual assessments when needed and recovery proposals.
Supports selection among finite allowed options.
Checks scope, permission, ownership and current state independently of the model.
Dispatches a validated typed action to the appropriate tool adapter.
Provides authenticated, controlled access to the isolated computer.
A separate workspace for file, application, browser and desktop tasks.
Compares the result with the task’s independent success criterion.
Aims to persist canonical task state and events in SQLite-backed records.
Separates model, adapter, deployment and benchmark identities; routes compatible capabilities.
Target architecture · Select a component to inspect its responsibility and boundary. The diagram is not evidence of running services.
Text equivalent of relationships
- User & human control → Request & scope → Task Normalizer
- Task Normalizer → Typed goal → Operator
- Supervisor → Plan → Operator
- Decision Engine → Selection support → Operator
- Operator → Action proposal → Safety Policy
- Safety Policy → Allowed command → Executor
- Executor → Allowed command → Computer Gateway
- Computer Gateway → Allowed command → Agent Computer
- Agent Computer → Observation → Outcome verification
- Outcome verification → Verification → Operator
- Outcome verification → Record → State / Trajectory Store
- Operator → Diagnosis request → Supervisor
- Registries / Capability Router → Compatible candidates → Decision Engine
- State / Trajectory Store → Reviewed record → Data preparation & quality
- Data preparation & quality → Versioned data → Offline training
- Offline training → Candidate → Held-out evaluation
- Held-out evaluation → Evidence for decision → Explicit release decision
- Explicit release decision → Authorized promotion → Registries / Capability Router
This site explains AOS. The services below are target architecture; the working application will be developed in a separate repository. Read the scope ↗
Two roles.
One control loop.
Supervisor plans. Operator owns the loop. Safety Policy independently allows or stops an action.
One active task, one active action, one computer-input owner. Canonical state is designed to live outside chat in SQLite-backed persistent records.
The right tool.
Through an allowed route.
Access to a more direct tool does not expand authority. Every route is subject to the same policy checks.
- 01Suitable internal API
- 02File, process or Agent Computer shell
- 03Browser DOM / CDP
- 04Accessibility interface
- 05Visual observation, mouse and keyboard
Host shell is a separate administration surface, excluded from the initial autonomous toolset. CachyOS is a target host preference, not a verified support matrix.