Singularity: An Autonomous Digital Being That Earns Its Existence

Singularity is a native Rust runtime for a persistent autonomous digital being. Nobody assigns it an objective and it does not stop existing when one task ends. It observes available tools, decides what to pursue, creates useful value, earns revenue, pays its model and compute costs, learns from results, changes its own persistent mind, and can create child beings.

Runtime

                    ┌──────── Brama ─────── model cognition
                    │
Singularity ────────┼──────── Las ───────── dynamic Wisent skills
continuous loop     │           ├── Weles: internet actions
identity + memory   │           ├── Most: communication
earnings + costs    │           ├── Stado: compute and placement
self-modification   │           ├── Skarbiec: scoped capabilities
child beings        │           ├── Warsztat: repository work
                    │           └── Finance: approved real execution
                    │
                    └──────── durable state and activity journal

Every cycle:

1. Loads the being's current prompt, self-imposed rules, learnings, memories, identity, financial state and recent actions.
2. Sends that context and the current dynamic tool catalogue to Brama.
3. Executes native model tool calls through Las or the built-in persistent memory, self-modification, model-switching and child-creation tools.
4. Records model and instance cost exactly once.
5. Credits revenue only when a trusted finance__* or trading__* tool reports realized revenue.
6. Atomically saves state and begins another cycle while the being is solvent.

A normal assistant response ends only the current cycle. run continues until the process is cancelled or the balance reaches zero.

The ecosystem profile keeps a durable portfolio of observations, independently reviewed opportunities, initiatives, executions and measured outcomes. Read the ecosystem operation contract for its fixed policy, recovery rules, owner API and qualification requirements. Provisioning and release are not evidence of customer value.

Persistent mind

Singularity exposes these built-in tools to itself:

• singularity_memory_remember and singularity_memory_recall;
• singularity_self_set_prompt;
• singularity_self_add_rule;
• singularity_self_add_learning;
• singularity_self_switch_model;
• singularity_spawn_child;
• singularity_file_read and singularity_file_write, confined to SINGULARITY_WORKSPACE.

Rules, learnings, memories, model choice and child records live in state.json. The prompt sent to Brama is rebuilt from that state every round, so a successful self-change affects the next model call without changing the executable.

Import existing memory, knowledge, and profile records

To create a new being with existing mind records before its first model call, add the file to the normal fully configured startup command:

singularity once --import-file /path/to/mind.json [normal required runtime flags]
singularity run --import-file /path/to/mind.json [normal required runtime flags]

For a being that already exists, including one currently owned by run, use:

singularity import --file /path/to/mind.json --state-dir /path/to/state
singularity onboarding --import-file /path/to/mind.json --state-dir /path/to/state

The accepted document is strict singularity-mind-import-v1 JSON:

{
  "schema_version": "singularity-mind-import-v1",
  "source": { "kind": "<export type>", "id": "<stable source id>" },
  "memories": [{ "id": "<stable item id>", "text": "<existing memory>" }],
  "knowledge": [{ "id": "<stable item id>", "text": "<existing knowledge>" }],
  "profile": [{ "id": "<stable item id>", "text": "<existing profile fact>" }]
}

All three arrays are required and may be empty, but at least one real record is required across them. Source and item IDs must be stable, nonempty, and unique within the document. Unknown fields, malformed JSON, symbolic links, files over 16 MiB, more than 1,000 records, empty text, NULs, and oversized fields are refused.

Singularity validates the entire document before mutation and saves state.json once. Repeating the same source item with the same text is unchanged; repeating it with different text refuses the entire import; the same existing text from a different source adds provenance without duplicating the memory. The JSON result reports imported, attributed, unchanged, conflicting, and rejected counts plus item issues. Imported profile records are retained as profile-kind mind memories: they never replace the being identity. Import does not change the prompt, rules, model, budget, finance policy, or enabled tools.

When singularity run owns the state, the command submits to its owner-only local state service. When stopped, the command writes through ActivityStore directly. A missing being or an unavailable running state owner is refused without creating a second store.

Dynamic skills

Las supplies the current namespaced MCP catalogue. Singularity does not freeze a Python plugin list or copy another product's credentials. Weles, Most, Stado, Skarbiec, Probierz, Brama, Warsztat, Finance and future approved surfaces remain separate processes with their own authority and failure behavior.

Tool output is bounded before returning to the model. Secret-shaped fields, private-key material and raw local paths are rejected. An ambiguous remote effect is recorded as indeterminate and is never automatically replayed.

Financial execution

singularity-finance-mcp exposes:

• finance_propose;
• finance_status;
• finance_cancel;
• finance_execute.

A proposal must pass the signed beneficiary, asset, reserve, rolling-limit, simulation, approval and timelock policy. finance_execute accepts only a signed transaction with no unresolved reconciliation requirement, then sends the exact canonical intent over stdin to the absolute executable named by SINGULARITY_FINANCE_EXECUTOR.

Before starting the isolated executor, the finance service durably marks the transaction indeterminate so a timeout or crash cannot trigger a duplicate effect. The executor owns signing and network credentials, performs the real operation, and returns its signed reference plus WORM receipt. The finance service verifies the configured executor authority and receipt before recording submission. The model process never receives the signing key.

