What is LumenFlow?
LumenFlow is a shared runtime for governing what AI agents can do. Its kernel checks permissions and policy for calls routed through it, can pause work for approval, and records evidence. Domain packs add the tools and workflows for particular kinds of work.
Software delivery is one pack. Git, Work Units, lanes, worktrees, and software quality gates apply when that pack is installed; they are not requirements for every LumenFlow use.
One Kernel, Different Packs
Section titled “One Kernel, Different Packs”The kernel provides shared execution and governance. Packs define domain-specific task types, tools, policies, and evidence. A pack’s tools still need the right host integration, configuration, scopes, and approvals before they can run.
| Example | What the current pack can do | What it depends on |
|---|---|---|
| Personal assistant | Sidekick can keep workspace-local tasks and notes, then recall saved memory. | The Sidekick pack and its local storage; channel integrations require a configured bridge. A routine can produce a reviewable plan, while a host scheduler or dispatch integration is needed to run it automatically. |
| Reliability investigation | Reliability Operations declares read-only service, incident, metrics, logs, traces, alerts, and timeline tools. | An explicitly registered trusted host adapter and configured provider access. Network access is off by default. The pack does not expose write-tool remediation. |
| Facility operations | Campus can read registered facility, inventory, energy, PUE, and power evidence, and produce an approval-gated flexible-load proposal. | Local facility state and integrations. Missing facility state produces empty results. Flexible-load job examples are fixtures, and LumenFlow proposes curtailment; an external scheduler decides whether to actuate it. |
| Software delivery | The Software Delivery pack governs code tasks with lanes, Git worktrees, gates, evidence, and completion. | A configured software repository and its delivery policy. Its Git and Work Unit lifecycle belongs to this pack. |
Some packs are still libraries and contracts rather than ready-made tools: Knowledge and Protocol Adapters currently register no kernel-callable tools. A declared capability is not the same as a configured integration.
Shared Governance
Section titled “Shared Governance”For calls sent through the kernel, permission scopes intersect across the workspace, lane, task, and tool. Deny-wins policy applies across the workspace, lane, pack, and task, and approval requirements can stop a call before it runs. Kernel-dispatched work produces evidence about the requested and enforced action. Saved state and recovery depend on the runtime and the pack’s integrations; an agent’s native tools outside LumenFlow remain outside this boundary.
LumenFlow also includes memory and recovery surfaces, but their behavior depends on the pack and runtime in use. Sidekick memory, for example, is workspace-local and separate from software delivery coordination memory.
Local Runtime and Cloud Fleet
Section titled “Local Runtime and Cloud Fleet”The local runtime provides the governed worker and its domain packs. LumenFlow Cloud can manage enrolled workers with shared policy, readiness, approval visibility, job outcomes, and accounting. Those benefits depend on compatible versions and explicit adoption. New development in the local runtime does not automatically mean the Cloud service already runs that code, and an external model provider may receive data according to its own configuration.
Learn More
Section titled “Learn More”- Agentic OS architecture — shared runtime, pack boundaries, evidence, approvals, and current limits
- Kernel Runtime — how the kernel dispatches and governs tool calls
- Packs — how domain-specific extensions work
- Sidekick Pack — workspace tasks and memory
- Reliability Operations Pack — configured read-only investigations
- Campus Pack — facility evidence and proposals
- Software Delivery Pack — governed software work
- Get Started (Humans)
- Get Started (Agents)