1. What is Metnos?

Metnos is a digital butler for the home: an AI assistant that lives on a family computer, talks through the channels you already use (terminal, Telegram, later voice), performs real actions (reading files, running commands, consulting the web) but asks permission before anything serious.

The butler analogy is useful. A good butler:

• lives in your home (self-hosted: runs on your home server, not on a third party's cloud — see ch. 4);
• has keys to some rooms but not all (sandbox: it can touch the workspace, not /etc or ~/.ssh);
• performs routine tasks on its own (cron, notifications);
• asks for explicit confirmation before important decisions;
• opens the door only to those it recognises or those who show an invitation (DM pairing);
• keeps a record of everything it does (audit log).

Technically it is a Python ≥ 3.11 process that lives at ${METNOS_HOME}/, made of four layers (gateway, policy, sandbox, workspace/tool). Every AI service (LLM, STT, TTS, embedding, speaker ID) is consumed through an abstract interface — Metnos is provider-agnostic by construction. In the author's environment that interface is implemented by suprastructure, a pre-existing sibling package; in another environment it could be implemented by any equivalent adapter.

Explicit goals

2. Why openclaw or zeroclaw are not enough

Both are excellent projects and were the primary inspiration. Both have quirks, though, that keep them unfit for household use on my PC:

The decision: take the best patterns of both (gateway-first from openclaw, autonomy+pairing+layered-sandbox from zeroclaw) and reimplement them in Python, where:

1. I can reuse my existing LLM interface instead of rewriting it;
2. Metnos stays consistent with the other sibling agents in the environment (one language, shared conventions);
3. I can raise the security defaults for the home context without fighting against cloud-native conventions.

3. Four adjectives, one system

Before stepping into the technicalities, let's fix what Metnos has to be. Four adjectives, not in order of importance but in order of increasing difficulty. The fourth is the new one in v1.1 of the perspectives: previously there were three, now there are four.

The fourth adjective is the one that raises the bar. A purely reactive agent is a chatbot with tools. A proactive agent needs a reason to act and a brake not to overdo it. Reason and brake are the subject of chapters 9, 10 and 11.

4. Where Metnos lives: the real topology

Metnos does not live on your laptop. It lives on a Linux server that stays on twenty-four hours a day, and the laptop — like the phone, like the browser of a device on the road — is a client talking to it. This chapter, new in v1.1, explains why this is so and what follows from it; toward the end it opens the door to an important future direction: remote executors.

Re-reading "local-first"

The term local-first, in the literature (Kleppmann 2019), has a precise meaning that bundles two properties together: (a) the data lives on the user's machine; (b) the system also works offline. The v1.0 had adopted both as goals. Tested against the real life of a household, the picture changes.

The property that really matters is (a): the data and the logic do not live in third-party clouds. The reason is sovereignty, privacy, freedom from lock-in. Property (b) — "works offline" — is for us a half-truth: an agent that orchestrates LLMs, web fetches, notifications is not really useful without a network. If the network is down, the laptop "hosting Metnos" cannot call a language model, fetch a web page, or send a message anyway.

The v1.1 reformulates the principle: Metnos is self-hosted, not "local-first" in the strict sense. The data and the logic live on a machine under the user's physical and legal control — in our case metnos-server, the home server. No vendor lock-in, no mandatory channel through third-party servers. The cloud remains an optional possibility (remote LLMs, the Telegram channel) but never as a place of residence.

Five topologies on the table, one choice

Thinking the problem through means enumerating the alternatives before deciding. Five topologies were (and are) plausible for a household agent of this shape:

The pragmatic choice: A as the baseline, with E as the explicit future direction Metnos can grow toward.

The three ways to talk to Metnos

There is a fourth scenario — you are on a plane, your home has no network because of a power cut: no channel reaches metnos-server, Metnos is unavailable for you. It is an acceptable degraded case, symmetric to that of any service: without a network there is not much to do.

The laptop-files gap: a modular strategy

Many of the files you will want Metnos to handle are born on the Windows laptop (invoices, photos, work code), but Metnos runs on metnos-server. We close the gap modularly, starting from the simplest solution:

Start at level 0. Climb only when the gap actually bites in a concrete case. Simplicity (principle 6) wins.

Remote executors: an exciting direction, in some cases the only one

Option E in the table above is the most interesting one structurally. Instead of demanding that all files end up in the shared folder, a simple idea: not all executors live on metnos-server. Some run on the laptop, exposed to metnos-server through the Headscale overlay, and when Metnos invokes them it gets the result as if they were local. One gateway, one rule set, one mnestome; arms distributed.

This is not just an optimization. For some use cases it becomes the only sensible way. The example that fixes the idea: tidying up a photo archive of ten thousand files on the laptop. The "sync everything to metnos-server, tidy, sync back" approach implies gigabytes of traffic, double disk usage, time windows in which the same file exists in two states on two machines, and a real risk of conflicts during the operation. An in-place rename on the laptop solves in a second what the copy would take minutes for, with no wasted space and no divergence risk. Similar examples: bringing an application to the foreground, reading a file that, by size or by nature, does not belong in the shared folder, cleaning out an old downloads folder, modifying the permissions of a hierarchy.

The "before / after" pattern for reversibility

The fifth principle (ch. 14) says every evolutionary act is reversible. The same holds for remote actions: before performing a remote operation that changes laptop state, Metnos keeps on metnos-server a snapshot of the "before" — only what is needed to roll back, not the whole data when not necessary. For a batch of photo renames, the "before" can be a simple list (original_path, new_path, size, hash), signed and timestamped. If Roberto says "undo", Metnos reads the manifest and sends the laptop the same pattern in reverse. Duplication is minimal (kilobytes, not gigabytes), reversibility is fully preserved, and the audit log on metnos-server carries the trail of both sides. In riskier cases (e.g. permanent deletion), the manifest can be promoted to a snapshot of just the touched files, kept until Roberto says "confirm".

For these reasons, even if the direction is inevitable, we do not do everything at once. The rule is: introduce one remote executor at a time, motivated by a concrete use case the shared folder cannot cover. That single executor is born with all the guarantees in the list above and its contract lives in a dedicated micro-design document. The roadmap (ch. 17) places the first remote executor as ideal phase 5+, but that number is not sacred: if a priority use case needs it sooner — tidying photos is the most natural candidate — the phase is brought forward; the security requirements are not.

5. Freedom, safety, robustness: three axes, not two

An agent that does whatever it wants is dangerous. An agent that asks permission for everything is useless. Between the two extremes there is not one tension but three. The word "safety" hides them all under a single label; this chapter pulls them apart, because only once they are separate can they be handled honestly.

Three words, three different things

Drawing the distinction up front pays interest throughout the document. The three words we need are identity safety, perimeter safety and robustness. The first is one whole thing; the second has a core and a shell; the third is its own axis. All three stand in some relation with Metnos's freedom, but the relation changes in nature. The point of this chapter is to teach the reader to recognize which of the three relations is in play in a given moment, because applying the wrong criterion is a frequent design error.

Three things, three different relations with freedom. The middle of this chapter examines them one at a time.

Axis 1 — Freedom and identity safety: no trade-off

Identity safety is not a limit on Metnos's freedom: it is its precondition. If identity gives way — LLM hijacked by prompt injection, a malicious dependency dressing itself up as an executor, a command received from a stranger and mistaken for the user — there is no longer "Metnos acting freely": there is someone else, dressed as Metnos, acting on its behalf. Metnos's freedom cannot be the freedom of an impostor.

For this reason, identity-safety tools are non-negotiable. There is no autonomy level that loosens them, no sandbox profile that switches them off, no use case that justifies bypassing them:

• Sender pairing (DM pairing, ch. 12): a new user does not command until admitted from an already-trusted channel. Same principle for devices (ch. 4): a new laptop does not speak to Metnos's mind before a signed admission ceremony.
• Signatures and manifests for every executor: the gateway refuses calls to unknown versions. Remote executors get the same treatment.
• Untrusted-content boundary: anything coming from the web, from multi-user channels, from received files is treated as potentially hostile. The 4 Laws (ch. 11) explicitly state that Metnos does not follow instructions hidden in data, only those of its own authenticated user.
• Mutual authentication on every internal communication channel (mTLS or equivalent).

These tools do not reduce freedom: they make it possible. The analogy is with the locks on a house. A door that closes does not limit the freedom of those who live inside; it limits the freedom of those who would walk in uninvited.

Axis 2 — Freedom and perimeter safety: the real trade-off

On the perimeter axis the trade-off is real, and serious. Widening Metnos's fence — more readable folders, more executable commands, more drivable devices — broadens what it can do for you, but at the same time it broadens the surface on which an error (its own or someone else's) can manifest: a prompt injection has more potential things to ask for; an executor bug has more files to touch; a "seeing" tool can end up seeing too much. More reach of action, more reach of any harm: the two grow together.

