KUOS means Knowledge Universe OS. Its product direction is a knowledge-first, agentic operating environment for organizations that need useful AI without building an internal AI or DevOps team.
Connect your data. Build your AI. Deploy anywhere.
This is the platform direction, not a statement that every journey is available in the developer preview. NixOS supplies the deterministic execution foundation. KUOS defines the product architecture and customer experience.
Six platform capabilities
| Capability | Intended customer result | Inspected implementation |
|---|---|---|
| Knowledge Engine | Add company knowledge and get cited answers | Local Markdown/text keyword index; broader ingestion and cited retrieval remain V1 targets |
| Agent Runtime | Create, configure and test a useful Agent | Role presets and object scaffolding; complete visual builder and team execution unverified |
| Work Engine | Observe and resume multi-step work | Workflow scaffold; current runner does not demonstrate real Agent execution |
| Integration / Sidecar Engine | Connect existing systems without migration | Read-only PostgreSQL business-data journey remains a V1 requirement |
| App Platform | Turn intent into a blueprint, app and preview | External platform specification; integrated KUOS builder unverified |
| System Intelligence | Understand and manage infrastructure | Native Rust diagnostics and advisory capability plans; full approved activation flow pending |
The inspected console kit is version 1.4.2. Website package versions and historical release metadata are separate. Source inspection establishes code presence, not production readiness or successful execution of an entire customer journey.
Knowledge is the starting point
Keep six knowledge domains logically separate:
| Domain | Purpose |
|---|---|
| K0 System | Linux, NixOS and current machine evidence |
| K1 KUOS | Official product and operating guidance |
| K2 Integration | Database, API and business-system connection knowledge |
| K3 Development | Application standards, architecture and testing |
| K4 Industry | Domain terminology, workflows and policies |
| K5 Customer | The organization's own authorized documents and data |
The intended Knowledge Router selects relevant domains rather than retrieving from everything at once. Provenance, citations, ownership, permissions and retention belong to each source. These controls need acceptance testing beyond the preview's local keyword index.
Agents, Skills, Tools, MCP and Work
An Agent is a configurable software object with purpose, knowledge, model policy, skills, tools, permissions and an audit history. A Skill describes a reusable procedure. A Tool performs a typed, deterministic action. MCP connects external capabilities. Work coordinates durable execution, artifacts and review. They serve different roles and must not be treated as interchangeable.
Teams should have bounded parallelism, task depth, budgets and timeouts. The current workflow scaffold is not evidence that complete orchestration ships.
Existing data before replacement
Sidecars are intended to connect databases, CRM, ERP and legacy applications without forcing migration. Read-only is the default product direction. Synchronization and controlled writes require separate permissions and audit. A read-only PostgreSQL customer journey must be demonstrated before it is advertised as available.
Intent before implementation
Company knowledge + User intent
↓
Architect → App Blueprint
↓
Build → Test → Preview
↓
Review → Approve → Deploy → Verify
The Architect should recommend the simplest suitable application type. Rust-first does not mean Rust-only. Simple websites can use HTML, CSS and minimal JavaScript; web applications can use React/TypeScript; desktop interfaces can use Tauri. The website itself uses server-rendered Axum and Askama.
System actions remain controlled
The inspected CLI observes system state and prepares advisory capability plans. Those plans explicitly do not apply changes. The full target transaction is:
Observe → Retrieve → Plan → Validate → Build → Diff
→ Policy → Approval → Deploy → Verify → Record
Agents must not receive unrestricted root access or override deterministic policy. NixOS generations help recover configuration; databases and customer data need separate backups and tested restoration. See the upstream explanation of generations and rollbacks.
Deployment and privacy
The same conceptual platform is intended for local, LAN, on-premises and cloud operation. A temporary Live image, persistent Portable SSD and Installer are separate deliverables. The inspected console build tooling does not establish persistent Portable or a verified public installer. A real Web Sandbox needs isolated sessions, synthetic data, limits and cleanup.
Local-only and approved external model routing are product policy choices. A configured external provider can receive data. GPU is optional in the architecture; model usefulness depends on hardware and installed dependencies. Complete offline and deployment journeys must be tested per release.
Authorship and upstream software
KUOS product architecture and design are attributed to Hui Zhang, Ph.D., Founder and Chief Architect. KUOS ApS is the product owner and commercial entity. NixOS and other upstream components retain their identities, licenses and notices. Attribution does not alter existing source permissions or assign intellectual property.
Read the preview quickstart, feature scope, licensing and FAQ before planning an evaluation.