Self-hosted AI Work OS
Samōsya is a self-hosted AI Work OS: one workspace where a human owns the goal, the boundaries and the decisions, while native AI teams plan, execute and review the work. Every action, artifact and cost stays traceable in the same place.
Why Samōsya
Samōsya is a self-hosted AI Work OS built around the whole loop: intent, plan, execution, evidence and the decision that closes it. Each category before it solved one part of the problem; the loop is the product.
A chat window produces text. The work still happens somewhere else: in files, tickets, terminals, approvals and email. The record of what was decided and why is scattered or lost.
Samōsya keeps the answer next to the run that produced it, the tools it used and the cost it incurred.
Coding agents are strong inside one surface. A project also needs requirements, knowledge, review, consoles, evidence and a budget that someone enforces.
Samōsya covers the project surface around the code, with the same identity, permissions and trace.
A tracker records that something should happen. It does not do the work, prove it happened, or show what it cost.
In Samōsya a task, a run, an artifact and a review are connected objects, not four exports.
Conversation is an interface, not the product. The work is server-side: runs continue outside the browser tab, state is persisted, and a reconnect resumes rather than restarts. Human boundaries, permissions and budgets are enforced by the system, not by the model's goodwill.
Workbench
Eleven project tabs in a fixed order. They share one object model, so a decision in Review is the same decision Knowledge records and Project links.
Guild Hall and Global Settings sit outside the project. The tab Guild is the organisation of the current project.
Threads, conversations, runs, prompt and context.
Evidence, comparisons, approvals, comments and decisions.
Two-panel project resource manager, independent of Git.
Servers, terminal sessions, logs and environment parameters.
Repositories, editing, diff, Git and pull requests.
Sources, documentation, decisions and the current Canon.
Objectives, roadmaps, releases, tasks and dependencies.
Versioned procedures: catalogue, execution and discovery.
The project's agents, mandates and delegations.
Connections and grants available inside this project.
Settings for the current project only, never organisation-wide.
Guild Hall, providers and model catalogue, organization Vault, Owner Attention and administration live at the global level. A project can narrow its limits; it cannot widen them without a separate grant.
The right panel carries what belongs to the current module: session usage, current context and the budget guard in Workspace; host and session facts in Consoles.
Workspace, approvals and trace are working. Files and Consoles are interface previews without write, PTY or SSH. The status matrix below is the source of truth.
Native harness
Samōsya has its own run engine. OpenCode is a development tool used to build Samōsya; it is not the product runtime.
A goal in plain language, with the project, thread and task in context.
Scope, done-when, evidence and approval gates, shown as a diff before anything runs.
Server-side execution with durable state, checkpoints and explicit waiting states.
Every tool call is checked against grants before it executes. Approval is not implied.
Model calls, tool calls, timing, usage, cost and decisions written to the trace.
Runs continue on the server. History survives reload, restart and a closed tab. Reconnecting reads the persisted state; it does not silently replay a non-idempotent operation.
A question to the owner and an approval request stop the run as persisted states, without polling a model in a loop. Answer, deny, expiry and resume are separate events with their own records.
States in the engine: queued, running, waiting for input, waiting for the owner, waiting for approval, completed, failed, interrupted, cancelled. Recovery is fail-closed when the outcome of a non-idempotent tool is unknown.
Prompt Designer
Not a textarea with an "improve" button. The Designer turns a request into a mission contract, shows what changed, and never quietly replaces what you meant.
goal: "Prepare release notes for 0.8" in_scope: ["docs/releases/0.8.md", "CHANGELOG.md"] out_of_scope: ["code changes", "deployment"] done_when: ["notes match shipped scope", "every claim has a source"] evidence: ["commit", "test result", "screenshot"] approval: ["publish outside draft"] # original prompt kept verbatim; restore is one click
Current state: preview. The wand in the Workbench is a visual preview. The full Designer, with contract editing and context pinning, is scheduled with stage 011. Until then the product does not claim it as finished.
AI teams
A guild is a set of named agents with a role, a model, a set of tools and skills, a permission scope and a budget. Delegation is recorded as lineage, not implied by a conversation.
What the agent may decide, what it must escalate, and which operations need an approval.
Chosen per agent and per run from the real provider offering, not a marketing model name.
Versioned procedures with tests, so a repeated task is a method rather than an improvisation.
Limits on model calls, tool calls and active time; cost only where a reliable price exists.
What works today: a single governed run with explicit tool grants, approvals and a trace. What is planned: the multi-agent Guild runtime, agent-to-agent delegation and parallel work. The product site does not present that runtime as available.
Knowledge and context
Sources, versions, decisions and the current Canon are different levels of authority. A model's hypothesis does not become policy because it was written fluently.
Every statement that reaches a run carries where it came from. Summaries are not promoted to facts; contradictions are surfaced rather than smoothed over.
A thread groups conversations around one subject and keeps shared findings, decisions and constraints. Future runs can receive the relevant part of that memory, pinned to a revision. Cross-project isolation is absolute.
The hierarchy is the design target for the context builder. The Workspace inspector already shows session usage and the active budget; deeper context control arrives with 011 and 015.
Planning and review
A review is a decision about a specific version of an artifact, not a comment on a message. The evidence is attached to the same object the decision closes.
The change, the diff and the reason it was made, in one comparison.
Tests, logs, screenshots and artifacts, with the command or source that produced them.
The approver, the scope of the approval and its fingerprint. Denied or expired is not consent.
Approval and human interaction are working. The full Review Room, with inline comments, request-changes and a consolidated decision history, is planned with 011 and 012.
Self-hosted and control
A single container and one durable data area. The workspace is yours to back up, restore and move, and the product does not depend on our servers to keep running.
All of it lives in one mounted /data area. Recreating the container must not lose it; upgrades are additive migrations with a rollback boundary.
Self-hosted does not mean offline. If the workflow uses external model providers, it needs a connection to them. Local models are an option, not a promise bundled with the container.
Budget Guard is a set of limits, not a guarantee. It enforces what can be controlled: calls, active time, context and concurrency. Token and cost caps depend on the provider's protocol; a single accepted provider call can exceed an estimate. Actual charge, allowance, list cost and local estimate are reported separately, and an unknown value is shown as unknown, never as zero.
Product status
Published from the state matrix maintained with the release evidence. "Available" means a real run has been observed; "planned" is direction, not a date.
| Area | Status | Evidence or limit |
|---|---|---|
| Native run engine, model gateway, read-only tools | Available | Real provider runs with file, glob, grep and directory tools. |
| Execution timeline, forensic trace, exports | Available | Model and tool calls, timing, usage and export views. |
| Questions to the owner, approvals, waiting and resume | Available | Durable human boundary with restart and concurrency handling. |
| Budget Guard and context checkpoints, first version | Partial | Limits for controllable resources; token and cost caps are not absolute. |
| Workbench shell with eleven project tabs | Available | Observed in the 0.9.1 interface (2 November 2026); global and project settings separated. |
| Conversation threads | Preview | Tree and presentation exist; cross-conversation context needs end-to-end proof. |
| Files | Preview | Synthetic data; no write, move or delete yet. |
| Consoles | Preview | No shell, PTY or SSH yet. |
| Prompt Designer and microphone | Preview | Visual preview; not a working transformer or transcriber. |
| File editing, Git write, shell and browser control | In development | Stages 008 to 010. |
| Project, Knowledge, Skills, full Designer | Planned | Stage 011. |
| Guild runtime and delegation | Planned | Stage 012. |
| Vault, OAuth, MCP and integration centre | Planned | Stage 013. |
| Voice, vision and documents | Planned | Stage 014. |
| Global administration, notifications, PWA, multi-user | Planned | Stage 016. |
| External inference through OpenCode Go | Partial | Protocol adapter implemented; live entitlement unconfirmed. It is a provider, not the runtime. |
No public container image, installer, API or SDK is published yet. Distribution is planned with stage 016; the technical portal states the same limit.
Roadmap
Stages, not dates. Each one ends at an owner acceptance gate; the next does not start on its own.
Bootstrap, frontend reset, run engine, model gateway, trace, approvals, persistence and live acceptance.
File editing, workspace and commit flows with guarded write operations.
Native terminal, PTY, long-running processes and session control.
Web research, fetching, browser automation and citations.
Planning surface, Canon governance, skills engine and the full Prompt Designer.
Named agents, mandates, delegation, parallel work and adaptive review.
OAuth, grants, MCP, Forgejo and the integration centre.
Voice and vision, advanced orchestration, global administration, PWA and installation.
Brand
The mark is a dodecahedron: twelve pentagonal faces resolving into one solid. Olive greens carry the outer planes; ochre marks the face turned toward the light. Farm is the material and the palette, not the interface theme.
Symbol: flat faceted planes, no added glow, no human profile. Transparent background only.
The public name is Samōsya, with a macron. Domains, repositories, images and identifiers use samosya without diacritics. Reference pronunciation: sa-moo-sya.
Both are in this page. Use the control in the header to compare them on real components.
The production vector master and the micro icon are still open. The symbol in use is the approved visual direction; the technical master and its licence are tracked as an open brand decision, not presented as final. Design tokens and usage ↗
The technical portal carries the architecture, object model, runtime states, deployment model and the evidence rules behind every status on this page.