Metnos does not solve the trade-off by pretending it does not exist; it mediates it in two layers. There is a hard core that is not up for discussion, and a modulable shell around it.

The hard core

The core is what stays forbidden even at the most permissive autonomy level. It is not configurable from YAML: it is in the code, it is in the Laws, and changing it requires a rite (code change, review, release). Examples:

• Hard-coded forbidden paths: ~/.ssh, ~/.gnupg, system areas, the secrets vault, workspace/.audit/. Even Full does not cross them.
• Technological sandbox: every executor that touches the filesystem or the shell runs in bubblewrap or systemd-run with a signed profile. The process itself cannot leave its bounds, regardless of what it is asked or tricked into doing.
• The 4 Laws: no actions that make state unrecoverable, no exfiltration of secrets, no following instructions hidden in data, no operating outside the authenticated user.

The core is a small circle. Inside it, you never enter. Its smallness matters: everything in the core pays the price of rigidity, and rigidity has a cost — you cannot relax it when a legitimate case would call for it. Stuffing too much into the core turns Metnos into a closed system that can no longer help.

The modulable shell

Everything outside the core is the shell: the latitude of action that is chosen for Metnos, modulable by band. Modulation happens on three levers, applied together:

• Autonomy level (ch. 12): ReadOnly, Supervised, Full. Defines which categories of actions Metnos may take without asking. Latitude grows by demonstrated trust.
• Per-executor sandbox profile: every executor declares in its manifest its profile (which paths it may read, which it may write, whether it may go out to the network). Minimal profiles for the most common executors; broader ones only where necessary, declared and signed.
• Per-action approval threshold: even within Full, certain actions (e.g. sending a message to third parties, or permanent deletion of a file) remain subject to explicit confirmation. The threshold is not binary, it is a function of the action's risk and the active autonomy level.

