Quick tour & Survival kit — the home assistant, from outside and inside
A digital butler that lives in your house, answers on your phone and your terminal, and asks permission before doing anything important. Here: what it is, how you talk to it, how it grows, how to get started.
Metnos is an assistant that lives on a mini-computer at home,
speaks through Telegram and from the terminal,
and can do things on your behalf asking permission when it matters.
Think of a butler in the kitchen, 24 hours a day. He doesn't leave the
house without asking, doesn't spend money without warning you, doesn't delete
anything he hasn't shown you first. But if you say "download yesterday's
attachment and put it in Documents", he does it, and says "done".
It is not a chatbot. A chatbot answers questions. Metnos
acts: downloads files, reads mail, writes notes, checks the calendar,
summarises conversations. It answers questions too, of course, but its reason
for being is to do small things on your behalf.
2. Seven scenes from real life
The fastest way to grasp what it does is to watch a few examples. The
first three are reactive (you ask, it answers); the middle three show the
more interesting things — when it acts on its own at scheduled times,
when it delegates to another household agent, when it builds itself a new
tool. The seventh is the longest: it shows how the system, over time,
notices what it is missing and proposes to grow in that direction.
Scene 1
"Summarise today's mail"
Roberto opens Telegram from the train. He writes to his Metnos bot:
“Hi, give me the summary of today's important mail”
Metnos reads the inbox, drops the spam, groups the mail by sender and
priority, and replies in 4-5 lines: "3 mails today: (1) lawyer asks you
for the document by Friday, (2) bank confirms the transfer, (3) your sister
about Sunday lunch. Would you like me to reply to any of these?"
No approval required: reading mail is considered safe
(Metnos modifies nothing, sends nothing).
Scene 2
"Reply to the lawyer yourself"
Roberto, still on the train:
“OK, reply to the lawyer, tell him I will send the document by Thursday”
Metnos drafts the message, then before sending asks for confirmation,
showing the exact text:
✋ May I send? To:[email protected] Text: Dear counsel, I confirm I will send the document by
Thursday 24 April. Best regards, Roberto.
[ Yes, send ] [ Wait, let's edit ] [ No, drop it ]
Roberto taps "Yes, send", the mail goes. Two seconds later: "Done.
Delivered at 11:34."
Scene 3
"Remember that tomorrow is mum's birthday"
Roberto, in the kitchen, says to the terminal:
“Tomorrow is mum's birthday. Write it wherever it belongs.”
Metnos updates the calendar (with approval), adds a note to MEMORY
("mum's birthday is 23 April"), and the next morning sends a Telegram
message: "Today is mum's birthday. Would you like me to remind you to
call her in the afternoon?"
Long-term memory: next year, same day, it will already know.
Scene 4
"Every Sunday at 9, summarise the week"
Roberto, on a Saturday evening, writes just once to Metnos:
“From now on, every Sunday morning at 9, send me a Telegram summary of the week: important unreplied mail, deadlines within 7 days, significant expenses, things I promised to do.”
Metnos confirms: "OK, I have set a recurring reminder. The first run
is Sunday 26 April. Want me to do it now as a test?".
The following Sunday, at 9:02, a spontaneous message arrives:
☕ Good morning. Week 20–26 April summary
• Unreplied mail: Mr. Rossi (document Monday), cousin Luca (christening)
• Upcoming deadlines: electricity bill 29/4, medical visit 2/5
• Notable expenses: €312 home hardware (Wed 23)
• Open promises: book hotel in Rome, call mum
Shall I draft replies for the two mails?
Proactive action: Metnos woke up on its own, worked in
the background, and reached you. This is possible because at the time of
the initial request you gave the green light for this specific recurring
activity. Nothing arrives spontaneously without you having said yes at
least once.
Scene 5
"Ask the house whether the washing machine is done"
Saturday afternoon, Roberto from the armchair:
“Ask the house to check whether the washing machine downstairs has finished its cycle, and if so, notify me when I'm back in the kitchen.”
Something interesting happens here: Metnos does not check the
washing machine itself. Home automation (sensors, switches,
appliances) is the job of another agent — the home-automation
assistant — that lives on the same mini-computer and talks to
the home network. Metnos delegates:
Metnos → house: "status washing_machine_bathroom" house → Metnos: "cycle finished at 14:07, consumption 0.42 kWh" Metnos → house: "notify presence_kitchen(roberto)" Metnos → Roberto: "The washing machine finished at 14:07.
I'll let you know when you're back in the kitchen."
General principle: Metnos does not rewrite half the
digital house. It works with the other specialised agents that are already
there. The home-automation assistant for voice and sensors, Metnos for
mail, files, appointments. They talk through a shared protocol, like two
colleagues in a company.
Scene 6
"Write me a script that orders the photos by date"
Roberto has 2,400 photos downloaded from the phone in
~/Pictures/raw/, names like IMG_4812.JPG, dates
only in EXIF metadata. He asks:
“In Pictures/raw I have 2,400 photos. Put them in subfolders 2025-03, 2025-04, ... by date taken. Don't touch the originals: copy them.”
Metnos understands that a script is needed, writes one (Python +
exifread), and before running it shows you:
✋ May I run? Script:~/Pictures/.metnos/sort_by_date.py (42 lines) Source folder:~/Pictures/raw/ (read-only) Destination folder:~/Pictures/sorted/ (new, to be created) Operation: copy, not move or delete Sandbox:supervised (no network, no other paths)
[ Yes, run ] [ Show me the script ] [ Cancel ]
Roberto clicks "Yes", the script runs inside a sandbox (it cannot touch
anything other than those two folders, it cannot go online), and 90 seconds
later: "Done. 2,403 photos copied into 18 subfolders from 2023-01 to
2026-04. Originals intact.".
What matters here: Metnos does not have "a command to
order photos". It wrote one on the fly, under sandbox supervision,
for that single request. If tomorrow you ask the same on a different folder
it can reuse the script; if the photos were in a different format, it will
write another one.
Scene 7
"These photos… I've seen them before"
Weeks after scene 6, Roberto begins to ask questions about the sorted
photos. No longer "put them in folders", but things like:
“Give me the photos from the Corfu holidays” “Find the photos with mum” “Which ones are from Luca's wedding?”
Metnos does what it can: searches EXIF metadata (geotags, dates), writes
little scripts on the fly, sometimes it arrives, sometimes it doesn't
— requests about visual content (who is in the photo, where it was
taken without a geotag, what kind of event) escape it. It has no tool for
looking at photos, only for reading their metadata. It does not
fail loudly: it admits the limit, tries an alternative route, and often
answers "I don't know".
Five weeks go by. One Saturday evening, spontaneously, Roberto receives
a message:
📷 A proposal, if you like.
In the last five weeks you have asked me 12 times about things in photos
that I cannot resolve from metadata: recognising a place from visual cues,
people present, type of event. Each time I did what I could, but I also
recorded the gap.
The pattern is now clear enough. May I propose two new tools?
• one to recognise recurring faces (after you tell me, just
once, who is who in the first 30 photos);
• one to classify the place from visual cues (sea, mountain,
indoor, street).
I'll send you the drafts on Thursday, then you decide. If you don't like
them, I drop them.
What happened here: every time Metnos met a request it
couldn't resolve with its available tools, it recorded the void as a
half-finished attempt. Twelve attempts of the same type in
coherent contexts were enough to decide the gap was worth closing. The
proposal does not come from above — it comes from your own requests.
The system grows in the direction you, week after week, have pulled it.
But it does not grow by itself: the drafts come to your judgement before
becoming actual tools. Chapter 6 explains how this growth works in
detail.
3. Where it lives and how you talk to it
Metnos runs on a mini-computer with Ubuntu that sits in your house
(in the living room, in the basement, under the TV — it's not big).
Internet is not needed to talk to it when you are at home; it is needed for
things that require external services (Drive, mail).
It has two faces. One brain, two surfaces.
The phone face: Telegram
Figure 1 — What you see on Telegram. The style is a normal chat app: text, quoted replies, buttons below confirmation requests. No commands to learn.
The home face: terminal
Whoever loves the computer can speak to it through a terminal window,
and see what it is doing in real time. For those who prefer Telegram, this
is never necessary.
Figure 2 — The same brain, seen from a terminal. The italic grey lines show what Metnos is doing "behind the scenes": useful if you want to understand, ignorable if you don't.
A sample dialogue from the terminal
Scenario: you are at the supermarket, you want to know whether a model
download you started yesterday evening has finished.
Roberto
is the model download finished?
Metnos
Checking ~/downloads/ and the wget log. Give me a second.
(internal)
Policy: "file read + local log" → supervised OK, no approval
needed. Sandbox started, read-only profile.
Metnos
Yes. Downloaded 8.2 GB of 8.2 GB, checksum verified. The file is
claude-opus-4-7.gguf, finished at 03:14 last night.
Should I move it to /opt/models/?
Roberto
yes
(internal)
Policy: move outside the workspace → approval required. The
"yes" just received counts as explicit approval.
Note how Metnos explains what it is about to do before doing it;
doesn't ask confirmation for read-only operations; asks confirmation for a
move outside its working space; records an audit log number, so it is always
possible to trace back what happened.
4. What happens when it says "may I?"
The single most important piece of design, for a user. Every time Metnos
is about to do something that changes the state of the world (send
a mail, write a file, spend money), it first stops and asks.
This is not a bug: it is its number-one safety mechanism.
1
Understands the intent. Reads your message and decides what needs doing (e.g. "send mail to Rossi").
2
Prepares the action. Writes the mail in its internal memory, but does not send it. If it is downloading a file, it computes it but doesn't write it yet.
3
Asks for confirmation. Shows you what it will do, where, with "Yes / No / Let's edit" buttons.
4
Executes only after "Yes". If you don't answer within the allotted time (2 minutes on Telegram, 30 seconds in the terminal), the action expires: it is not performed. Nothing acts behind your back.
5
Confirms the outcome. Says "done" or "failed, reason: X". Everything ends up in a write-only log: you can always re-read yesterday, last week, six months ago.
Too many "may I?" bothering you? Normal. For things you do
often, Metnos learns: the first time it asks, the second time it asks with
"ok for similar cases in the next 30 minutes?" and if you say yes, it stops
asking for half an hour. If you switch channel (you're at the computer
rather than on the phone), it starts from scratch: different contexts =
different discretion.
5. Its memory: what it remembers and what it doesn't
Metnos has a three-layer memory for conversations and
facts. It's not magic, it's three files/tables with different roles.
Figure 3 — Memory of facts and conversations. On the left, the warm and volatile; on the right, the cold and permanent.
The detail that matters: Metnos never promotes a fact
to "long memory" on its own. Once a day (in the evening) it proposes:
"I noticed that today you kept talking about Mr. Rossi: shall I save
him as a regular contact?". You say yes or no. Long memory is built
this way, not surreptitiously.
And there is a fourth, less visible memory. Beyond facts
about the world, Metnos keeps track of how it works: which tools
it has used together and with what outcome, and — more interestingly
— which attempts stayed half-finished because it lacked the
right tool. This second memory is not about remembering you: it tells the
system where to grow. Chapter 6 uses it; the
Dialogue on executors and
distributed memory tells the full story.
6. How it grows: new tools when needed
Metnos is not born "omniscient". It is born with a limited toolbox, and
learns to expand it — always under your control, never in secret.
Tools in the toolbox have a proper name: they are called
executors. An executor is a simple script that does one
thing (archive an invoice, extract text from a PDF, rename a file based on
its metadata). When called, it acts; when not called, it sits still. It
doesn't learn, it doesn't change inside — intelligence does not live
there.
The growth intelligence lives elsewhere in the system: a specialised
part that knows how to write new executors when the system
realises one is missing. I call it the Synthesizer, or
synt for short. The synt does not work in the void: it works on
evidence it has gathered. The cycle goes like this:
1
It tries with the tools it has. If a task fails or
takes too many manual steps, it notices.
2
It keeps track of half-finished attempts. Every time
there was a result it would have liked to hand off to something, but
no executor was suitable, the system records the absence. It does not
act, yet: it logs.
3
It proposes a new executor when the evidence consolidates.
After the same absence recurs enough times in coherent contexts (think
of scene 7: twelve similar photo requests), the synt drafts a proposal
and brings it to you.
4
You decide. Yes, no, edit. If yes, the executor is
born, tested in the sandbox, and from the next moment is in the
toolbox. If no, the synt forgets it. The initiative is its; the
control is yours.
5
The ones that aren't used any more age out. Executors
that no one has called in months get proposed for archiving, with a
short explanation ("worked 3 times, last in January, now seems
superseded by X"). They don't vanish abruptly — they are retired
with a note, and you can recall them if they become useful again.
Why it's interesting. Metnos's growth is not driven by
the designer (me), and it isn't driven by the user (you) explicitly
asking for new tools. It is driven by the actual use the system
has had so far: by the gaps that have accumulated because you, day after
day, asked it things. The system grows in the direction it has been
pulled, never in a direction that has not already been solicited. Two
Metnos installations, in two different homes, after six months do not
have the same toolbox.
For the full technical mechanism — how gaps are measured, how the
synt picks what to propose, how the archiving decision is made — see
the Dialogue on executors and
distributed memory.
7. What it can do, what it will never do
✓ What it can do (or will soon)
Text chat from terminal and Telegram
Read and summarise mail, draft replies
Search files on the home computer, extract data from PDFs and documents
Download attachments from cloud services (Drive, Dropbox)
Manage the calendar: add, detect overlaps, propose reschedules
Keep the shopping and to-do lists
Answer questions about yesterday, last week, months ago
Remember birthdays, anniversaries, deadlines
Read the web when needed (weather, trains, specific news)
Proactive briefings: spontaneous messages at set times
Home delegation: ask the home-automation assistant to check sensors, lights, appliances
Multi-user family: your partner and children can have their own channel with different permissions
Remote access, over a secure tunnel (optional)
Write and run small scripts in the sandbox
Propose and build new executors when existing ones don't suffice
Audit log: every action leaves an inspectable trace
✗ What it will never do (or not yet)
Act on the internet without your explicit OK
Spend more than €5 in a day (hard cap)
Send messages to people not explicitly whitelisted
Delete files without showing them first
Leave the house: it doesn't control locks, alarms, cars
Read private data without you having handed it over
Change its own Laws (they are digitally signed, sealed)
Write in /etc, ~/.ssh and similar paths
Modify other projects' code (that's a different tool's job)
Automate browsers (no Playwright, initially)
Listen through microphone (no voice channel, for now)
Install new executors without your approval
The 4 Laws. Metnos operates under 4 rules that it cannot
rewrite on its own: (0) stay within the declared perimeter, (1) do no harm,
(2) obey only informed instructions, (3) always leave a trace. They are
written in a digitally signed file: if someone alters it, Metnos will not
start. This is the system's seat belt.
8. Getting started: install, day 1, essential commands
The pieces of the install
The real start takes an afternoon. The pieces are:
The mini-computer. An Intel N100 at ~€150 is plenty. Silent, 6–8 W consumption.
Ubuntu + installer. A guided installer configures everything (the end-user part is just answering two-three questions).
First Telegram pairing. You scan a code from the phone, and the phone is "paired" to your mini-computer. Everything stays in the family: Telegram is the channel, not the brain.
The first three personalisation files. One about who you are ("my name is Roberto, I live in X, my alarm is at 7"), one with your contacts ("my lawyer is studio.rossi@…"), one with things to know ("work attachments go into ~/Documents/work/"). They take 10 minutes to write, can be edited at any time.
Beginner mode. You start in "supervised": it asks confirmation for everything. After 10-15 days, once you've gained confidence, you unlock "autonomy full" on specific things (e.g. "you can read mail without asking").
Estimated time to first "wow". One hour for installation,
another for the first useful scene (typically "summarise my mail"). The
interesting things, instead, arrive after 2-3 weeks, when memory has begun
to know who you are — and after 1-2 months, when the system starts
to propose the first new executors born out of your use (scene 7).
The five things of day 1
Chat from the terminal.metnos chat
opens a local text session. The fastest way to talk to the agent,
supervised by default (asks confirmation for serious actions).
Chat from Telegram. A dedicated bot, paired once.
After that, writing to the bot is equivalent to talking to your
mini-computer from anywhere.
Run shell commands inside a sandbox. Examples:
check disk space, find a file in the workspace, answer "what's the
NAS IP?".
Read and write in the workspace
(/opt/metnos/workspace/). Here the agent has free hand
(always sandboxed). Outside the workspace, approval is needed.
Automate repeated tasks with cron. Example:
"every night at 22 summarise the system log and send me a Telegram
message if something unusual is there".
Essential commands
Command
What it does
metnos chat
Opens an interactive terminal chat
metnos chat --level readonly
Chat with minimum autonomy (useful for testing)
metnos session --level full --for 10m
Temporarily raises autonomy (self-expiring)
metnos pairing list
List known users per channel
metnos pairing approve telegram K7-DELTA-19
Approve a new Telegram user
metnos pairing revoke telegram @someone
Revoke a user
metnos cron list
See scheduled jobs
metnos cron add "22:00" "summarise daily log"
Add a job
metnos executor list
List available executors
metnos proposals
Pending new-executor proposals (the ones the synt has drafted)
Metnos does not decide which language model to run. The choice
lives in a separate system component (the LLM abstraction), which in
different environments can have different implementations. One place to
decide "which model runs in the house": Metnos inherits it.
9. Mini glossary
The complete glossary of the project — technical terms, components,
inspiration projects, people and places — lives in a dedicated document:
→ Open the Glossaryabout 35 entries, alphabetical, with links to canonical sources.
A few entries that recur in this document:
Executor
A tool in Metnos's toolbox. A simple script that does one thing;
invoked, it acts; not invoked, inert. Either present from day one, or
added by the synt after your approval. (For now, in some documents on
this site, the previous name — "neuron" — still appears. The
vocabulary shift is in progress.)
Synthesizer (synt)
The part of Metnos that can write new executors when needed. It
works on accumulated evidence (the half-finished attempts) and produces
drafts for your approval.
Gateway
Metnos's main process. Listens locally, manages channels, sessions,
cron. The always-on heart of the system.
Channel
A way to talk to Metnos. Terminal, Telegram, in the future voice
(through a dedicated home-automation assistant).
Autonomy
The level of freedom granted to the agent for the current session:
ReadOnly, Supervised (default, asks confirmation), Full.
Workspace
The agent's "home": /opt/metnos/workspace/. Personality
files, memory, audit log.
Sandbox
The limited space in which executors run: no network, no paths
outside those declared, CPU and RAM quotas, timeout. No executor can
escape it.
Home-automation assistant
A specialised agent for voice, sensors, home automation (wake-word,
STT, TTS, MQTT). Lives on the same mini-computer. Metnos does not
absorb its functions: it delegates them.
LLM abstraction
The abstract layer through which Metnos accesses language models,
without tying itself to a specific provider. Makes the system
provider-agnostic.
Metnos — Quick tour & Survival kit v1.1 — 23 April 2026
Meant to be read in 15-20 minutes by someone new, or as a refresher by
someone who is already in.