Archer OS: draft spec for AI agents operating apps under OS authority

Archer OS, a draft 0.1 architecture and specification, proposes an operating environment where AI agents discover, request authority for, and semantically operate installed software under OS-governed policy, aiming to elevate Human-Agent Functional Parity (HAFP) into an OS-level conformance principle. The defining benchmark is the Archer Unseen Pair Test, requiring an unseen agent and app to interoperate without bespoke integration, and the project emphasizes that ability is not authority, separating capability from execution authority.

Archer OS is a draft operating environment and application contract for model-independent AI agents to discover, request authority for, and semantically operate installed software under OS-governed policy. Status: Draft 0.1 architecture and specification. This repository is not a completed operating system, desktop assistant, agent framework, or Linux distribution. AI agents can already call tools, drive GUIs, invoke APIs, and automate workflows, but those mechanisms are usually fragmented across application-specific integrations, framework-specific tool definitions, credentials copied into agents, and brittle screen interaction. Archer OS explores a different boundary: the operating environment, not the model or application, should govern capability discovery, delegated authority, credentials, execution, events, inter-application composition, and audit receipts. The goal is not to protect the proposal from criticism. The goal is to make it concrete enough to fail. The defining benchmark is the Archer Unseen Pair Test: One previously unseen Archer-compatible agent and one previously unseen Archer-native application, with no bespoke pairwise integration between them, should be able to: - discover one another through OS-mediated capability discovery; - understand typed capability schemas; - request and receive permission within a delegated mandate; - invoke semantic operations; - handle structured results, errors, cancellation, and events; - compose the result with another application; - respect denial and revocation; and - produce an auditable receipt for consequential actions. php flowchart TD A "Reasoning / Agent Layer" -- B "Inference Abstraction Layer" B -- C "Capability Broker" C -- D "Guardrail / Policy Enforcement" D -- E "Universal App Protocol" E -- F "Archer-Native Applications" E -- G "Legacy Adapters / Connectors" F -- H "Existing OS / Linux Services" G -- H H -- I "Kernel / Hardware" D -- J "Credential & Secret Broker" D -- K "Audit Log & Receipts" Semantic governance is different from kernel resource management. Archer OS initially targets a cross-platform semantic runtime, an application contract, and a Linux reference desktop environment rather than a replacement kernel. Human-Agent Functional Parity HAFP : material domain functionality available to a human through an Archer-native application's interface should have a semantic agent-accessible equivalent wherever technically appropriate, and both interfaces should ultimately invoke the same underlying application or domain operation. Archer OS does not claim to invent app automation, semantic APIs, capability discovery, OS IPC, agent tools, or human-agent parity as a general idea. It proposes elevating HAFP into an OS-level application conformance principle. Ability is not Authority: exposing a capability does not mean an agent may invoke it. Archer OS separates available capability, user identity, agent identity, delegated mandate, context, risk, scope, and actual execution authority. Model interchangeability: models and agent frameworks are replaceable intelligence providers. Archer OS should be able to broker agents using local models, cloud models, or future systems without making any one model provider foundational. PAPER.md /coachpato/archer-os/blob/main/PAPER.md : position paper and architecture argument. SPECIFICATION.md /coachpato/archer-os/blob/main/SPECIFICATION.md : draft normative specification. principles/ /coachpato/archer-os/blob/main/principles : individual design principles. spec/ /coachpato/archer-os/blob/main/spec : draft technical modules. examples/ /coachpato/archer-os/blob/main/examples : illustrative application contracts and authority examples. docs/threat-model.md /coachpato/archer-os/blob/main/docs/threat-model.md : security threat model. docs/review-plan.md /coachpato/archer-os/blob/main/docs/review-plan.md : public review and Draft 0.2 priorities. PRIOR ART.md /coachpato/archer-os/blob/main/PRIOR ART.md : prior-art review and positioning. rfcs/README.md /coachpato/archer-os/blob/main/rfcs/README.md : RFC process. Please open GitHub issues for: - prior art: show where this already exists; - architecture objections: challenge assumptions with failure cases; - security concerns: use responsible disclosure for actionable vulnerabilities; - specification proposals: suggest concrete contract changes. The issue templates in .github/ISSUE TEMPLATE /coachpato/archer-os/blob/main/.github/ISSUE TEMPLATE ask for the evidence needed to make criticism useful. For sensitive security reports, use GitHub private vulnerability reporting if available, or contact Hello@bid360.co.za . Project contact: Hello@bid360.co.za Code and executable examples use the Apache License 2.0 /coachpato/archer-os/blob/main/LICENSE . Documentation, specification text, diagrams, and prose use CC BY 4.0 /coachpato/archer-os/blob/main/LICENSE-DOCS.md ; see PAPER.md /coachpato/archer-os/blob/main/PAPER.md licensing .