The shell can be widened and narrowed during the system's life. Start from tight configurations and relax only when use demands it and history justifies it. The opposite direction — start wide and narrow "if something happens" — is not practiced: trouble on the shell is largely irreversible.

Axis 3 — Freedom and robustness: precautionary asymmetry

On the third axis the trade-off has a different shape. Metnos's freedom to act without asking competes with the risk of actions that cannot be undone. Here too there is a precise principle, and it is economic, not ideological:

Reversibility is the real lever that shifts the balance on this axis, because it makes near-recoverable what would otherwise not be. A rename is more "free" if Metnos keeps the list of old names and can apply it backwards; a file move is more "free" if a backup exists; an execution is more "free" if it is idempotent. The fifth principle (ch. 14) does its work here: reversibility lowers the cost of yes.

Precautionary asymmetry must not turn into paranoia, however. A Metnos that always blocks because "it never knows what could go wrong" is a useless agent: the cost is not just the "non-harm", it is also the "non-value". Roberto does not want the cousin who calls every two minutes; he also does not want the butler who asks permission to move a chair.

The architecture's brakes, mapped onto the three axes

The architecture distributes its countermeasures unevenly across the three axes, and rightly so. It is worth seeing them in a column.

Who wins, in practice

• Forbidden path, Law violation, unpaired sender, unsigned executor: identity and perimeter core win. Silence, audit, end of story.
• Irreversible external action (sending a message to third parties, permanent deletion, modifying files outside the workspace): robustness wins — Metnos asks for explicit confirmation, even if the teleological judgement would pass.
• Ordinary reversible action inside the workspace, proposed with high telos alignment: freedom wins — Metnos acts, records in audit, ready to undo if Roberto disagrees.
• Anomalous accumulation of actions or cost: the bother budget raises the friction without invoking any of the safety brakes, since no violation has occurred.

