Architecture map

Metnos is an agent governor that you can install on a local computer. It receives a request, decides which capabilities may satisfy it, controls their use, and records what happens. Metnos does not come with inherent access to email, browsers, or filesystems: the executors admitted by an installation define what it can actually do.

The reference installation can work as a personal or household assistant. That use case does not define Metnos itself. Give the same governed core a different admitted executor catalog and it can support software maintenance, research, or another clearly bounded operational domain.

The central idea

The core plans, judges, remembers, and records. Executors act. This separation stops a language model from automatically inheriting the privileges of the computer that hosts it. A model may propose “read these files, compare them, and create a report”; only declared and admitted executors can perform those steps.

The path of a request

Consider this request: “Find the PDF reports received this week, summarise them, and save the summary in the Projects folder.”

1. Metnos establishes the context. The channel identifies the user, conversation, language, and any device named in the request.
2. It identifies the intended result. It separates the needed operations: find messages, read attachments, summarise them, and create a file.
3. It considers only available capabilities. The active catalog narrows the choice to executors that are installed, signed, compatible, and admitted for that user.
4. It prepares an inspectable plan. Every step has a name, an argument schema, explicit dependencies, and an expected result.
5. It applies the controls. Schema, policy, Vaglio, placement, credentials, and consent are checked before the action they govern.
6. It executes and verifies. Executors return structured results and receipts. A later step receives the preceding step's data, not a model's plausible reconstruction of it.
7. It reports honestly. Metnos states what succeeded, what failed, and whether the result is partial. It then records the trace needed for audit and, where the contract supports it, undo.

A question is not necessarily an action

When someone asks how Metnos works, Tutor searches admitted public sources and may retrieve a small set of current, read-only observations. It does not start an operational executor. If the same sentence also contains a separable action, Tutor explains the informational part and asks before handing the operational part to the ordinary engine.

How a plan is made

Metnos does not ask a model to start from scratch every time. It tries the simplest previously verified path first:

1. a deterministic rule for a closed, well-defined case;
2. a previously successful plan for the same request, called the fast path;
3. a confirmed, generalised plan for a family of requests, called an autopath;
4. a new proposal from the planner when none of the earlier paths is enough.

A reused plan is not a permanent shortcut. Before execution, Metnos checks the catalog, schemas, and operating context again. If an executor has changed, a relevant alternative has appeared, or a dependency is no longer available, the saved plan is rejected and rebuilt.

Data moves between steps through structured references. Large collections may stay in the turn's scratchpad, so the planner sees what it needs without being given entire mailboxes or file collections. Credentials and other sensitive values are resolved by the runtime only when execution needs them; they are not entrusted to the model.

Who may do what

An action is admitted only when every applicable boundary agrees. There is no single “safe/unsafe” switch.

• Identity: who made the request, and which user owns the resources, channels, and devices?
• Executor contract: which effects, resources, networks, platforms, and arguments does the signed manifest declare?
• Policy: does the user's autonomy level allow that capability for that target?
• Vaglio: does the operation present a risk that makes it forbidden or requires an explicit decision?
• Sandbox: does the execution environment actually restrict processes, files, and the network according to the contract?
• Confirmation: where required, can the user recognise the action, destination, and relevant consequences before accepting?

Confirmation does not create a new power on its own: it authorises a proposal that is already compatible with identity, policy, and contract. Likewise, an executor's presence in the catalog does not mean that every user may run it against every target.

Undo does not always mean the same thing

The contract distinguishes three cases. An action can be undoable when it produces a receipt that can restore the previous state; not undoable when it changes data without a reliable inverse; or not applicable when a read or pure computation leaves nothing to restore. The executor catalog shows the classification derived from the manifests.

Where an action runs

Executors normally run on the computer that hosts the Metnos server. A user may also pair another computer, such as a Windows laptop. The runtime chooses that device only when the plan requires it, the executor is compatible, and the user has the necessary authority.

The device client does not decide what to do. It receives an authorised invocation, applies the contract and sandbox available on that operating system, records the outcome, and returns a receipt to the server. If the device is unreachable, Metnos does not pretend that the action ran: it stops or, for work that supports it, offers to defer the action.

Transport does not change an executor's meaning. The same capability must keep the same arguments, results, and authority whether it runs locally or on a remote device.

Memory, records, and long-running work

Metnos keeps several kinds of state, each for a specific purpose:

None of these memories grants capabilities. Remembering that two executors worked well together does not authorise the second to read data that the first could not lawfully pass to it.

How to add a capability

A new capability enters the system as an executor, not as a free-form prompt instruction. It needs a name from the admitted vocabulary, a schema, declared effects and resources, tests, a signature, and placement rules. Only after admission does it appear in the catalog available to the planner.

Synt can compose existing capabilities or prepare a new executor when one is genuinely needed. Imported skills cross the same boundary: their content is translated into Metnos capabilities, checked, and admitted. Third-party code does not automatically inherit the instance's privileges.

A shared vocabulary

Executor names combine one action and one object from a closed vocabulary. It currently contains 28 actions and 27 objects. This lets “read files” and “read messages” share a verb without turning them into the same capability.

Actions: read,write,move,delete,create,find,list,filter,sort,group,classify,get,set,send,describe,render,extract,compress,compute,compare,change,order,share,open,login,act,install,run.

Objects: files,dirs,packages,messages,events,contacts,places,processes,urls,numbers,images,signatures,texts,proposals,persons,tasks,inputs,approval,credentials,issues,pulls,calendars,entries,lists,skills,sites,preferences.

When a plan needs to work on a collection it has already obtained, it uses shared operators instead of creating a domain-specific variant. The structural operators are filter_entries,filter_lists,sort_entries,group_entries,compute_entries; the semantic operators are classify_entries,compare_entries,extract_entries,describe_entries.

Deliberate limits

• The language model has no direct access to files, email, browsers, credentials, or devices.
• A plausible result is not a substitute for a verified receipt.
• A missing capability is not simulated with a generic command.
• A partial failure is not presented as complete success.
• A paired device does not automatically become available to every user.
• A confirmation does not become permanent authority unless the user explicitly chooses a persistent grant supported by policy.
• Metnos does not depend on a particular model or provider: functional tiers are configurable, and external services remain optional.

Where to go next

This guide describes implemented behaviour. For inventories that change over time, such as the list of executors, it links to pages generated from current contracts instead of copying counts that would soon become stale.