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 as one or more verifiable units and handed to a supervised execution service. Chat immediately returns a receipt; execution continues independently and can resume after a restart. The user describes the desired outcome: Metnos decides automatically whether to use LRE.
The LRE core knows nothing about images, mail, databases, or other domains. It consumes typed plans that declare sources, dependencies, outputs, resources, limits, timeouts, and failure behaviour. In the ordinary path, the runtime builds the smallest possible plan directly from the executor already selected and its final arguments. For established compound workloads it may instead use a plan registered in advance. This is a technical optimisation, not a user requirement or a profile that someone must configure.
The first distributed compound plan processes image collections and produces questions, solutions, notes, and a formula reference. It demonstrates the multi-stage path, but it neither defines LRE nor limits automatic admission: every compatible ordinary executor enters through the same general compiler, without domain-specific code.
What “universal” means. The engine is domain-independent and does not use a list of profiles as a filter. “Universal” does not mean “unchecked”: LRE automatically accepts every long action it can represent without losing arguments, authority, placement, or recovery guarantees. If it cannot do so, the action is not quietly run inline; Metnos explains the limitation.
Metnos first prepares the ordinary plan for the turn. Immediately before execution, one central check examines the final plan and the executor's signed contract. In the first automatic version, an action is considered intrinsically long when its declared maximum duration is at least ten minutes. This decision uses structured metadata, not words such as “long”, “in the background”, or “many files”.
| Condition | Metnos decision |
|---|---|
| The plan contains no action above the threshold. | Metnos uses the ordinary interactive path. LRE is not involved. |
| The plan contains one independent long action; its executor is active, signed, and deterministic; its arguments, effect, and destination can be frozen. | Metnos creates the LRE plan during the turn, queues the workload, and returns a receipt. No profile is required. |
| The long action first requires approval. | Metnos performs the approval step only. After approval, it checks the resumed plan again and, when eligible, hands it to LRE exactly once. |
| The instance switch is disabled. | No new workload enters LRE. Ordinary chat and access to existing workload history continue to work. |
| A long stage is recognised, but the plan contains dependent actions, unresolved references, a model binding that is not fully frozen, or an ambiguous remote destination. | Metnos states that the workload was not started. It neither runs the long part inline nor invents a recovery guarantee. |
| Configuration is invalid or the execution service is unavailable. | Admission fails with a precise explanation. No unit bypasses the check. |
There is no hidden 98- or 980-item corpus ceiling. Each revision does, however, have finite and visible limits consistent with its admitted resources. Plans that expose units and reductions advance in batches instead of accumulating an entire corpus in memory. A monolithic executor remains one unit: LRE can govern its attempt but cannot invent internal recovery points. 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.
The LRE engine supports all these classes through common ports. The current automatic direct path, however, admits deterministic executors only. An executor that uses a model enters when its plan, prompt, model, language, cost, and number of calls have all been frozen by a complete contract, as they are in verified compound plans. This distinction prevents a resumed workload from silently changing model midway through execution.
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. |
In an automatically generated direct plan, a read-only operation may make up to three attempts. An action that changes data has one automatic attempt: if the service stops after invoking it but before recording the result, LRE requests attention instead of risking a second effect.
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.
One activation per instance. The switch under Services does not enable one workload. It determines whether the whole Metnos instance may accept new LRE workloads. It is not a per-user setting and does not need to be changed before each request.
workload_id. You do not need to know or select a profile.Settings → System → LRE whenever you want to inspect state, denominator, budget, stages, and events.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 following boundaries distinguish what LRE can guarantee today from what can be added without losing traceability or safety.
| Current limitation | Practical effect | Correct extension path |
|---|---|---|
| Automatic compound plans | The first automatic version queues one independent long action. A plan with several executable steps or unresolved dependencies is not started. | Compile the whole final plan into LRE's typed graph, with explicit references and checks; do not preserve it as an opaque block. |
| Intelligent executors | The direct path currently excludes language- and vision-model executors without a complete immutable binding. | Freeze prompt, language, model, call limits, tokens, and cost in the same contract, then use the same general port. |
| Implicit remote destination | An executor that can run only on a device is not queued until the exact device has been resolved. | Name the device in the request or add deterministic, verifiable resolution before admission. |
| Monolithic executor | LRE sees one unit and cannot resume halfway through an undeclared internal loop. | Expose the work as general, identifiable, idempotent units or as a batched reduction; do not add domain-specific cases. |
| External effects are not always repeatable | A write to a service or device may have an unknown outcome after interruption. | Use native idempotency keys or an authoritative reconciliation read; when neither exists, stop and request a decision. |
| Finite resources and costs | Each revision has ceilings for units, attempts, time, bytes, tokens, and concurrency. Exhausting a budget stops the workload explicitly. | Tune limits from real measurements and add local or remote capacity through the central scheduler; do not remove the limits. |
| Frozen plan during execution | An executor, model, or source is not silently replaced halfway through a workload. | Create a new revision and reuse only results whose dependencies have not changed. |
The console is the operational record of workloads, not the command that
starts them. Open it in web chat under Settings → System → LRE. The
left panel lists workloads visible to the owner: press Open on
a row to load its revision, progress, limits, stages, events, units, and
artifacts in the right panel. An empty list means that the current identity has
no LRE workloads; if the page is unavailable, inspect the service under
Settings → System → Services. The console does not need to remain
open for execution to continue.
Settings → System → LRE; the entry remains visible in the HTTP UI navigation column.The displayed corpus is synthetic and non-sensitive; its operational identifier contains no personal data.