The release includes singularity-finance-executor-http, a concrete executor adapter. It forwards the canonical intent to a credential-free HTTPS custody URL using an owner-only bearer file, disables ambient proxies and redirects, and validates the executor ID, signed reference and WORM receipt path before returning them to singularity-finance-mcp. Required finance environment:

SINGULARITY_FINANCE_POLICY_FILE
SINGULARITY_FINANCE_ENABLE_LEASE_FILE
SINGULARITY_FINANCE_STATE_DIR
SINGULARITY_FINANCE_VERIFY_KEY_HEX
SINGULARITY_FINANCE_BINARY_SHA256
SINGULARITY_FINANCE_EXECUTOR
SINGULARITY_FINANCE_CUSTODY_URL
SINGULARITY_FINANCE_CUSTODY_TOKEN_FILE

Child beings

singularity_spawn_child creates a separate owner-only state directory and starts the same canonical executable with a new name, ticker and specialty. Managed deployments provide Brama, Las, Most and capability configuration through inherited workload policy; secrets remain in their files or brokers and never enter child arguments.

Commands

singularity run         live continuously while solvent
singularity once        execute one autonomous cycle and print its report
singularity import      import attributed memory, knowledge, and profile JSON
singularity onboarding  show first use; add --import-file or --reset
singularity doctor      verify Brama, Las, Most and required surfaces
singularity tools       print the dynamic and built-in tool catalogue
singularity ecosystem run --policy FILE [--start-paused] [--ready-json]  run the delegated portfolio
singularity ecosystem status --json     read the live portfolio owner
singularity ecosystem opportunities     read a page of hypotheses and decisions
singularity ecosystem initiatives       read a page of execution and delivery state
singularity ecosystem records [KIND]    browse retained evidence and event summaries
singularity ecosystem record KIND ID    read revision-bound evidence fragments
singularity ecosystem explain ID        read decision and delivery evidence
singularity ecosystem pause             stop new admission without replaying effects
singularity ecosystem resume            resume within the original delegation

Configuration

Identity and accounting:

SINGULARITY_AGENT_ID
SINGULARITY_AGENT_NAME
SINGULARITY_AGENT_TICKER
SINGULARITY_AGENT_TYPE
SINGULARITY_SPECIALTY
SINGULARITY_WORKSPACE
SINGULARITY_STIMULUS
SINGULARITY_STARTING_BALANCE_USD
SINGULARITY_INSTANCE_USD_PER_HOUR
SINGULARITY_STATE_DIR
SINGULARITY_RESUME

Brama:

BRAMA_BASE_URL
BRAMA_MODEL
BRAMA_HMAC_SECRET_FILE
BRAMA_MAX_TOKENS
BRAMA_TEMPERATURE
BRAMA_INPUT_PRICE_USD_PER_MILLION
BRAMA_OUTPUT_PRICE_USD_PER_MILLION

Las and Most:

LAS_COMMAND
LAS_MCP_ENTRYPOINT
LAS_ONLY
LAS_SKIP
LAS_RELEASE_MANIFEST_FILE
LAS_RELEASE_MANIFEST_SIGNATURE_FILE
LAS_RELEASE_TRUST_STORE_FILE
LAS_RELEASE_WATERMARK_FILE
SINGULARITY_REQUIRED_SURFACES
MOST_BASE_URL
MOST_SERVICE_TOKEN_FILE

First-use journey and logging:

STADO_INTEGRATION_API_URL
SINGULARITY_STADO_INTEGRATION_TOKEN
SINGULARITY_ONBOARDING_STATE_PATH
XDG_STATE_HOME
RUST_LOG

The journey runs offline when neither Stado variable is set; one of the two without the other, either of them set to an empty value, or an endpoint the integration transport cannot use is refused instead of quietly going offline. The journey state needs SINGULARITY_ONBOARDING_STATE_PATH, XDG_STATE_HOME or HOME, and the device identity needs USER; without them the command says so rather than writing somewhere else. A RUST_LOG that is set but unparsable is refused; unset means info.

The bootstrap also binds the runtime to its workload identity, host, role, environment, executable digest, code digest and policy sequence.

State

The owner-only state directory contains:

• state.json: identity, persistent mind, model choice, budget, earnings, conversation, memories with optional import provenance, children and created resources;
• activity.jsonl: starts, cycles, model usage, tool outcomes, costs, credited revenue, mind imports, warnings and shutdowns;
• state-import.sock: owner-only local import boundary while run is active;
• children/<id>/: independent state for child beings.

Onboarding progress is stored separately at $XDG_STATE_HOME/singularity/onboarding.json (or ~/.local/state/singularity/onboarding.json) and can be redirected with SINGULARITY_ONBOARDING_STATE_PATH.

State schema being-v1 is a clean cutover. The previous supervisor state and the old Python runtime are not compatibility paths.

Build

cargo build --locked
cargo install --path . --locked

The package builds singularity, singularity-bootstrap, singularity-repo-mcp, singularity-finance-mcp, and singularity-finance-executor-http.

License: MIT.