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.
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.