metnosMetnos is the project of an assistant: not a chatbot, and not an "autonomous agent" in the sense in which that expression has by now been drained of meaning — but a system designed to act on the user's behalf, and, with the same care, to know when to stop. The interesting part of such a system is not the code: it is the definition. To write, before writing the code, how it ought to be made, which limits it honours, and in what vocabulary it addresses the human who uses it. That is the part which code, on its own, could never produce.
Neighbouring ideas have already been explored by openclaw and zeroclaw. It is from them that this project draws courage, and to them goes, first of all, my acknowledgement. Metnos does not wish to be a clone: it is a starting point for experimenting with a few specific ideas — the distinction between laws and ends, the separation between whoever proposes and whoever judges, the care not to turn usefulness into intrusion. A testing ground, not a solution.
Not the code. Good code, someone will write better than me — and that is fine. Here you will find the documents: the architecture, the decisions, the days of reflection. The process of definition, not the product. A reader of these texts receives, on closer look, a more durable object than any implementation: a set of motivated choices, and a way of reasoning that can be reused elsewhere. And in the end, yes, also the code — but only the code that is needed to reassure the author and the reader that ideas must, sooner or later, find their way into reality.
This project has been written with the constant help of an artificial intelligence system. Much of what you are reading, the SVG figures of the documents, the tables, the microdesign pages, were born from a dialogue with a machine that held the pen when mine grew tired. It is not merely a confession: it is the point of the project itself. Metnos imagines an assistant that gives wings to the one who uses it, so that they can focus on analysis rather than on execution. Building its definition with an assistant is already, in miniature, a proof of concept. A recursive experiment.
The dialogues are the trace of the thought behind Metnos, put under the pressure of objection: not treatises, not specifications, but ideas compelled to answer an uncomfortable peer. The form is Galilean — two voices, both the author's, one of which refuses to give easy agreement. Not fiction: only the structure is dialogic, the content is real.
Roberto and The Other, in four Giornate. From how the need for ultimate ends first arises, to the cardinal sentence — the Constitution does not judge; teleology does.
EnterFour Giornate. What a system that does not learn can remember; whether Metnos is an organism, a mirror, or an ecology; the emergent shape of the mnestome, read through network medicine; and the final test — the six principles that hold the rest together and the technical specification as the next step. Executors, mnests, traces, ager, the table.
EnterA fair question, after all this philosophy. The code is not (yet) here, and that is by design. Every document on this site is upstream of the code: the rule is that a component is not implemented before its HTML exists and has been approved. When the definition is ripe enough that building it becomes an exercise in fidelity rather than translation, the code will follow — and will look like the documents, not the other way around.
But there is a stronger reason to linger here before chasing the beef: we would rather you did not jump even to the design documents without first passing through the dialogues. The microdesign pages and the architecture encode decisions; the dialogues show how those decisions were earned. Read the design first, and you receive conclusions without the objections, components without the rejected alternatives, names without the struggle to name them. Read a dialogue first, and you arrive at the same decisions with the doubts still attached — which is what lets you judge, later, whether a surprise in the system is a bug or a consequence to accept.
If you are about to dive into the architecture or the microdesign, read at least one dialogue first. The rest of the documentation will speak a different, richer language afterwards.
If you would like the how after the why, three other doors:
One HTML document per component of the architecture. Rule: a component is not implemented before its HTML exists and has been approved. Today there are 21 approved documents, covering the full Phase 1 design and the subsequent extensions.