← Lumen overview
03 / Self-building

The platform writes its own apps.

Lumen's most important feature isn't an app — it's the build engine. An embedded AI turns a sentence into a working plugin, and the plugin appears on the phone while the conversation is still open.

ASK

Describe the app

"I want a tile that shows tonight's dinner options and lets me vote." Plain language, from the phone, often while out.

→
WRITE

Structured file writes

The AI replies with tagged write blocks — manifest first so the tile appears immediately, then UI, then an API router if the app needs state.

→
LOAD

Hot reload

Every write is snapshotted for rollback, the plugin registry rescans, and the hub broadcasts the updated app list over WebSocket.

→
USE

It's on the phone

The new tile is live on every connected screen. Total elapsed time: about one model response.

The write contract

The build engine's entire interface is one tag it may emit anywhere in a reply:

<WRITE_FILE slug="dinner-vote" file="plugin.json">
{ "name": "Dinner", "icon": "🍜", "description": "Tonight's options — tap to vote" }
</WRITE_FILE>
  • Manifest-first convention: the tile shows up in the hub before the UI even exists, so the human sees progress instantly.
  • Every write is versioned: the hub snapshots the previous file before overwriting. A bad generation is a one-step rollback, which is what makes letting an AI write production files tolerable.
  • Bounded blast radius: the engine writes into the plugin tree; apps inherit the hub's auth perimeter rather than defining their own.

It can rebuild itself, too

The same contract accepts slug="portal" — the AI can patch the hub server itself. The service manager restarts it on write and picks up the new code. The platform that hosts the build engine is a valid build target of the build engine; several of the hub's own features were added this way, from the phone.

This is the "apps change on the fly" claim, made literal. Not themes or layouts — the actual software inventory of the device is conversational. Wanting an app and having it are minutes apart, and having it everywhere is automatic.

Guarded autonomy: the Nova gate

Self-building is only safe if action-taking is disciplined. The voice assistant runs behind two mechanisms built for that:

  • End-of-utterance detection — a dedicated detector decides when the human has actually finished speaking, instead of firing on every pause.
  • A decision gate with an audit trail — every proposed action is logged with its accept/reject verdict to append-only journals. The assistant is instructed never to claim an action happened unless the platform confirms it did.

A harder loop: coaching against reality

The most demanding AI subsystem is Code Coach: it watches a real monitor over HDMI capture, reads the learner's editor with a vision model, maintains a plan of the solution, and coaches one line at a time. Its 24 shipped versions were mostly lessons in grounding — filtering scaffolding stubs from seeded plans, refusing no-op corrections that would loop forever, and treating "replace" edits whose text already exists as moves rather than duplications. Reasoning against a live, noisy sensor is a different sport from reasoning against text.

Boundary honesty: the build engine is a personal-scale trust model — one operator, one perimeter, rollback everywhere. The Vision page discusses what changes before this pattern is handed to a family or a company.