myclaw, as drawn by the current architecture, is a reactive assistant: the user writes, the gateway kicks off a loop, the loop replies. This document introduces five families of capabilities that shift the centre of gravity: from reactive to ambient. myclaw stops merely replying and starts perceiving, collaborating, observing, proposing.
The base design stays valid: the four layers, the four Laws, the audit, the three-tier memory, graduated autonomy. But an ambient system introduces elements the reactive version does not account for:
FactProposal);This doc establishes each of these at the level of intent and architectural tension. The concrete microdesign will come later, in new Level-2 HTML docs that this doc lists in §5.
Today's architecture is request-driven: everything starts from a channel message, goes through the loop, ends with a reply. These capabilities are task-driven in time: a process scans, updates an index, notifies when something happens. A different model.
image_search(subject, date_range), file_dedup_report(path), voice_match(audio_clip). These are ordinary tools; they read an index, they don't build it.SOURCES.md: where the Indexer may look, which folders are off-limits).ActionProposal (see §2D).Channel (beyond CLI, Telegram, voice, cron). Implements the existing Channel Protocol, but the sender is another agent (e.g. agent:home-assistant), not a human.{intent: "query.calendar", date: "2026-04-23"}), not in natural language. Rationale: determinism, readable audit, no ambiguity.It isn't a tool. It's an operational regime: a way myc inhabits a chat. Different from not present (current), different from interactive (current), similar to conscious lurker in online-community vocabulary.
constitution.html dedicated to shadow mode: default off, enablable chat by chat, requires (a) user-written whitelist, (b) notice to chat members at the start of each session ("there is an assistant observing—it's mine"), (c) no recording of content unrelated to the owning user.kind="shadow_catch"; every thing it ignores is not recorded (otherwise the audit itself would violate third-party privacy).Today memory §6 (in Italian)
defines reflection as the producer of FactProposal: the proposal to
remember something. Creative proactivity is a generalisation:
reflection also produces ActionProposal, the
proposal to do something non-trivial (involving many files, many
records, repetitive actions).
@dataclass
class ActionProposal:
"""A large-scale action proposal that emerged from reflection."""
kind: Literal["restructure", "homogenize", "cleanup",
"enrich", "classify", "consolidate"]
scope: str # "~/Documents/work/" etc
impact: ImpactReport # how many records/files touched
rationale: str # why myc proposes this
plan: list[PlannedAction] # concrete actions, step-by-step
reversibility: Literal["reversible", "reversible_with_cost", "irreversible"]
confidence: float # 0..1, how confident myc is
created_at: datetime| Aspect | ApprovalRequest (today) | ActionProposal (new) |
|---|---|---|
| Origin | The loop is about to do something, asks permission. | myc has observed data, proposes something no one asked for. |
| Urgency | Blocks the loop until the user replies. | Blocks nothing. Sits in a proposals inbox until the user looks at it. |
| Implicit action | On timeout: the action does not happen. | On timeout: the proposal expires with no consequence. |
| UX | Yes/No/Let's-edit buttons in the active channel. | Evening digest, proposals inbox, preview sample, accept/reject/receive-fewer-of-these. |
A new UX surface. It deserves a dedicated proposal_ux.html.
tool.html already.They are tools in the strict sense of the current Protocol. They
implement the same interface as fs_read or shell_exec.
They go through Policy, approval, trace. They introduce no new
architectural components.
Families A, B and D generate unsolicited intentions: the indexer proposes a taxonomy, an agent suggests a delegation, proactivity proposes a reorganisation. We need a criterion to say which of these intentions make sense, without asking the user to evaluate them all. It is the evaluation function that the proactive agent, on its own, does not possess.
The reactive design doesn't face this problem: the user asks, myc executes, the evaluation is implicit in the request. The proactive agent is free to propose anything — and without a criterion becomes an enthusiastic noise generator.
A sixth file in the workspace, alongside IDENTITY, USER, MEMORY, AGENTS, SOUL. Written by the user, 3-7 short sentences. They are not reached, they are approximated: Aristotelian. Sample:
Each telos has a weight (priority in conflict) and an activation threshold. They can be revised at any time via a signed rite, like the Constitution.
Each proposal is evaluated with a single scalar:
expected_alignment = Σᵢ (weightᵢ · fitᵢ) · urgency · confidence − bother_cost
where:
weightᵢ = weight of telos i (declared in TELOS.md)
fitᵢ = how much the proposal advances telos i (0..1, estimated by LLM)
urgency = temporal pressure (deadlines, events)
confidence = myc's confidence in the estimate
bother_cost = cost of disturbing, grows with recent frequencyIf expected_alignment < θ → the proposal never reaches the
user. It lands in an internal journal the user may inspect at will
("proposals dropped today: 47"). The threshold θ is a
parameter, not a moral decision.
The TrustStore (already in
rl_offline, in Italian)
extends with a per-telos axis: if proposals tied to order get accepted in 8/10
recent cases, the effective weight of that telos grows. If those tied to
parsimony get ignored for 48 hours, the weight decreases.
Ignoring is a signal — weaker than a "no", stronger
than "not yet seen".
| Trap | Why dangerous | Countermeasure |
|---|---|---|
| Goodhart | If telos are measurable via overly-precise metrics, myc optimises the metric rather than the substance. | fitᵢ are estimated by the LLM with a textual explanation ("frees 2h/month because…"), not by hardcoded counters. The LLM judges the substance. |
| Paternalism | "Don't spend more than X" as a telos risks becoming moral judgement on the user's purchases. | Telos apply to what myc does for the user, not to what the user does. myc doesn't judge, it judges itself. To be written explicitly in constitution.html. |
TELOS.md: sixth workspace file. Manifest schema in workspace.html to extend.telos.html (new microdesign): schema, alignment function, bother budget, learning from silences, revision rite.memory.html §6: reflection produces ActionProposal already weighed against telos, not raw.rl_offline.html: TrustStore enriched with telos_fitness: dict[telos_id, EMA].constitution.html: distinction Laws vs Telos, anti-paternalism clause.fit values of the alignment function cannot be
entrusted to the LLM that generated the proposal: an LLM evaluates its
own outputs in a conforming way (self-enhancement bias, Zheng
2023). From this observation a second component emerged,
Vaglio (in Italian; gloss:
"the sieve"), which guarantees independence of context between proposer and evaluator. The
Vaglio has two phases of different natures: Guard
constitutional (deterministic, binary) and Judge
teleological (independent LLM, gradient). The principle articulating the
two phases is crystallised in the sentence: "The Constitution does
not judge; teleology does." — the Constitution verifies and,
on violation, blocks; otherwise stays silent. Only teleological
judgement produces a score. The full reconstruction of the reasoning is in
the Dialogue on ends and limits,
Giornate III-IV (Days III-IV).
Four of the five families (A voice-id, B agent channel, C shadow mode, D per-user proactivity) share a need the current design covers poorly: knowing who is speaking.
Today the binding is: sender = "<channel>:<handle>"
(e.g. telegram:@roberto). Episodic memory uses sender
as its key (see fix §3.5 in the coherence
review, in Italian). This is enough for a single user who always uses the same
channel.
As soon as voice-id, agents, shared home enter the picture, an extra layer is needed:
This introduces:
IdentityResolver: new component that given a sender returns an Identity with confidence. On low confidence myc can ask: "sorry, are you Roberto or someone else?".identity_id, not sender. The fix went in the right direction but will need refining.IdentityResolver is born already in phase 4
as singleton identity (always Roberto). The structure exists but
handles one user only. This lets us introduce voice-id without
refactoring everything afterwards.
These capabilities introduce frictions with the 4 Laws that the current design can't resolve in-situ. Listing the most important ones with a provisional verdict.
| Tension | Family | v1 verdict | Rationale |
|---|---|---|---|
| Listening to third-party chats without explicit consent | C. Shadow | block | Dedicated sub-law required before release. Default off, written whitelist, notice in chat. |
| Recognised human faces → labelled with a name | A. Perception | gate | Clustering OK (cluster_id). Cluster → name association only via approved ActionProposal. |
| Voice ID of anyone passing by the microphone | A. Perception | gate | Recognise only voices enrolled in the workspace (explicit enrollment). Unknown voices → unknown_speaker. |
| A sibling agent delegates actions without user confirmation | B. Multi-agent | block | No external agent can sign approvals on the user's behalf. Inter-agent request → standard approval loop. |
| Proposal to rename 300 files with no preview | D. Proactivity | gate | ActionProposal must always include: preview, impact count, rollback plan. Without those, automatic rejection. |
| Web search on sensitive topics (finance, health, minors) | E. External | gate | Topic list where search drops to supervised even in full autonomy. |
| Indexer scans directories with personal files of other housemates | A. Perception | block | Indexable sources only those declared in SOURCES.md. No autonomous discovery. |
This section lists the new Level-2 docs the five families will require. It does not replace the canonical order of Perspectives & Judgement §8 (in Italian), which stays valid until completed. It appends to it.
| # | New doc | What it covers | Phase |
|---|---|---|---|
| 1 | telos.html | TELOS.md, alignment function, bother budget, learning from silences. Foundational for families A, B, D. | 4-5 |
| 2 | indexer.html | Long-running process, scan, embedding, persistent indices. Completes family A. | 5 |
| 3 | identity.html | IdentityResolver, multi-channel evidence, voice enrollment, confidence. Makes human identity a primary concept. | 4 |
| 4 | agent_channel.html | Fifth channel, symmetric pairing, inter-agent vocabulary, delegation. Completes family B. | 6 |
| 5 | shadow_mode.html | Listening regime, constitutional sub-law, filters, intensified audit. Completes family C. | 7+ |
| 6 | proposal_ux.html | ActionProposal, proposals inbox, evening digest, preview. Completes family D. | 5 |
| 7 | extensions to tool.html | web_search, calendar_read, calendar_write tools. Family E — no new doc needed, an appendix suffices. | 3 |
| 8 | extensions to constitution.html | "Applicative extensions" section with the 7 sub-laws from §4 + the anti-paternalism clause of telos. | 2 |
| 9 | extensions to workspace.html | Add the 6th file TELOS.md to the workspace manifest. | 4 |
| 10 | extensions to memory.html and rl_offline.html | Reflection produces ActionProposal weighed against telos. TrustStore adds telos_fitness axis. | 5 |
Five new docs (telos, indexer, identity,
agent_channel, shadow_mode, proposal_ux),
four extensions. None of these blocks the 19 already-approved microdesign
docs. None of these requires rewriting an existing doc.
telos.html and identity.html. The first because
it is foundational to three families (A, B, D): without the alignment
function, proactivity is unusable. The second because it unblocks four
families and requires refining fix §3.5 from the coherence review
(episodic indexed by identity, not by sender). All the others can follow
by phase.
The release phases from Neurons & Memory §12 stay valid. Here the five families are mapped onto phases, with internal priority.
| Phase | Existing focus | Additions from this doc |
|---|---|---|
| 1 | skeleton + CLI + sandboxed shell | — |
| 2 | policy + workspace + audit | Extension of constitution.html with the 7 sub-laws |
| 3 | Telegram + pairing | web_search, calendar_read tools (family E) |
| 4 | memory + failover | identity.html (initial singleton-identity), telos.html (contract), TELOS.md in the workspace |
| 5 | voice, tunnel, dashboard | indexer.html, proposal_ux.html, activation of the alignment function (families A+D+F together) |
| 6 | neurons, synthesis, synapses | agent_channel.html (family B) |
| 7+ | maturation | shadow_mode.html (family C, after commissioning and sub-law) |
Phase 5 becomes denser this way: indexer and proposals inbox are both daily-use capabilities that change the perception of the product. Intended: phase 5 is the jump from "prompt → reply" to "myclaw surprises me".
Mykleos — Extended Perspectives v1.0 — 22 April 2026
Opens a second design branch: from reactive to ambient. Does not replace any doc.