The runtime accompanies a request from its arrival to the final response. It keeps the user's context, selects admitted capabilities, builds or reuses a plan, applies the controls, and coordinates the executors. It is the conductor of a turn, not a universal executor.
A turn begins when Metnos receives a request. It ends when Metnos returns an answer, asks for indispensable information, or hands long-running work to LRE. The runtime immediately associates the request with:
This context bounds everything that follows. One conversation's history is not mixed with another user's history; a device paired to one owner does not become a shared resource; a credential is sought only within the mandate authorised for that turn.
Consider this request: “Read the three quotes in the Purchasing folder, compare their prices, and create a summary table.”
Language models help where understanding or producing language is useful. Schema, identity, authorisation, placement, and signature checks remain deterministic. Proposing a plan is not the same as having the power to run it.
The runtime tries paths from the simplest to the most general:
| Path | When it is useful | What is checked again |
|---|---|---|
| Deterministic rule | For closed operations such as undoing the latest turn or resuming a known dialogue. | Identity, current state, and the specific contract. |
| Fast path | To reuse a successful plan for the same request. | Catalog signatures, variable arguments, and operating conditions. |
| Autopath | To reuse a confirmed, generalised plan for a similar request. | Similarity, absence of embedded personal values, catalog, and full validation. |
| New proposal | When no earlier path is reliable enough. | The entire plan, step by step. |
Fast paths and autopaths are plan caches, not shortcuts around the controls. They retain signatures for the relevant capabilities. When the operating world changes, reuse is no longer valid and Metnos returns to ordinary planning.
Models are selected by function through configurable tiers. The runtime asks, for example, for a model suited to planning or summarisation; it does not depend on a model's commercial name. The effective configuration is visible under System › Models.
A plan is a finite list of typed steps. Every step names an executor in the catalog, supplies arguments that match its schema, and may depend on earlier results. It contains no free-form code to execute.
{
"steps": [
{"tool": "find_files", "args": {"base_path": "~/Purchasing", "pattern": "*.pdf"}},
{"tool": "read_files", "args": {"from_step": 1}},
{"tool": "extract_entries", "args": {"from_step": 2, "fields": ["supplier", "price"]}},
{"tool": "create_files_spreadsheet", "args": {"from_step": 3, "path": "~/Purchasing/summary.xlsx"}}
]
}This example illustrates the shape; it does not promise that every installation has exactly those executors. The generated catalog is the source for installed capabilities.
The validator rejects unknown executors, out-of-schema arguments, references to future steps, and inconsistent combinations. Shared guards may also insert an indispensable producer, align known dependencies, or request a new proposal when an explicitly requested action is missing. They do not add capabilities outside the catalog.
Results are not manually copied into the next step's request. A plan uses two main references:
from_step: N passes the collection produced by step N;{{stepN.field}} passes one value from the result.Before invocation, the runtime resolves these references and checks the final schema again. If a producer returns no data, the consumer does not accidentally receive the result of an older step. A large collection may remain in the scratchpad while the planner sees only a useful, explicitly truncated projection.
Data also retains its provenance. Knowing that a value came from step 2 is not enough to turn it into a local path, a recipient, or an authorisation: the consumer must declare what it accepts, and the runtime must be able to verify it.
Every step crosses the same invocation boundary, whether its plan is new, reused, scheduled, or destined for a remote device. At that boundary the runtime applies the shared controls and records the actual outcome.
If confirmation is required, execution stops before the effect. The proposal must make the action, purpose, destination, and relevant consequences recognisable. The reply is bound to the user and turn that created it, so an old confirmation or one from another conversation cannot resume the plan.
Credentials follow a separate path. The planner may indicate the kind of access needed, but the runtime resolves the secret from encrypted storage and a bounded mandate only at execution time. The value does not enter the plan, model messages, or ordinary records.
Not every request can finish in a single HTTP or Telegram response.
A resumption does not continue blindly. The runtime checks the owner, expiry, dialogue state, catalog, and operating conditions again before proceeding.
LRE distinguishes service presence from work progress. A disabled service continues reporting its presence without executing activities; when no units can run, it avoids opening concurrent workers. Periodic authorization maintenance remains active. Worker count follows demand and central limits, without replacing atomic admission checks. The console separates committed results, errors and skipped items and indicates stale data. Unverifiable usage stops work for safety; it does not necessarily mean the spending limit was reached.
The surface registry and Tutor guide distinguish the engine, queued jobs, pending units and confirmed results: waiting does not imply approval, and a saved result does not imply whole-job completion. Reading states and counters is an informational question, not a request to start operations.
On the Services page, the primary LRE indicator describes the feature, not just its process: gray for confirmed disabled state, green only when enabled and ready, amber while transitioning or unverified, and red for service failure or invalid configuration. Technical details retain process state. This visual distinction changes neither health checks, supervisor decisions nor the persistent feature setting.
The LRE console derives start time from actual attempts in the current revision, not workload creation. A compact table separates completed and total batches in the current phase from the known total across phases, which may grow. The main percentage covers the phase identified as x/y, not time; aggregate percentage remains in technical details. One owner-scoped aggregate read per page derives an indicative finish estimate for the current fully materialized phase, using at least three sufficiently recent results from that same phase. It never adds unlike phases: the whole-job estimate remains separate and available only for single-phase plans. Errors, pauses, an unavailable engine or stale observations produce n.a. with a reason; a job requiring attention takes precedence.
Photo analysis requests schema-constrained model output and validates it again before saving. A truncated response is not a successful result; actual usage remains recorded, without automatically increasing the limit. The domain distinguishes unavailable, truncated, invalid and empty descriptions as recoverable causes; an invalid request schema requires review instead. It does not retry internally: LRE applies the already admitted attempt and effect limits. LRE diagnostics retain only codes declared by the approved output schema and enumerated loader causes, never arbitrary exception text.
In the general engine, exhausting attempts for a recoverable error leads to Needs attention, preserving pending batches and committed results. An unknown cause requires review without automatic retries; explicit permanent errors and contract violations remain non-recoverable. A retry decision grants one attempt, not an unlimited loop. Accounting, authority and effect safety remain mandatory. History may show the approved attempt cause without confusing it with items that produced a negative domain outcome.
Checking empty directories left by interrupted publication uses a shared read lock: concurrent readers do not invalidate the catalog, while writers remain excluded during inspection. Format, ownership, permissions and absence of payload remain mandatory; inspection neither repairs nor removes directories. An LRE attention state stops new blocks from starting but permits already running blocks to save their results.
Parallel execution demand respects each block's tightest required resource and bottlenecks shared across workloads: CPU, disk and VLM capacities are not added when they are needed together. Actual admission remains with the central scheduler. Photo analysis also decodes HEIC without changing originals; an unreadable format remains an explicit error, never an indexed photo. Each complete analysis saves a verifiable private receipt: another attempt within the same generation reuses only results matching the source, models, prompt and folder context. These receipts do not publish a partial index or bypass usage accounting checks.
The list identifies activity and folder when available in the owner's admitted plan; details distinguish the observed phase, running units and workload concurrency limit. These counts are not threads or processes. During initial photo discovery, one unit represents discovery, not the whole archive; totals for later phases are not yet known. Percentage and finish estimate show n.a. with an explicit reason. Job errors remain prominent even when the service is ready.
Temporary SQLite writer contention pauses new admissions with increasing, bounded waits without immediately stopping other lanes. Simultaneous errors count as one failed cycle. Corruption and unrelated failures are not classified as contention. The capability loader distinguishes usage statistics updates from actual availability changes, which still invalidate the verified catalog.
An executor may succeed, return no entries, produce a partial result, or fail. These states are not equivalent. The runtime preserves the distinction and uses it to decide whether to continue, attempt bounded recovery, or terminate.
Recovery does not blindly repeat an action that may already have changed state. It first classifies the error and considers recorded effects. If no safe resumption exists, the response states the limitation. When only one part of a plan fails, successful work remains visible without turning the overall result into false success.
The turn trace includes the chosen path, steps, controls, timings, outcomes, and any undo receipt. It must not contain secrets. Administrators and users see only information compatible with their role and identity.
In one sentence. The runtime does not decide what Metnos can do; admitted executors do. The runtime ensures that those capabilities are selected, controlled, executed, and reported in the same way, no matter which path produced the plan.
A prerequisite preserves the placement defined by verified contracts: when both the search and its preparation are server-only, LRE preparation also runs on the server, independently of a device remembered in the conversation. If either component supports device execution, the requested destination is preserved and remains subject to normal checks. Executor output cannot choose the destination.