Atlas universal runtime contract
Status: normative architecture guardrail for every Atlas capability and surface.
Status: normative architecture guardrail for every Atlas capability and surface.
Implementation status: this document defines the target contract. It does not implement the universal runtime. The complete delivery plan dated 2026-09-17 maps the existing code, remaining work, dependencies and acceptance scenarios for PR #1277.
Product contract
Atlas is the conversational kernel of BoostEcom, not a chat-only assistant. A request may continue after the operator changes page, may delegate to specialists, may produce several artifacts, and may surface on Chat, Workflow, WorkTree, Preview, store pages or an external API without becoming a different job.
The durable identity of that job is a Run. Messages are one projection of a Run; they are not the runtime itself.
Universal primitives
| Primitive | Contract |
|---|---|
| Objective | The operator's desired outcome, decomposable into several intents and skills. |
| Capability | A native tool, skill, prompt, workflow, connector, MCP server, agent, marketplace package or human/partner service. |
| Context | Store, organisation, conversation, memory, knowledge, files and current surface, retrieved only when relevant. |
| Policy | Permissions, autonomy, risk, budget, approval and tenant boundaries enforced outside model prose. |
| Run | Durable, resumable execution with parent/child relationships and concurrent branches. |
| Event | Append-only observation of planning, delegation, progress, approval, correction, completion or failure. |
| Artifact | A durable result: image, video, report, graph, benchmark, theme section, block, code patch, sandbox preview, store preview or appointment. |
Capability lifecycle
Every provider is normalized into one registry and exposes independent state:
available— known to the platform or marketplace;installed— selected for this organisation/store;connected— credentials or transport are healthy;authorized— user, store, policy and budget allow this action;active— selected for the current run phase.
The toolbar may boost or constrain discovery, but it must never be the only way a capability exists. A direct request in Chat, Voice, API, Canvas, WorkTree, Preview or a page action must resolve the same capability.
Installation is itself a capability. Atlas can propose and, with the appropriate approval, install tools, skills, prompts, workflows, agents, connectors and MCP packages from the conversation, then resume the same Run.
Run and event invariants
- Leaving a page never cancels a durable Run. A surface subscribes and unsubscribes; execution ownership stays server-side.
- Atlas may continue the conversation while child Runs execute in parallel.
- Delegation creates child Runs with their own model, context, tools, cost and events. The parent receives summaries and artifacts, not an unbounded dump of child context.
- Every meaningful background action is visible as progress, may request clarification or approval, and may be corrected or cancelled according to policy.
- Tool calls are evidence. Surfaces collapse plumbing by default but keep it inspectable.
- Completion requires verification against the objective, not merely a successful tool response.
- Conversation history, Run events and artifacts are durable and reloadable. Context windows may be compacted; the record is never discarded.
Human and marketplace capabilities
Humans are first-class capability providers. A marketplace partner may expose discovery, availability, appointment booking, brief handoff, delivery, review and payment actions behind the same permission and approval gateway as an API tool. Atlas chooses AI execution, approval-gated execution or a human handoff based on requirements; the operator does not need to switch products or rebuild the brief.
Surface projections
All surfaces consume the same Run events and artifacts:
- Chat renders the objective, concise progress, approvals, questions and deliverables.
- Workflow renders phases and dependencies as nodes and edges.
- WorkTree renders files, diffs, tests, agents and sandbox state.
- Preview renders store/theme artifacts with an action toolbar and rollback.
- Store and organisation pages render context-specific actions and live results.
A capability implementation must not depend on the surface that invoked it.
Reference implementation in this change
Product-faithful Studio composition demonstrates the contract on a bounded capability:
- discovery comes from the objective; the composer toggle is only a hint;
- Shopify or an attachment provides the authoritative source artifact;
- the model generates the scene and, when required, a segmentation mask;
- server code composites original product pixels and verifies them;
- Chat renders the stored artifact and fidelity result without exposing raw tool JSON.
This is intentionally the first vertical slice, not a second Studio-only runtime. Subsequent durable Runs, marketplace installation, partner appointments, sandboxes and multi-agent work must reuse the primitives and invariants above.
The Studio implementation still needs integration validation. Its current pixel check covers opaque pixels selected by the mask; it does not prove semantic segmentation quality or that the entire product was retained. The delivery plan records this distinction and the routing, dependency and test corrections required before acceptance.