1. The idea, in two lines

When a request reaches Metnos, before bothering the LLM planner we try to recognise it. If we have already seen it and we have already decided well how to answer, we replay it and return to the user in half a second instead of ten. No language models on the critical path, just memory.

2. Why a fast-path is necessary

The Metnos planner is a local Qwen 3.6 35B-A3B: it thinks well but takes about twelve seconds to decide the first step of a turn. For many requests this wait is disproportionate. “What time is it?” does not need an LLM: it needs get_now. Even “download this page and describe it in two lines” does not need the planner if it is a request we make often and whose sequence we already know: get_urls followed by describe_entries.

Hence the question: how do we recognise that a request is already known? And how do we accept that almost known is enough? The answer is the introvertive fast-path, organised in two layers — each captures a different degree of certainty, both converging to the same outcome: the assistant executes the right sequence without thinking twice.

3. The two layers

The flow is strictly sequential: first L0 is attempted, then L1 if L0 missed. If both miss, the LLM planner (Engine v2) takes over as always.

4. L0 — auto-produced cache (fastpath.py)

The first layer lives in runtime/engine/fastpath.py and manages a SQLite database (fastpaths.sqlite) of plans already executed. Entries are produced automatically: every time a turn completes successfully (full plan from the engine, L1 hit, or promotion from cosine 0b), Metnos records the canonical query, its hash, the BGE-M3 embedding, the complete plan (framework) and the intent (verb + object). No approval is needed: the chains are made of executors already vetted and tested.

Two sub-layers of matching

The lookup proceeds in two phases:

• 0a — hash lookup. The normalised query is transformed into a deterministic hash and looked up by exact match. Cost under 5 ms. No language model, no embedding. Hash match is the only path for query-specific plans, i.e. plans with literal arguments tied to the original request (e.g. a proper name as a search parameter): replaying them on a similar but different query would return stale data.
• 0b — semantic cosine. If the hash match fails, the query is transformed into its BGE-M3 vector and compared by cosine against all entries above the configured threshold. This covers lexical variants of the same request (“what time is it” vs “tell me the time”). Cosine match only serves non-query-specific plans, to avoid applying arguments from one query to another semantically close but distinct one.

Safety valves

• Negative feedback: a “✗” feedback from the user deletes the fastpath for that query (last-writer-wins: it recreates on the next successful turn).
• Admin: fastpaths can be deleted from the /admin/praxis console.
• Non-cacheable tools: undo_last_turn and get_inputs do not generate fastpaths, because their semantics depend on the turn context.
• Absolute dates: a plan with literal ISO dates (e.g. since_iso="2026-06-11") is not recorded, because replay on a different day would execute a frozen time window. Relative dates (time_window="today") remain cacheable, because replay re-resolves them correctly.

5. L1 — feedback-promoted autopaths (autopath.py)

The second layer lives in runtime/engine/autopath.py and operates on a different logic: it does not repeat the same query, but generalises to a cluster of intents confirmed by positive user feedback.

When the user gives a “✓” feedback, Metnos records the turn's framework, its hash and the semantic cluster (intent hash + cluster ID). After a minimum number of confirmations (configurable, default 1) on the same framework hash and cluster, the plan becomes a reusable autopath: the next time an intent in the same cluster arrives, the plan is replayed without going through the planner.

Anti-autopaths and champion/challenger

• Anti-autopath: if the user gives negative feedback (3 or more failures), Metnos records an anti-autopath that blocks that plan for that cluster for 30 days. This is a last-writer-wins symmetry: a positive feedback removes the matching anti-autopath.
• Champion/challenger: when multiple frameworks compete for the same cluster, Metnos computes a composite score that favours the plan with more confirmations and fewer failures.

6. Aging, death and inheritance

L0 fastpaths age and die deterministically, with no LLM involved. The nightly task_state_reaper job applies three aging rules and four death conditions.

Aging

Death (only with complete catalogue)

Point inheritance

When a fastpath dies by supersession (C2), its usage counts (n_uses) are transferred to the heir executor via the executor aging system. Accumulated demand is not lost.

7. The arguments extractor

Recognising the request is half the work. The other half is reconstructing the concrete argument values: which paths, which URLs, which date, which threshold. Metnos has a deterministic extractor (args_extractor.py) that works by rules:

• Closed rules. Regular expressions for known types: URL (https://...), path (~/... or /..., with the “home” shortcut becoming ~/), email, numbers, file extensions (“PDF file” becomes *.pdf), dates (today/yesterday/tomorrow/day-after-tomorrow in Italian and English, mapped to ISO format), time windows (“this week”, “last 24 hours”, “last 7 days”).
• Query-specific slot re-resolution. At execution time (and at recording time), query-dependent arguments (such as the mail account and time window) are re-resolved against the current query, not inherited from the cached plan.

8. Configuration

Fast-path parameters are controlled by METNOS_* environment variables. A TOML file (~/.config/metnos/runtime.toml) provides persistent values; the default hardcoded in the module is the last safety net.

Layer 0 (fastpath)

Layer 1 (autopath)

Promotion to executor

9. Promotion to a synthesised executor

When a group of recurring L0 fastpaths shares the same plan structure (framework hash) and the same intent, a nightly job (task_fastpath_promotion) evaluates them as candidates for becoming a full synthetic executor. Promotion is cluster-based, never per-instance: at least 3 distinct fastpaths, 15 cumulative uses and 30 days of age are required. Only multi-step patterns are promoted: single-step ones already have their executor, and the fastpath value there is skipping the LLM, not the plan.

Two promotion tiers

• Tier 1 (default, active). The candidate is emitted as a human-gated proposal in the introvertiva backlog: visible in /admin/proposals and in the unified hub. Approval writes a synt_pending/ marker that starts the full synthesis pipeline (5 stages + test + signing + installation).
• Tier 2 (flag, off). Above a much higher threshold, the system synthesises the executor automatically without human approval. Safety is guaranteed by the fact that the full synt pipeline includes vetting, testing and signing, as for every synthesised executor. Hard cap: 1 attempt per night.

Provenance

Every emitted candidate records the IDs and canonical hashes of the source fastpaths in a promotions table. When the executor enters the catalogue, C2 provenance-based death is exact: the link between the original fastpath and its heir is recorded, not inferred from the name.

© 2026 Roberto Brunialti · Metnos documentation