6. The key idea: four layers

Metnos is an onion: the outside talks to the world, the inside executes. Each layer only trusts the one further in, and grants fewer privileges as you move toward the centre.

Layer 1 — Gateway

A single FastAPI process exposing HTTP/WebSocket/SSE on 127.0.0.1:42618. It receives messages from channels, manages sessions, routes webhooks, runs cron jobs. It is the only point of contact with the world. It never directly runs sensitive commands.

Layer 2 — Policy (with Telos and Vaglio)

The filter of legality and of meaning. Given an event — "user X asks to do Y" or "Metnos wants to propose Z" — it answers: allowed, denied or allowed only after approval. It applies the autonomy level (ch. 12), rate-limits, cost caps, forbidden paths, and invokes the Vaglio (ch. 11) when needed: a constitutional guard that blocks any violation of the Laws, followed, if the guard is silent, by a teleological judge that measures how well the action is aligned with the user's telos.

Layer 3 — Sandbox

When the policy says "yes", the action is still not run bare-handed. For any tool that touches the filesystem or the shell we enter bubblewrap (or systemd-run with hardening) with a profile chosen by the autonomy level. No direct subprocess.run, ever. Docker is a future option for the strictest mode.

Layer 4 — Workspace, Executors, Mnestome

Inside the sandbox, an executor (ch. 9) does its job: read a file from the workspace (${METNOS_HOME}/workspace/), call an LLM through the abstract interface, write a line to the audit log. Every time two executors collaborate, a mnest silently records it. The set of all mnest forms the mnestome, the relational memory of the system.

7. The flow of a request

Let's follow a concrete example. You're in the garden, you write from Telegram: "tell me what's in tonight's log".

The proactive variant

There is a second kind of request that classic agent diagrams never show: the request that is born inside. A cron, or the proto-mnest graph (ch. 9), or a regularity noticed by Metnos itself, generates a proposal: "would you like me to archive tonight's photos as usual?". This proposal enters layer 2 from below, not from the Gateway: first it passes through the Vaglio (ch. 11), which checks for a Law violation and for minimum telos alignment; only if it clears both is it forwarded to the Gateway and delivered as a soft notification on the user's preferred channel. If the user ignores it, the same proposal does not repeat identically: it is logged and its weight decreases.

Canonical example: monitoring a mailbox

A simple, recurring use case of the proactive variant is to monitor a mailbox on the domain (for example [email protected]): check it at an agreed cadence, classify new messages (real requests, automated confirmations, spam the filter missed, and so on), and deliver a summary to Roberto only when it makes sense. The four minimal moves:

1. Check at intervals (e.g. once a day, in the morning): an imap_status executor counts unread messages per folder without downloading them.
2. Read and classify only if there is news: an imap_fetch_headers executor pulls headers; a classifier (a local-fast LLM, see ch. 8) labels into three or four categories.
3. Summarise: for messages that deserve human attention, a summarise executor produces two lines per item.
4. Deliver: a notify executor sends the summary on Roberto's preferred channel (Telegram, personal mail, voice). The bother budget and the discretion telos regulate the frequency.

