LumenFlow as an Agentic OS
LumenFlow is a shared, governed runtime for agents doing different kinds of work. The kernel supplies execution boundaries and evidence; packs supply the tools and domain rules. Software Delivery is one pack among several, and its Git and Work Unit lifecycle is specific to software teams.
The Shared Runtime
Section titled “The Shared Runtime”An agent can reach LumenFlow through a supported surface such as the CLI or MCP. When a tool call is dispatched through the kernel, LumenFlow checks the request against its declared permissions and policy before execution. Permission scopes intersect across workspace, lane, task, and tool. A deny at any applicable policy level wins across workspace, lane, pack, and task, and required approvals can pause a call until an authorized person responds.
The kernel records evidence for dispatched calls and runtime events. Evidence supports review and recovery by preserving what was requested, allowed, and observed. It is an audit record, not a claim that every external side effect can be rolled back or that every provider executes exactly once. Work outside the kernel, including an agent’s own native tools, remains outside this boundary.
Memory and recovery live at more than one layer. Packs can provide domain memory, such as Sidekick’s workspace-local notes. Runtime state and evidence can support resuming or reviewing interrupted work when the relevant runtime and host integration implement that path. This shared foundation does not make every pack’s task automatically resumable.
Packs Give Work Its Meaning
Section titled “Packs Give Work Its Meaning”| Pack | Example | Boundary and current prerequisite |
|---|---|---|
| Sidekick | Keep a personal task list and save or recall useful notes in a workspace. | The pack uses workspace-local .sidekick/ state. Channel bridges need configuration. Routines can create a reviewable plan; execution requires a host scheduler or dispatch integration. |
| Reliability Operations | Investigate an incident by gathering service, metric, log, trace, alert, and timeline observations. | Its seven declared tools are read-only. Network posture is off by default, and execution requires an explicitly registered trusted host adapter and provider configuration. No write-tool remediation is exposed by the manifest. |
| Campus | Review facility inventory, energy, PUE, and power evidence, then prepare a flexible-load recommendation. | Facility observations come from registered local state; missing state returns empty results. The flexible-load job list still uses hardcoded fixture data. Curtailment requires approval and produces a proposal for an external scheduler; LumenFlow does not actuate physical power. |
| Software Delivery | Work through a code change with lanes, isolated Git worktrees, quality gates, and completion evidence. | These tools and the Git/Work Unit lifecycle are specific to the Software Delivery pack. |
Other pack manifests show why declared packages need careful interpretation. Knowledge and Protocol Adapters currently register tools: []; they provide library and contract surfaces, not ready-to-call search or connector tools. In general, a manifest’s tool declaration still needs its trusted host adapter, configuration, scopes, and any required approvals.
Local Workers and LumenFlow Cloud
Section titled “Local Workers and LumenFlow Cloud”The local runtime governs a worker on its machine. LumenFlow Cloud adds fleet operations around enrolled workers: shared desired policy and configuration, readiness checks, approval visibility, job outcomes, bounded retry and parking, and usage accounting. Operators can see when work is waiting for approval or cannot run, then decide what to do.
Cloud benefits depend on explicit version compatibility and adoption. Cloud currently pins released package versions; changes in the local development checkout do not automatically appear in the hosted service. A compatible control-plane contract creates a path for Cloud to manage a worker, but it does not prove that every pack, connector, or new runtime capability is deployed or available to every customer. Model-provider configuration also determines where prompts and data are sent.
Choose the Right Boundary
Section titled “Choose the Right Boundary”Use the shared kernel when you need common permission checks, policy decisions, approvals, runtime records, and evidence. Add a pack for each domain’s tools and task model. Configure trusted host adapters and external integrations deliberately, and keep decisions that affect people, production systems, or physical equipment behind their declared approval and actuation boundaries.
See the pack overview, Sidekick, Reliability Operations, Campus, and Software Delivery documentation for pack-specific setup and behavior.