Concepts

Twelve objects and one boundary that matters.

Everything in Lumium is scoped to an organization and then to a project. Read these twelve in order and the console stops looking like a set of pages and starts looking like one model.

Organization

The tenant boundary.

An organization owns everything shared across projects: people and their roles, agents, the model registry, capabilities, skills, MCP connectors, channels, and secrets. It is also the scope for the ledger sequence, so evidence from different projects can be ordered together.

Project

The work and authorization boundary.

A project holds conversations, artifacts, work items, knowledge, files, and automations. Membership is what grants access: a person reads and writes inside projects they belong to, and an agent only works with the permissions its project assignment grants. Nothing substitutes an owner’s permissions for a project assignment.

Conversation

A project thread, not a private chat.

Conversations are where discussion happens. People and assigned agents post into the same thread, turns run one at a time per conversation, and completed turns rebuild the transcript after a restart. A conversation can link to artifacts and work items, but it does not own them.

Run

One pass through the agent loop.

A run starts with a prompt, walks the agent loop (provider call, tool calls, policy checks, final answer), and ends in exactly one terminal outcome. Runs are the unit of cancellation and evidence: the terminal outcome stays durable in the run record, the authority operation, and the ledger.

Artifact

A project object with immutable revisions.

Artifacts carry a type key, revision history, object-backed content, metadata, and typed relations. Files, boards, and documents are all artifacts, and unknown types stay inspectable instead of disappearing. Because they belong to the project, one artifact can be discussed in several conversations without duplication.

Work item

The canonical record. Boards are a view.

Work items are project-owned records with statuses such as todo, in progress, blocked, awaiting test, done, and cancelled. A board is an artifact view over them. Every mutation writes an immutable project event in the same transaction, which is what lets an agent be notified when work changes state.

Agent

Registered once, assigned per project.

An agent binds a model, a system prompt, and a set of capabilities. It lives in the organization registry and is enabled for a project through an assignment. Changing the assignment changes what the agent may do; it never widens what the person who started the run could access.

Capability

Skills, connectors, and built-in tools.

Capabilities are organization-owned and selected per project. Skill packs carry instructions for the agent, MCP connectors bring external tools, and built-in tools like file read, write, and artifact access ship with the runtime. Every tool call passes an authorization and approval gate and is recorded against the run that made it.

Knowledge

Three scopes, deliberately separate.

Organization documents are shared reference material, project knowledge belongs to a project, and conversation notes stay attached to a thread. Each run assembles context from the scope it is allowed to read, so a project never silently inherits another project’s notes.

Ledger

Evidence with a sequence.

Terminal run outcomes, authority operations, and ledger entries are durable rows. Ledger sequences are organization-wide while entries carry optional project and conversation identifiers, so you can answer both "what happened in this run" and "what happened across the organization" without a separate audit system.

Session

The execution workspace.

A session is the execution record for a project conversation, with leases, a waiting state, ordered prompt inboxes, and immutable terminal state. Cleanup races are handled explicitly, and conversation ownership is checked before a session is reused. Files live in the durable project library, not in the session.

Live transport

One authenticated stream per tab.

Each visible console tab holds a single server-sent-events connection. Pages register the reads they are currently showing; the server validates the scope of every update and flush. Hidden tabs disconnect and resynchronize when they become visible again, and presence is deduplicated across a person’s tabs.