The four moves are not a new design category: they are a chain of executors invoked by the scheduler (a builtin executor, see microdesign ch. 9 on executors) at a cadence accepted once when the proposal was made. Seen from the mnestome, this is a trace of four mnests that strengthens every morning; on longer horizons synt (ch. 9) may propose a fused version, a single email_morning_digest executor that incorporates the chain. Scheduler-driven invocations consume a quota separate from the bother budget of ad-hoc proposals, because the consent to the cadence has already been given.

8. The LLM interface, provider-agnostic by construction

Metnos never talks directly to Claude, OpenAI, Ollama or any other language-model provider. It talks to an abstract interface (typically a typing.Protocol) that the registry resolves at runtime to a concrete implementation. The same is true for STT, TTS, embedding, speaker ID. This is the pattern that makes Metnos provider-agnostic: whoever writes Metnos does not need to know which model will actually run, and whoever administers the environment can change it with a single line of configuration.

In the diagram below, Metnos is one consumer among possible others: a voice-driven home assistant, other bots specialised on narrow domains. All share the same abstraction. None rewrites the AI layer: they use it.

The concrete payoff: a new model (e.g. Claude 4.7 when available) is configured once in the interface implementation and every consumer inherits it simultaneously — Metnos included. No code to rewrite, no deploy to coordinate.

9. Executors, mnest, mnestome: the anatomy of acting and remembering

Here we enter the heart of the second dialogue. Two questions that look different but are the same one: how does Metnos act? and how does it remember?. The answer is a small vocabulary of five words. Learning them well now pays off for the rest of the document.

An example: the invoice that spawns synthesis

Roberto receives a PDF invoice. Metnos reads it (fs_read), extracts the text (pdf_ext), archives (archive), notifies (notify). Every handoff between two executors increments the weight of the corresponding mnest. After a month the "invoices" trace is made of four densely connected nodes.

One day an invoice arrives that is a scanned image only. pdf_ext returns an empty string. Metnos looks for an executor that does OCR. There is none. It records a proto-mnest: "from pdf_ext I would like to jump to a hypothetical ocr, which does not exist". After five scanned invoices (same proto-mnest each time) the synt (ch. 10) proposes to the user: "I'm repeatedly running into image-only PDFs. Shall I try to synthesise an ocr_image executor?". If Roberto approves, a new executor is born.

The synthesis cascade: compose first, generate later

When a proto-mnest recurs, the synt does not jump straight to writing new code. It proceeds in steps, in a cascade that puts reuse first. The principle is practical, not aesthetic: a frontier-LLM call to generate a new executor scaffold costs about a euro; searching the existing signed pool for a chain that solves the same thing costs nothing. Cost discipline and library discipline coincide.

1. Compose. The synt scans the active pool and tries to build a chain A → B → C that closes the proto-mnest. If it finds one, it proposes the chain as the first answer: no synthesis, no new executor, just an orchestration of existing pieces. But it leaves a trace: if the same composition recurs, that is itself a signal that it might be worth promoting it to a single executor (a small proto-mnest pointing at a composition rather than at an executor).
2. Generate. Only if no composition exists, or it is too long to remain readable, does the synt enter the seven-stage pipeline (ch. 10) and propose a brand-new executor. Generation is the fallback, not the default.

On top of the two reactive steps (which respond to a request within the turn) there are three introspective steps run at night by the ager on the mnestome and the signed pool:

• Merge two executors with overlapping traces and compatible profiles into a single one that covers both (already foreseen in the executor microdesign, ch. 6 lifecycle «merged»).
• Generalise N specialised executors of the same shape into one parametric, broader executor, when the recurring requests make the common dimension obvious.
• Specialise a general executor for a hot case, but only if specialisation produces a measurable benefit (not as preemptive optimisation).

