Local models
Aiming to keep model services in your environment. Network access follows a separate policy.
AOS aims to bring local models, tools and an isolated computer together in an agent environment with explicit state, outcome verification and human oversight.
Explanatory diagram · not a running agent session
Aiming to keep model services in your environment. Network access follows a separate policy.
Tasks, actions and evidence outside chat: typed, persistent and traceable.
Explicit permission boundaries. Approval, rejection and handover are part of the flow.
For an agent, suggesting the right command is not enough. It needs to know what to do, where it may act and whether the result actually happened.
AOS separates these questions: planning proposes a route, policy checks authority, execution uses an allowed tool, and verification tests the result. “Operating system” here means this task environment; it is not a new kernel or Linux distribution.
From creating a fictional file to verifying its contents. Explore the steps at your own pace.
The 19 September 2026 package contains architecture and contracts. Actual models, target hardware, GUI runtime and training remain unverified. Open source is a design goal.
Explore status and acceptance criteria →AOS belongs under HNS. Links to DPL and CUL help connect concepts; they do not indicate running service or data integrations.
AOS’s parent area: explore the relationships between the agent loop, tools, state and evaluation.
DPL ↗Explore decision support and planning roles alongside AOS’s Operator / Supervisor distinction.
CUL ↗Read computer-use concepts alongside AOS’s tool selection, isolated computer and outcome verification.