A skill determines whether a group of capabilities is available. An execution backend determines how a capability reaches a local store or a concrete provider. Planning and authorization keep these two planes separate.
Ask Metnos with a request like this example: “Which skills are active, and which are dormant?” Metnos reads the current registry and shows each skill's state, prerequisites, and associated executors. You do not need to know a command name.
To select a provider for one operation, name it in the request: “Find the 2025 budget on Google Drive.” If you do not name one, Metnos applies the configured order for that data family. The language model is not asked to infer a brand from a list.
| Concept | Question it answers | Example |
|---|---|---|
| Skill | Is this capability family enabled, and are its prerequisites present? | mail, photos, google-workspace |
| Execution backend | Where and through which adapter is the operation executed? | local files or Google Drive; local calendar or Google Calendar |
| Operational service | Which Metnos process is installed and running? | HTTP server, Playwright, SearXNG, Photon |
The operational services in the last row are the ones shown in web chat at
Settings > System > Services
(/admin/services). That page controls processes and service units;
it is not the skill registry and does not select a provider for one request.
From Telegram, Tutor can give this path, but the page opens in web chat.
The registry uses three stable categories. A category expresses provenance and trust regime, not how the planner phrases a request.
| Kind | Contents | Availability |
|---|---|---|
core | Capabilities with no mandatory external service: local files and processes, time, scheduled work, signatures, credentials, and list operators. | Core cannot be disabled like an ordinary skill. |
first_party | Skills maintained by Metnos, including mail, photos, web, geocoding, calendars, GitHub, Google Workspace, system administration, and SQL stores. | They ship with the project; they may become dormant when a prerequisite is missing or an administrator disables them. |
imported | Skills acquired from an external source and translated into Metnos executors with recorded provenance. | They pass the signing, adaptation, verification, and isolation rules for imported code. |
Project-maintained skills are classified by
runtime/skills_catalog.py. Bundles also declare language, trust,
and automatic enablement in the front matter of SKILL.md. The
generated executor catalog remains the source for current names and counts.
The central resolver owns the choice for families with multiple backends. It receives the canonical object, request, and argument schema and returns only a value admitted by that executor's contract. The language model does not pick from a list of brands.
| Family | Current backends | Behaviour without an explicit provider |
|---|---|---|
| files and directories | local, Google Workspace | local; Google is selected when the request names Drive, Docs, Sheets, or Google Workspace |
| events | Google Workspace, local calendar | the first available backend in configured order; local remains available for the operations it supports |
| contacts | Google Workspace | used only when the required credentials are available |
Mail applies the same principle through the account resolver: an explicitly named account wins; otherwise the configured default account is used. GitHub keeps provider-qualified executors, and the engine recruits them semantically when the request names GitHub. SQL stores select their backend from the individual store's registry. These are different forms of one rule: configuration and explicit context own the choice, not a free planner guess.
If the requested backend is unavailable or not admitted by that executor's schema, Metnos returns an explicit error. It does not silently replace the requested provider with the default.
A skill can be enabled yet dormant: it remains visible in the inventory while its executors are excluded from planner choices. This can happen when OAuth credentials, a required index, or a registered store is missing.
list_skills reads the registry and loaded catalog; it does not use a model to invent state.set_skills enables or disables a known skill, passes through ordinary authorization policy, and takes effect on the next turn.Enablement is installation configuration, not a preference inferred from one user's prose. Only an authorized identity may change it; language, conversations, and sessions remain isolated per user.
Selecting a backend does not grant permission to use it. Executors that
reach a provider declare the closed provider:access capability,
with a constraint on the final selector value where needed. The runtime first
resolves the effective backend, then evaluates capabilities, credentials,
network, user role, and consent.
An executor name, a word in the request, or a model-proposed argument is not an authority source by itself. The isolation profile derives from the signed manifest and receives only the resources required by effective capabilities. The skill/backend separation therefore lets an adapter change without bypassing policy, signatures, or postconditions.
An external skill is not executed directly. The importer analyses its commands, maps them to the governed vocabulary, generates or reuses executors with a Metnos contract, records provenance, and applies the admission checks. The Skill import page describes the process and its rejection reasons.
MCP addresses discovery and invocation of tools exposed by a server; it does
not replace Metnos's authority contract. There is no generic executor that
freely accepts an MCP server, tool, and arguments. Any
adapter must remain behind a canonical executor with a declared schema,
capabilities, and outcome verification.
| Source | Responsibility |
|---|---|
runtime/skills_catalog.py | classification and prerequisites of project-maintained skills |
runtime/skill_registry.py | installed bundles, language, trust, and persistent enablement state |
runtime/skill_admin.py | skill inventory and changes from the conversation |
runtime/backend_resolver.py | deterministic backend choice for files, directories, events, and contacts |
runtime/mail_account_resolver.py | mail account and backend choice |
| signed manifests | admitted arguments, capabilities, placement, isolation, and executor tests |
For processes installed and controlled through the interface, see the interface guide and open Settings > System > Services in web chat.
The first four sentences act on the catalog or a capability. The last asks Tutor to explain the operational-process page. This distinction prevents the word “service” from being interpreted as a skill, provider, or systemd unit without the necessary context.
Metnos — skills and execution backends