The short version#
An output is something Sidekick or another governed agent produced: a file, draft, bundle, report, patch, replay package, or deployment record.
An artifact is the governed record behind that output. It tells LumenFlow what was produced, which agent or participant produced it, which mission or handoff it belongs to, where it lives, who can access it, and which evidence, replay, or approvals are attached.
A destination is the place an output should land: managed artifacts inside LumenFlow, a code host, a document store, an artifact store, a deployment provider, a connected runtime, or a manual export path.
Managed links are not public hosting#
When a governed agent saves a generated file in managed artifacts, LumenFlow can give workspace members and authorized participants a view, download, preview, or export link. That link is workspace-scoped and governed by your workspace permissions.
It is not a public website, CDN, custom domain, or production deployment.
If you ask Sidekick, an external agent, or a fleet worker to "host this page" and no deployment destination is connected, the truthful result is:
- The agent saves the page as a governed output.
- You get the output or artifact id and a workspace-scoped link to view or export it.
- The agent states that no public hosting happened.
- The agent offers the next deployment destination or manual export path.
How this fits the architecture#
LumenFlow is a governed agent runtime and control plane, not just a chat surface. Sidekick is one first-party surface on the same substrate that can also govern external agents, bridge-backed runtimes, customer fleet workers, and coordinator-led swarms.
The stack is:
Control Plane -> Coordinator -> Swarm Runtime -> Participant Registry -> Agents -> Packs -> Connectors -> Evidence/Replay
| Layer | Plain meaning | What it owns |
|---|---|---|
| Control Plane | The governed workspace and fleet layer | Policy, approvals, budgets, sessions, dispatch, telemetry, artifact records, and workspace access |
| Coordinator | The mission PM layer | Decides when workers proceed, stand down, split, retry, or escalate |
| Swarm Runtime | The multi-agent execution layer | Launching, distributed coordination, participant handoffs, replay publication, and swarm-scale budget enforcement |
| Participant Registry | The agent identity layer | Roles, capabilities, grants, boundaries, inboxes, and escalation posture for every participant |
| Agents | The actual workers and surfaces | Sidekick, hosted workers, external SDK agents, bridge-backed runtimes, customer fleet agents, reviewers, and arbiters |
| Packs | Capability bundles | Domain meaning and allowed next steps, such as Software Delivery deciding whether an output is code, docs, an export, or a deployment candidate |
| Connectors | Your connected tools | Code hosts, document stores, artifact stores, deployment targets, CI/CD, data sources, and other external systems |
| Evidence/Replay | The proof layer | What happened, which participant acted, what was approved, which output changed hands, and what can be replayed later |
The kernel sits underneath this as the domain-agnostic enforcement substrate for policy, scope, tool execution, and evidence receipts.
Artifacts sit across the stack as handoff objects. They are how LumenFlow keeps proof and routing straight while your real tools remain the source of truth for code, documents, and deployments.
What people can build#
LumenFlow-governed agents can help you build:
- software changes with tests and pull requests
- generated documents, summaries, reports, and export bundles
- small static files or HTML pages as workspace-scoped outputs
- replay and evidence packages for audit or review
- workflow definitions and connected-app actions
- deployable code or assets that are ready to hand to a connected destination
They cannot turn an internal output into a public production website by themselves. Public hosting or deployment requires a connected destination, explicit confirmation, and a real URL returned by that destination.
Common terms#
| Term you may see | Plain label | What it means |
|---|---|---|
| Artifact | Output, generated file, export | Something Sidekick or another governed agent produced and saved with a traceable record. |
| Mission | Job, work, mission | A tracked piece of work one or more governed agents are carrying out for you or your team. |
| Runtime | Worker, execution environment | The place where governed work runs, whether hosted by LumenFlow or connected from your environment. |
| Pack | Capability, workflow type | A bundle of rules and tools for a kind of work, such as software delivery. |
| Destination | Connected tool, publish target | The app or service where an output should land. |
| Evidence | Proof, activity record | The record of what happened, who approved it, and which rules applied. |
| WU | Task, change | A scoped software-delivery task with files, gates, and evidence. |
On desktop, these terms should have helper text or info tooltips. On mobile, they should use tap-to-open explanations, inline help, or bottom sheets rather than hover-only tooltips.
Are you competing with Replit or Vercel?#
No. LumenFlow is the governed agent runtime and control plane. It helps Sidekick, external agents, connected runtimes, and fleet workers plan work, use connected tools, follow rules, ask for approval, coordinate handoffs, and prove what happened.
For code and deployment, LumenFlow works with the systems you choose. Your code host remains the source of truth for source code. Your deployment destination remains the source of truth for live public hosting.