a partner, not a repository

every notes app i've used is a box. a good box, sometimes — fast search, backlinks, a graph view that looks great in screenshots. but a box has one behaviour: you put things in, and later you take them out. it never asks you anything.

the first post in this series argued that the rot comes from receiving — feeds and answer-machines both hand you finished output and leave your head unchanged. if that's true, then a tool that only stores, or only answers, is the same problem in nicer typography. this post is about the design law that falls out of that, and the three mechanics maios uses to obey it.

the law

the question is more interesting than the answer.

that's the ui rule. every empty state and every ai suggestion should ask back, not just fill in.

a suggested link between two notes doesn't silently appear in the graph. it says these two look related — are they? and waits: a checkbox you tick before it's written anywhere. a distillation of a long note doesn't replace it. it's an offer next to your own words, and it lands in the note only if you press append. and the step before that one asks you to write the summary yourself.

the answer is cheap now. a model will produce seven of them before you finish the sentence. what's scarce is the moment you check — the half-second where you go hm, is that actually true? and open the source. that moment is the rep. a good partner engineers more of them. a repository engineers none.

skeptical memory

the second mechanic is about the ai's memory of you, and it starts from an uncomfortable admission: the model's memory is a hint, not truth.

most ai tools with "memory" keep a text blob about you and paste it at the top of every conversation. it goes stale silently. the note it remembers got renamed; the project it thinks you're on got shelved in march; the model doesn't know, so it confidently builds on a version of you that stopped existing. that's not memory. it's a rumour.

maios's memory is a set of pointers into your graph — this project, this concept, this person — handed to the model with one standing instruction: treat all of it as a hint, not as truth. before it asserts anything specific about one of them, it's told to go and fetch it — actually fetch it, and its links — and reason over what came back. if the fetch comes back empty, it's told to say so rather than reconstruct the note from memory.

there's a nice side effect: the fetch is the audit trail. every tool call shows up in the chat as it happens, so when you wonder why it read that note, the answer is right there. no black box. the memory is skeptical of itself, and you can watch it check.

the human parallel is obvious once you see it. your memory of a book you read in 2019 is also a hint. go check.

the ai proposes, you approve

the third mechanic is the one i'd keep if i had to throw the other two away.

there are two kinds of thing the model can add, and neither goes straight in. the first is a change to your notes — a proposed link, a distillation. those are offers: a checkbox, an append button, a discard. nothing lands in a note you wrote until you press something.

the second is what the background agents infer about your graph — a claim that A relates to B. every one of those lands as a draft with its provenance attached: which notes it came from and how confident the model was. provenance can't be empty; a claim without a source is a guess. a draft only becomes canonical — the thing the rest of the app is allowed to treat as true — when it passes every check: grounded in the notes it cites, not contradicting anything already canonical. one objection keeps it a draft, and every verdict is kept on record. so the agents can argue in the background and your notes stay yours.

the confirm step on your notes is where the thinking happens. you read the proposed link. you either recognise it — yes, obviously, how did i miss that — or you don't, and either way something in your head moved. a swarm that auto-links your notes skips exactly that step. you'd end up with a beautifully connected graph of things you have never once thought.

why an auto-committing swarm is a bug

it's tempting. ten agents overnight, each one reading, linking, summarising. you wake up to a vault that's twice as rich. what's the harm?

two harms — one engineering, one worse.

the engineering one: cascading error. ten agents at 98% accuracy each is not 98% accuracy. it's a chain, and the chain rots. when an answer degrades in a long-running stochastic pipeline you need to know which sub-agent degraded it — and if all of them committed straight to your knowledge, you can't. you've got a black box, and you're living in it.

the worse one is the thesis of this whole series, re-implemented as a feature. if a swarm writes your knowledge, it's the swarm's knowledge. you're back to borrowed competence — the illusion of mastery without the wiring — except now it's at graph scale, and it looks exactly like the vault of someone who did the work. the model's other failure mode makes this sharper: when it hits ambiguity it doesn't confess. it hands your own vocabulary back to you, sounding deep. an unsupervised swarm doing that to your notes for a month isn't a second brain. it's a mirror that has learned to flatter.

so the rule in maios's own planning docs is blunt: a swarm that auto-commits to the user's knowledge is a bug, not a feature. the agents can propose all night. nothing they propose changes a note you wrote without your click, and nothing they infer becomes canonical without surviving every check, on the record.

friction, placed on purpose

none of this means the app is slow. it means the friction is in the right place.

capture should be frictionless — the target is under two seconds from thought to note, because a thought you didn't catch is a thought you can't work. synthesis is deliberately effortful, because synthesis is the part that builds anything. deletion is deliberately slower: a deleted note goes to the trash first, where you can bring it back, because destroying is the only step you can't undo. the shape is the same as the liquidation protocol from the last post: cheap in, slow to decide, slowest to destroy.

if you remove the friction from the deciding step, you haven't built a partner. you've built a faster box.

what a partner should do

this is the bar, not a feature list. it shows up in the morning with the three notes you wrote in june that describe the problem you're stuck on today, and it doesn't summarise them for you. it asks which one you think was right.

it notices two notes drifting toward each other over months and asks whether they're the same idea. you say no. it remembers that you said no.

it hands you a draft and waits.

the test for every feature is simple, and it's the one i hold every design review to: if it ends with you thinking less, it's the wrong feature, no matter how impressive the engine behind it. a repository stores what you know. a partner asks what you think.