LRE is the universal engine Metnos uses for work that is too long or too broad to remain attached to a single chat turn. The workload is recorded, divided into verifiable units, and handed to a supervised worker. Chat immediately returns a receipt; execution continues independently and can resume after a restart.
The LRE core knows nothing about images, mail, databases, or other domains. It consumes registered plans that declare sources, dependencies, output schemas, resources, limits, timeouts, and failure behaviour. A new task type is added as a verified registration; it does not add a special branch to the engine.
The first distributed registration processes image collections and produces questions, solutions, notes, and a formula reference. It is a tested use of the general path, not the definition of LRE. Other workloads can use the same engine once they have equivalent contracts and evidence.
There is no hidden 98- or 980-item corpus ceiling. Each revision does, however, have finite and visible limits consistent with its admitted resources. Large collections advance in batches and reductions instead of accumulating without bounds. If a budget is exhausted, the workload exposes a structured state rather than pretending that coverage is complete.
Each stage declares where and how it may run. A local executor runs on the server; a remote executor runs on a paired device. Either can be deterministic or use a language or vision model. Placement does not determine intelligence: they are independent properties.
Independent units may run in parallel, but they do not create private pools of threads or processes. All concurrency passes through the central scheduler, which enforces global, owner, workload, model, and device limits. “Maximum concurrency” is a ceiling, not a promise to occupy every slot at all times.
| Situation | LRE behaviour |
|---|---|
| Worker or computer restarts | State remains in persistent storage; expired leases and unfinished units are reconciled in bounded batches. |
| A recoverable attempt is interrupted | It may be attempted at least once again, with the delay and attempt number recorded. |
| Two attempts finish for the same unit | Fencing and conditional commit admit one result only for that unit and revision. |
| The same HTTP request is redelivered with the same idempotency key | It returns the same workload instead of creating a second revision or corpus. |
| An external effect has an ambiguous outcome | It is not retried automatically unless it is idempotent or reconcilable; human attention is required. |
The precise guarantee. LRE uses at-least-once attempts and admits one valid commit per unit. It can make an observable effect effectively once when the operation is pure, idempotent, or reconcilable. It does not promise universal exactly once semantics across databases, filesystems, providers, and remote devices.
The admitted plan, inventory, and executor or model bindings are frozen in the revision. An incompatible change creates a new revision instead of silently altering half of a running workload. Results may be reused only when dependency digests match. When one source changes, LRE invalidates that unit and its descendants, not independent siblings.
Pausing prevents new claims while allowing a commit already in flight to finish safely. Cancellation is cooperative and prevents new units from being claimed. Pause, resume, cancel, and error-resolution commands carry both an expected version and an idempotency key, so redelivering a command does not multiply its effects.
workload_id and open /agent/workloads.Disabling the feature stops new submissions but does not delete history or artifacts. Data deletion follows the owner's lifecycle and retention rules. Downloads and views remain scoped to the authorised identity.
The displayed corpus is synthetic and non-sensitive; its operational identifier contains no personal data.