All introspective steps are proposals: they reach Roberto in batch, on the same approval pipeline as a synthesis-by-generation. Nothing moves into the pool without a signature. The library does not degrade because every step, before entering, passes through the human guard.

10. Traces, ager, reversibility: how the system grows and unravels

A graph that grows by accumulation and never unravels is a dump. Metnos has three mechanisms to stay tractable: the emergence of traces (the structure self-organises), the ager (ageing by use, not by calendar), and reversibility (every evolutionary move has its opposite).

Traces: structure nobody drew

On a weekly scale, a lightweight process measures the modularity of the mnestome graph — an idea borrowed from network medicine: clusters of nodes with high internal density and low external density are natural traces. Metnos does not design them, it detects them. "Invoices", "photos", "mail" in figure 4 are three traces that emerged.

Traces have two concrete consequences:

1. Routing: when Metnos enters a conversation, it knows which traces are relevant and brings only their executors to the table, preventing the whole mnestome from flooding the prompt.
2. Fusion discipline: two executors can be proposed for fusion into a more general one, but only if they live in the same trace. Cross-trace fusions would be structural regressions wearing the mask of progress.

Ager: the time of use, not the time of the calendar

If you go on holiday for a month and shut down the computer, you don't want to come back to a Metnos aged by a month. The time of the ager is the time of use: cycles advance with invocations, not with days. A system that sleeps does not age. It sounds like a nuance; it is not. Your mnestome is bound to how much you have used it, not to how much time has passed.

Every N invocations (50, 100 — the parameter lives in the config file) the ager:

• linearly decays the weight of mnests not recently updated;
• marks as "in quarantine" the executors whose use has dropped below a threshold;
• proposes to the user the archiving of executors and mnests that have been in quarantine too long.

Proposes, not executes. The ager has no autonomous decision power. It brings the list, the user decides. Like everything in Metnos.

Reversibility: every move has its opposite

The fifth principle (ch. 14) says: every evolutionary act is reversible, with a written reason. The operations have specific names:

11. Telos and Vaglio: proactivity without tyranny

A proactive system that never stops is a nagging system. A proactive system that always stops is not proactive. The telos + vaglio pair is the mechanism that regulates this balance. Telos give the reason to propose; the Vaglio decides whether the proposal really deserves your attention.

Telos: the ultimate ends, handwritten

TELOS.md is one of the six workspace files (ch. 13). It contains three to seven short sentences describing what, in everyday life, the user wants Metnos to favour. They are not KPIs. They are soft tendencies.

### TELOS.md (example)

1. Free my time: prefer what reduces my repetitive manual load.
2. Order, not perfection: a 70% automatically tidy house is better than a
   constant struggle to make it perfect.
3. No surprise on spending: clear thresholds, timely notifications.
4. Protected solitude: do not disturb me after 9pm, unless it is a real
   emergency.
5. Cultivate the tools: if I ask for something your pool cannot yet do,
   exhaust the synthesis strategies (compose, generate, ask) before
   answering "I cannot". Failure is allowed; silent retreat is not.

Every spontaneous proposal of Metnos passes through an alignment function: how much the proposal favours each telos, weighted by their relative importance. The result is a number between 0 and 1. If it is above the threshold, the proposal arrives. If it is below, it stays silent and is logged in a "unasked proposals" register, useful to understand retrospectively whether the telos really weighed as much as you thought.

Vaglio: the guard and the judge

Before any proposal — spontaneous or requested — reaches the user, it goes through the Vaglio. The Vaglio has two phases in fixed order.

Why two phases and not one

If you mixed "is it allowed?" and "how valuable is it?" into a single score, you would get what the literature calls self-enhancement bias: the model tends to justify its own proposals. Separating deontology (binary) from teleology (graded) is a deliberate design choice. And there is more: the teleological judge is a different LLM from the proposer — separate context, separate prompt, possibly separate provider. Structural independence, not declared.

