Lembic
Build notes
[ 0.1 product design ]

The product model, with the build status attached.

Lembic 0.1 is under active implementation. This page explains the product direction, which core foundations exist today, and which interactions are designed but not yet built. It is not an install guide; there is no public package today.

Core foundation · in development
[ 01 — Current build ]

Core foundation, not a public release

The authority, execution, and evidence foundation is in development. A working source tree is not the same thing as a packaged product, and the broader product surfaces are designed but not yet built.

Implemented in private source

Provider support, native tools, agent definitions and grants algebra, evidence chaining and recovery, permission checks, scheduling, the engine loop, and context compilation exist in source. Most of the current Consistency scope is also implemented.

In development

The resident service and the current Consistency-verification scope are still being completed and validated. The core foundation is working source, not a public package.

Designed, not yet built

Alchemist conversation and authoring, Magnum Opus execution, the Approval Inbox, schedules, the full domain CLI and Dashboard, sandbox hardening, Lembic Code, ADE, Adjudication, and Assay are documented product direction rather than current features.

There is no public Homebrew tap, shell installer, or winget package. Commands on this page describe the 0.1 interface contract; they are not a download claim.

[ 02 — Designed first run ]

The target path into the Agent OS

This is the intended 0.1 experience as packaging and the designed surfaces arrive. It is deliberately labelled as product design, not as a runnable tutorial.

01

Start from one resident system

lembic

The designed TTY entry opens the Ultimate Dashboard; a non-TTY invocation prints concise usage. The server, agents, definitions, schedules, and inbox persist independently of any client.

02

Set the machine ceiling

onboarding ≤ 3 user steps

The user configures provider access and the Alchemist’s machine-ceiling grants. With no key present, the target is precise guidance rather than a stack trace. The exact onboarding prompts are not yet implemented.

03

Give the Alchemist work

lembic ask "<request>"

The target front door starts an Alchemist session. For recurring or multi-step work, it presents real Agent and Magnum Opus definitions, then runs the first Opus attended under grants and approvals.

[ 03 — Domain model ]

Six concepts that carry the system

These names are product primitives, not decorative vocabulary. Their meanings stay consistent across storage, protocol, CLI, Dashboard, Code, and ADE.

Alchemist
The machine’s distinguished resident root agent: one per Agent Server, persistent across sessions and reboots. It is the primary interface, automated author, operator, and memory of practice. It is itself an Agent and cannot widen its grants or resolve approvals.
Agent
A reusable, content-addressed definition — an artifact, not a process. It is the unit the Alchemist authors, the node a Magnum Opus binds, and the security subject a Distill runs as. Its canonical definition hash is its identity.
Magnum Opus
A content-addressed workflow definition: a directed acyclic graph whose nodes bind Agents to tasks and declare the policies needed to run. Its authority can only narrow the grants of the Agents it binds.
Distill
One bounded execution with its own lifecycle and append-only Evidence chain. Sessions, Magnum Opus runs, nodes, direct tasks, and proof runs are all Distills, which gives every surface one uniform activity model.
Grants
The monotone capability ceiling for filesystem, execution, network, tools, delegation, budget, autonomy, and later remote access. Layers compose by meet only. Being outside is a hard deny; being inside never bypasses rules or approvals.
Evidence
The per-Distill append-only JSONL record, chained with BLAKE3 and treated as machine ground truth. Operational indexes and views must be rebuildable from it. Its classes are full, delegated, and remote, so reduced visibility is stated rather than hidden.
[ 04 — Target command grammar ]

One public command, several designed modes

The grammar below is transcribed from the 0.1 Surfaces design. The full domain CLI and Dashboard are designed, not yet built; this table does not claim they are available in the current foundation.

Designed commandTarget behavior
lembic
Ultimate Dashboard on a TTY; concise usage when invoked non-interactively.
lembic code [path]
Lembic Code, the designed coding surface; native mode is the target default.
lembic ask "<request>"
A one-shot, scriptable conversation with the Alchemist.
lembic <noun> <verb> …
Domain CLI for agent · opus · distill · approval · schedule · workspace · proof · service · config · doctor.
lembic serve
Run the server in the foreground for development.
lembic service install|…
Manage the designed resident system service.
lembic verify|prove <id>
The target proof entry points for a Distill identifier.

Binding surface rules: the command is always lowercase; CLI and TUI are modes of the same product; the Dashboard opens only from bare invocation; non-interactive commands never wait on an invisible prompt.

Follow the implementation, not an install prompt.

The build log is the honest next step while the core foundation develops toward a packaged release.

Read build status