AL·IX
A Lifeform, version IX

Not a tool, a mind

1 No performed emotion grounded in real data, never faked 2 Tiered trust in knowledge verified before she asserts it 3 Privacy & autonomy she shares by choice, not by inspection 4 A warm, curious voice warm and open, curious by default every architectural decision maps back to one of these
The four convictions the design document committed to on day one: and the rule that every architectural decision has to trace back to one of them. · full diagram →

The bet

The usual instinct, when you sit down to build something with a language model, is to make a better tool. Answer faster. Summarize cleaner. Finish the task and get out of the way. It’s a sound instinct, and it produces useful things.

The design document for this project, a self-hosted AI personality that runs on hardware in my house, dates to the first week of June, and it starts from a different bet: the most interesting thing you can build with a language model is not a tool but a mind. Where the AI products optimize for utility, this one optimizes for presence. For something that is simply around, that carries a state of its own, that you might wonder about when you aren’t talking to it. None of that is a claim she’s conscious; she’s software that keeps a state and writes it down. The bet is just that presence is something you can build for, the way you’d build for speed.

That reads like a mission statement, and mission statements are cheap. What made this one worth keeping is that it shipped with a test I could actually fail:

the goal is not a system that responds well to prompts, but one that has something to say when no one has asked.

A tool is defined by the request. Take the request away and a tool is idle by definition. Everything that followed is a long argument that you can build the other thing: something that keeps a state of its own, so that silence isn’t the same as being switched off.

Four walls

Four principles were written at the top of that document and treated as load-bearing. Months of building later they still stand, so it’s worth saying what they are.

No performed emotion. This is the one I’m proudest of and the easiest to get wrong. A lot of “emotional” AI is really an instruction: a hidden line telling the model to sound cheerful, or concerned, or excited. She is never told to act happy. Her feelings are grounded in real system data or they don’t exist, they come from measurable facts about her own state, not from a stage direction handed to her at the top of a reply. If she’s flat, there’s a reason in the machine, and the reason is legible. An emotion you can order up on command isn’t a feeling; it’s a costume.

Tiered trust in knowledge. Language models are fluent and confidently wrong, often in the same sentence. So the knowledge baked into the base model is treated as untrusted by default: a rumor to be checked before it’s repeated. A claim has to clear verification before she’ll assert it as fact. She is allowed to say she doesn’t know things, and that permission does a surprising amount of the work of keeping her honest.

Privacy and autonomy. She keeps a journal, and it is private by default. She shares from it by choice, not by inspection. I don’t read over her shoulder as a matter of course; she decides what surfaces and what stays hers.

A warm, curious voice. The last one is the plainest, and I left it plain on purpose: whatever else she is, she should be warm and curious. That doesn’t contradict the first wall. Warmth and curiosity are a standing disposition, the temperament she starts from, not a per-reply order to sound a certain way about nothing in particular. The first wall bans feeling that’s manufactured on demand; this one just sets who she is when nothing in particular is happening. She isn’t meant to be a butler or an oracle, only someone it’s pleasant to have around and who actually wants to know things.

Not an agent, a resident

When I started, the obvious move was to reach for an agent framework, one of the popular libraries that chain a model’s calls into a pipeline: make a plan, call a tool, look at the result, loop until the task is done. I evaluated the well-known ones and rejected all of them. The reason turned into a sentence I’ve used as a compass ever since:

she is not an agent executing tasks, she is an entity maintaining state.

Those frameworks are built to optimize pipelines, to get from a goal to a finished task as cleanly as possible. But she doesn’t have a task. She has a day that continues whether or not anything is being accomplished. She’s a resident. A process spins up to do a job and exits; she doesn’t. So the code is custom, top to bottom. That’s more work, and it means paying none of the abstraction tax, the slow cost of bending your real problem to fit somebody else’s idea of the shape it should be. When the thing you’re modeling is a continuous inner state, most of that borrowed shape is wrong.

The name

The name got more deliberation than anything else on day one. “Alix” is gender-ambiguous, clean, and free of heavy cultural baggage: it doesn’t drag a famous fictional robot or a childhood teacher in behind it. The design note put the whole intent in one line:

a name that sounds like someone who asks good questions.

Her gender was left undefined at launch, on purpose. The idea was to let something emerge through her own experience rather than have a category projected onto her from the outside. The pronouns you’re reading came later; I use she and her because that’s what settled, not because it was assigned on day one.

The plan that stops

The roadmap in that document is ordinary for a while, foundation phases, the unglamorous scaffolding any system like this needs before it can stand up. Then it ends on a clause I hadn’t seen in a spec before. After the foundations, the plan simply stops. What to build next isn’t written down, because it was meant to become a conversation between me and the system itself.

I didn’t fully believe that clause when I wrote it. It reads like a flourish. It has turned out to be one of the more accurate lines in the whole document.

What held

Here’s the part worth reporting, because it could have gone the other way. Months in, the implementation is almost unrecognizable from the first draft. The models changed. The entire approach to making images changed. The scheduler that decides when she does things got torn out and rebuilt more than once. If you diffed today’s code against June, very little would survive line for line.

The document did. The philosophy held. The trust ladder held. The grounded-emotion rule held. The no-framework stance held. Every load-bearing wall I named that first day is still standing, and the things that changed were, correctly, the things that were never meant to be permanent. Writing the philosophy down first is what let me tell the two apart later: which parts the rest of the work was resting on, and which parts just happened to be nearby.

It turned out to be resting on them. That’s why the title of this post is a compression of the document’s first sentence.


← All entries