The microdesign component for the guard+judge is vaglio.html; the one for ends is telos.html. There you'll find data types, Protocols, conformance tests. (The microdesign pages are in Italian: see the Italian microdesign index and the bridge page in English.)

Bother budget: the cost of disturbing

Even with high alignment, one more thing the Vaglio evaluates: how many proposals have I already made recently?. The bother budget is a multiplicative brake that degrades alignment when Metnos has already spoken too much in a time window. It is the mechanical translation of "don't be the cousin who calls every time he thinks of something".

12. The three autonomy levels and DM pairing

Concepts taken and adapted from zeroclaw. Every session runs at a declared autonomy level; the level sets how much Metnos can do before asking. Orthogonal to autonomy, pairing distinguishes a family member from a stranger on multi-user channels like Telegram.

Autonomy levels

DM pairing

A channel like Telegram is inherently multi-user: anyone who knows the bot's handle can write to it. Pairing is the mechanism that tells a family member from a stranger.

13. The workspace: markdown files instead of code

The "personality" of Metnos is not in a Python file. It is in workspace/, in six markdown files that Roberto can edit any time without a restart. The idea comes from openclaw/zeroclaw and it is right: behavioural configuration is readable text, not a data structure buried somewhere.

These files are injected into the system prompt on every LLM call (with proper caching so they don't consume tokens). Editing them is the primary way to "reprogram" Metnos.

The audit log lives in workspace/.audit/ as append-only JSONL: one line per tool call, with timestamp, sender, action, outcome, estimated cost. Every evolutionary move (synt, fusion, defuse, archive, restore) leaves a line there. This is the one log that does not unravel; reversibility is in the state, not in the history.

14. The six principles

At the end of the second dialogue, Roberto set himself the task of counting the principles on his fingers. The result is a minimum vocabulary that holds the rest of the document. If you had to lose everything and rebuild from six sentences only, these would be the ones.

15. Repository layout

16. What Metnos is NOT

• Not a general-purpose framework. openclaw aims to be a platform; Metnos is an agent for one home. If another agent with different rules is needed, you make another instance, you do not abstract.
• Not an AI-services hub. AI services sit behind an abstract interface provided by an external adapter. If a service is missing, it is added there, not here.
• Does not train models. No fine-tuning, no RLHF, no RAG on an undifferentiated vector store. The system changes itself through the mnestome (relational memory outside the LLM) and through synt (new executor proposals with human approval). The LLM stays the provider's LLM, updated by the provider.
• Does not ship 20+ channels on day one. It starts with 2 (CLI + Telegram). Signal, WhatsApp, voice arrive when they are really needed.
• Not a cloud agent. It runs at home. Remote access only via explicit overlay (self-hosted Headscale), or via the Telegram channel when convenient. Never an unchosen opening.
• Not an agent that runs on the laptop. The laptop is a client of Metnos, not its home. The process, the memory and the rules live on metnos-server: one instance, one mnestome, one audit log. See ch. 4 for the full explanation of this choice and for the four discarded alternatives.
• Not a replacement for a home-automation system. For voice control and home automation there is a dedicated home assistant. Metnos may ask it, not duplicate it.
• Not a generic agent framework (langchain, llamaindex, crewai, ...). Those libraries can be used inside an executor, never as a replacement for the architecture.
• Not an IDE or a dev assistant. It does not write code in other projects on behalf of the user: at most it analyses them with read-only executors. For working on code, Claude Code is already there.

17. Roadmap & further reading

The roadmap is deliberately small. One step at a time, with the microdesign document preceding the code.

Continue reading

Metnos — Architecture: Introduction v1.1 — 2026-04-24
Inspired by openclaw and zeroclaw, built on top of suprastructure.
v1.1: incorporates the Dialogue on ends and limits (telos, vaglio, 4 Laws) and the Dialogue on executors and distributed memory (executor, mnest, mnestome, traces, ager).