Ambient runtime and entity framework for agentic, local-first, and operational software.

Modern systems are increasingly agentic, asynchronous, and operationally complex. Dashboards, notifications, log streams, and chat windows do not scale gracefully as software becomes more autonomous, persistent, and context-aware. Ambisphere explores a different interaction layer: persistent, lightweight entities that make state legible without demanding attention.

The project is in its design / specification stage. The foundational paradigm and per-tier implementation language are decided and recorded in runtime's ADR-0001, and a full draft design-spec suite is in review. The primary output remains specs, research notes, and proposals — code follows once a spec has cleared review.

We believe ambient entities can become a reusable interaction primitive — the way windowing systems, notifications, menus, shells, and chat interfaces each became primitives for earlier generations of software. The thesis is testable: if a renderer-agnostic, persona-agnostic, domain-agnostic runtime can serve both a CI/CD watcher and a storytelling companion without coupling either to a renderer or an AI stack, the primitive holds. If it cannot, we will have learned exactly where the abstraction breaks. Either outcome is a contribution.

The work begins from philosophy and runtime concepts, not implementation. Proposals that drift toward a product category, a single rendering standard, or a vendor stack are reframed or rejected.

• Renderer-agnostic. Sprites, vector, 3D, native widgets — all pluggable. The runtime publishes entity state; renderers subscribe.
• Persona-agnostic. Mascots and assistants are one optional projection, not a built-in concept. Operational entities (a deploy watcher, a build monitor) are first-class.
• Domain-agnostic. Storytelling, CI/CD, observability, accessibility, education, research — none privileged in the core model.
• Local-first and daemon-oriented. A long-running local daemon owns entity state and brokers events. Cloud dependence is opt-in and explicit.
• No transport, AI, or framework lock-in. Event ingestion, AI providers, rendering frameworks, and UI toolkits are all decoupled. Experiments that introduce a hard dependency must justify the choice and propose how to abstract it later.
• Specs before code. Architectural choices are proposed, reviewed, and recorded as specs before implementation. Open questions live inside specs as open questions, not undocumented code decisions.
• Glanceable over interruptive. Entities exist to make state legible without demanding attention. "This is the situation" is easier to express than "stop and look at this."

The core ambient runtime — persistent entity state, semantic event ingestion, state reduction, attention routing, renderer abstraction. Design/specification stage: ADR-0001 fixes the paradigm (capability-gated actor-write / event-log source-of-truth / ECS-read materialized view) and per-tier language (Rust core, best-per-platform renderers, polyglot adapters), with a full draft design-spec suite in review.

→ Vision · RFP · SRS · ADR-0001 · Design spec index · Persona prior art

This organization runs on a small set of conventions designed to keep concept-stage work legible and reviewable.

1. Issues are the unit of work. Every change — spec edit, research note, proposal, future code — starts as a GitHub issue. The factory pipeline (see each repo's .loswf/) routes issues through intake → research → product → planning → review → ship.
2. Specs land in specs/. Draft specs live in specs/drafts/; promoted specs sit at specs/. Specs are markdown, sentence-case headings, fenced code blocks, no marketing voice.
3. Branch and PR for every change. No direct pushes to main. Branches follow kebab-case-issue-NNN where possible.
4. Open questions belong in the spec, not the code. If a decision is undecided, write it as an explicit Open Question in the relevant spec. Don't bake an assumption into a file and hope it's caught in review.
5. Cite prior art. When inspiration comes from an external project (e.g. codex-pets, hatch-pet, claude-buddy), say so explicitly and call out what we adopt and what we reject. The runtime is better when its lineage is legible.

Start with the Request for Proposals. It lists the open areas of exploration: ambient runtime architecture, semantic event systems, state reduction, persona abstraction, renderer abstraction, attention systems, local-daemon patterns, and more.

If you have a proposal:

1. Open an issue in the relevant repo describing the problem and the proposed approach. Don't pre-write a full spec — let intake and review shape the scope first.
2. If the issue clears intake, the factory will route it through research and product framing before planning. This is intentional — concept-stage work benefits from a research and product gate.
3. Once a plan is approved, implementation (spec, code, or both) lands in a branch and goes through review.

If you found something worth fixing now (typo, broken link, dead code):

1. Open an issue with factory:type:chore or factory:type:docs — these route through an abbreviated pipeline that skips heavier planning.
2. Branch, fix, PR.

See CONTRIBUTING.md for the full conventions.

These are the habits that keep concept-stage work tractable. None are negotiable.

• Read specs/VISION.md before proposing anything new. Misaligned proposals get rejected; aligned ones move faster.
• Cite the source. If a design decision is informed by an external project, paper, or conversation, link it.
• Prefer a spec edit over a code change. If the change can be expressed as a clarification or open-question resolution in a spec, do that first.
• Keep specs small. A spec that does one thing well is worth more than a spec that tries to be comprehensive. Decompose.
• Surface non-goals. The non-goals in RFP.md exist because they are the most tempting drifts. New work should call out what it is not doing as clearly as what it is.
• Local-first by default. Cloud-dependent designs must justify the dependency and propose a local fallback.
• No --no-verify on commits. Hooks exist for reasons. If a hook is wrong, fix the hook.

A rendering standard. A transport protocol. A mandatory AI stack. A personality system. A centralized cloud platform. A virtual companion product. A VTuber framework. A game engine. A chatbot platform.

Proposals that drift toward any of these should be reframed or rejected.

Each repo declares its own license. The runtime is currently MIT — see LICENSE.