← Documentation index Architecture guide › planning engine

Metnos

Planning and reuse engine
Four layers sharing one control pipeline.

The engine tries reusable plans first and builds a new framework when necessary. The model's proposal remains probabilistic; cache signatures, validation, guards, and executor semantics are enforced by code. There is therefore no promise of “one model call” for every turn: the number depends on the path, validation, and possible recovery.

Contents

  1. Purpose
  2. Engine contract
  3. The four layers
  4. The turn cascade
  5. The framework
  6. L0: fast path
  7. L1: autopath
  8. L2: validator
  9. L3: proposal, execution, and recovery
  10. Feedback and aging
  11. Using it from chat
  12. Limits of the guarantees
  13. Praxis console

1. Purpose

The engine turns a natural-language request into a finite sequence of admitted capabilities. It balances two requirements:

Ask Metnos with a request like this example: “Find PDFs changed this week under Projects, compute each file's SHA-256 hash, and create a spreadsheet with the name, date, and hash.” The first run may need a new framework. A repeated request is reused only if the plan remains cacheable and its operational-world signatures still match.

2. Engine contract

Input includes the request, ordered intents, visible catalog, language, user, channel, destination, and state already produced in the turn. Output includes:

The caller supplies the catalog, which defines the execution world. Prompt text cannot make an absent or unadmitted executor available.

3. The four layers

LayerStateResponsibility
L0 — fast pathPersistentMaps a query to a framework that previously succeeded effectively.
L1 — autopathPersistentMaps semantic clusters and intents to a generalizable framework.
L2 — validatorPer turnChecks names, schemas, required fields, and references before execution.
L3 — full enginePer turnProposes, finalizes, executes, classifies failures, and terminates.

L2 is not a separate lookup: it sits between a new proposal and execution. L0 and L1 plans still cross the current finalization pipeline, which applies guards, ordering, output policy, and consent gates.

4. The turn cascade

  1. Routing builds a pool of relevant capabilities.
  2. L0 tries an exact match and then—only for generalizable frameworks—a semantic match.
  3. If L0 does not answer, L1 looks for an active champion compatible with the intent, object, and cluster.
  4. Without a valid hit, the selected proposer produces one or more candidate frameworks according to configuration.
  5. Structural guards and the validator inspect the candidate and, in admitted cases, request one corrective proposal.
  6. The shared executor runs the framework. If it fails without committed effects, recovery may try an alternative.
  7. The terminator presents the result, asks for input, or states an honest limit; an effective cacheable turn feeds L0 and L1 observations.

5. The framework

The canonical format is independent of the proposer:

{
  "steps": [
    {"tool": "find_files", "args": {"base_path": "Projects", "pattern": "*.pdf"}},
    {"tool": "compute_signatures", "args": {"from_step": 1}},
    {"tool": "create_files_spreadsheet", "args": {"from_step": 2}},
    {"tool": "final_answer", "args": {}}
  ],
  "fillers": {},
  "final_message": ""
}

from_step and ${stepN.field} placeholders connect data without asking the model to copy it. The runtime can insert internal values through ${RUNTIME:key}. Configuration fields marked runtime_resolved, such as the default account or client, are not chosen by the proposer; the user context resolves them.

6. L0: fast path

L0 is created automatically after a successful, effective, cacheable turn. It does not require an approval button. Lookup has two forms:

Plans dependent on turn context—such as dialogs, consent, undo, and authenticated web sessions—are excluded. So are absolute time values that would become stale. Before replay, executor and candidate-family signatures must match. For mutations, discriminating argument values must also be grounded in the current request.

7. L1: autopath

L1 retains observations of cacheable frameworks together with intents, clusters, timings, and feedback. Positive feedback can promote a framework to an active champion. For repeated long pipelines, the runtime may create a shadow champion: it is served with the same guards but remains explicitly distinct from a plan confirmed by the user.

Semantic matching respects canonical-object boundaries and a relevance floor. L1 also rejects query-specific frameworks and validates catalog signatures on every hit. Repeated negative feedback can demote a champion and create a temporary anti-autopath; later positive feedback can remove the corresponding exclusion.

8. L2: validator

The validator is enabled by default and uses no model. It checks:

If it finds an error, the proposer may be called once with the failed framework fingerprint excluded. The new candidate crosses the deterministic guards again.

9. L3: proposal, execution, and recovery

The proposer is selected through configuration. Supported variants share the same Proposer contract; they may generate one candidate or several alternatives and rank them. A grammar, when enabled, constrains output shape but does not make the model's semantic choice deterministic.

The executor resolves references, fillers, and runtime values, checks step conditions, and invokes each capability. Independent steps run in parallel only when their contracts and preflight admit it. External effects remain variable: networks, filesystems, providers, and content can change between executions.

Recovery separates structural from operational failures. It may change a plan for a wrong tool, wrong arguments, or missing input; it does not pretend to repair a network outage. If a step has already committed a mutation, the whole pipeline is not repeated, and the result reports the partial outcome honestly.

10. Feedback and aging

Feedback evaluates a turn outcome; it does not directly train the model. L0 may remove the rejected query's shortcut. L1 updates its observation, champion, and anti-autopath. Maintenance removes unused, demoted, expired, or dead-catalog rows.

This memory stores operational decisions and structured observations. It is not a biographical user profile and must not become a source of open-ended preferences injected into the planner.

11. Using it from chat

People do not need to know L0, L1, or executor names. They describe the desired outcome in natural language. For example:

Ask Metnos with a request like this example: “Compare the files in the Quotes and Contracts folders and show those with identical content but different names.”

Inspecting or flushing caches instead requires the web chat: open Settings and choose Praxis. If the question starts on Telegram, Metnos must explain this path and state that the console is not part of the Telegram client.

12. Limits of the guarantees

13. Praxis console

/admin/praxis shows the persistent layers: L0 fast paths, active or demoted L1 autopaths, observations, and anti-autopaths. It can delete an individual L0 row or flush L0, L1, or both. Flushing is an administrative, non-reversible operation: it removes accumulated operational capital and may slow requests until the caches are rebuilt.

The caches are operational at instance scope and contain no credentials. On replay, account, language, consent, target, and authorization are resolved again in the current user's context.

Code references: