Samosya Technical portal →

Samosya · product scope v0.1

A person sets the direction. AI teams do the work.

Samosya is a self-hosted workspace for running complex projects with teams of autonomous AI agents. Conversations, plans, knowledge, code, consoles, reviews and costs are one system — not five tools stitched together by copy-paste.

The Samosya-core container bootstrap runs today. The modules described here are the planned v0.1 scope — see status.

Positioning

Not a chatbotConversation is one view of the work, not the product.
Not a coding agentCode is one artefact among documents, decisions and reviews.
Not a task managerTasks are bound to knowledge, execution, evidence and cost.

Samosya is a complete environment for running a project with human authority and AI execution: from defining the goal, through the work, to the decision and the cost attached to it.

Difference

Eight properties that are hard to bolt on later

Most tools add agents to an existing surface. Samosya assumes from the start that agents work for hours, produce artefacts, spend money and need permission.

01

Authority is explicit, not implied

People set goals, constraints, priorities and the level of autonomy. Agents execute inside those limits. Approval is recorded against a specific version of a result — not against a chat message.

02

Work outlives the browser

Sessions, queues and consoles live on the server. Close the tab and the run continues; reopen and you get the current state, not the state of a stale page. Checkpoints make resumption deliberate.

03

One object model, one truth

Project, Guild, Agent, Session, Task, Run, Knowledge, Skill, Artifact, Review and Budget share identity across every module. No parallel registries, no reconciliation by copy-paste.

04

Knowledge that can be governed

Canon distinguishes binding decisions from proposals, tracks provenance and flags contradictions. Agents receive the context that applies — not the most recent document that happened to be retrieved.

05

Skills instead of repeated reasoning

Repeatable work runs as versioned, testable skills — link audits, component analysis, convention checks. Discovery proposes new skills; humans approve the ones that change data.

06

Budgets are enforced, not reported

Limits exist at organisation, project, task, session and agent level. The system distinguishes estimates, provider-reported cost and confirmed spend, and blocks work when a limit is reached.

07

Review carries evidence

Every result arrives with artefacts, commits, test output, sources and cost. Comparison is before/after, approval is a decision with an audit trail, and rejection sends work back with a reason.

08

Self-hosted and portable

One container, one durable data volume, no cloud dependency in the critical path. Backup, restore and migration are part of the model, not an enterprise add-on.

Capabilities

Twenty modules, six areas of work

The v0.1 specification defines the full catalogue. Below is what each area does in the language of daily work.

The team

Configure roles, competences, models and autonomy. A guild can be a single agent or a coordinated team; its configuration is versioned.

  • Guild Hall — organisation, projects, models, budgets
  • Guild Designer — roles, skills, permissions
  • Agent Runtime — delegation and parallel work

Project and plan

Goals, roadmaps, stages and tasks with dependencies. A task points to its document, agent, session, commit, cost and QA result.

  • Tasks & planning — priorities, acceptance criteria
  • Owner attention — decisions that need you
  • Progress reporting and change history

Governed knowledge

Project documentation and agent governance are separate classes of material. Canon decides what is binding and what is only a proposal.

  • Knowledge — documents, versions, sources
  • Canon — source hierarchy and contradictions
  • Extraction proposes; it never silently rewrites rules

Execution and code

Files, repositories, commits and persistent terminals in the same window as the conversation and the documentation.

  • Code explorer — files, changes, history
  • Consoles — server-side PTY sessions
  • Skills engine — reusable methods of work

Context, models and cost

You know how much context a piece of work consumes and what it costs. Limits apply per organisation, project, task and agent.

  • Prompt composer — write, dictate, refine
  • Context inspector — sources, compaction, checkpoints
  • Budget guard — warnings and hard blocks

Control and trust

Review is part of the process, not an afterthought. Consent applies to a specific result version, not to a message.

  • Review room — before/after and evidence
  • Vault & grants — secrets and per-role permissions
  • Integrations & MCP — tools under policy

How it works

Configure once. Delegate. Come back to evidence.

  1. Define the goal and the teamProject scope, knowledge, permissions, budget and autonomy.
  2. The brief becomes a taskA request is linked to an existing task or creates a new one, within permissions.
  3. Agents executeDelegations, skills, tools and parallel threads with visible progress — no invented percentages.
  4. You return to evidenceArtefacts, commits, tests, sources, cost and decision history.
  5. You approve or send backReview addresses a specific result version and is recorded as a decision.

What happens while you are away

Samosya is built for work that runs for hours without a person watching. Durable queues, checkpoints and explicit states make progress observable and resumption safe. A container restart does not silently replay destructive operations.

What you can always answer

Who did what, on which sources, at what cost, and whether it was approved. That is the product's success criterion — a clear picture of work, results, decisions and spend in one environment.

Control

Least privilege, explicit consent, audit trail

Permissions per object

Access is defined at user, project, guild, agent, tool and resource level. An agent does not receive every secret in the organisation.

Irreversible operations

They require explicit authorisation. Sending a message is not consent to a destructive action — that is a separate decision with its own record.

Traceability

Changes to policies, Canon and guild configuration are logged. Transparency does not mean exposing secrets to people or agents without a grant.

Hosting

One container. Your data. Your infrastructure.

Samosya is self-hosted by design. The product is a single Docker image based on Ubuntu LTS with one durable data area mounted from the host.

  • Docker on Ubuntu Server and other compatible Linux systems
  • Unraid Community Applications
  • Manual installation from an OCI registry
  • The interface as a web page or an installable PWA

What stays with you

Settings, projects, documentation, repositories, sessions, tasks, skills, credentials, artefacts, costs and checkpoints — in one data area.

Updating or recreating the container must not lose that data. Backup, restore and migration to another host are part of the model.

Status

What exists today, and what is planned scope

Samosya is being built in the open about its own state. The scope is published; the deployment is not pretended.

Working

Bootstrap

The Samosya-core container runs on Ubuntu 24.04.5 LTS with Docker, a durable data area and base environment configuration.

v0.1 scope

Modules

Twenty modules, from Guild Hall to System Administration. Implementation order is decided iteratively; nothing here is claimed as shipped.

Planned

Distribution

OCI image, Unraid template and a CLI configurator. There is no public artefact to download yet.

The first production use is an enterprise web programme run with a multi-agent organisation, governed Canon, planning, repository integration, cost control and background work.