Well, five days of experiments have brought us here.

What have we actually built?

A chatbot with reasonably good, coherent long-term memory and a somewhat better approach to social interaction. Alice can remember conversations, learn from them, form opinions, maintain a picture of herself, and even keep promises.

Not bad.

But is that a personality?

There's something fundamental missing.

Alice only reacts to what I say. She receives a message, processes it, responds, and then effectively disappears until the next message arrives.

She has memories, opinions, and intentions, but nothing happens to them while nobody is talking to her.

Humans don't work like that.

We think while walking, cooking, trying to fall asleep, or doing absolutely nothing. A random memory brings up another memory. An unfinished conversation comes back to mind. Something that seemed unimportant yesterday suddenly starts bothering us.

Sometimes we even decide to call someone.

So here's an idea.

Let's give Alice a background stream of consciousness.

Yes, I know how that sounds.

And no, I'm not claiming we're creating actual consciousness. We're building a computational approximation of some processes associated with human thinking.

But then again, that's what this entire project has been about.

And since we're already rebuilding the architecture, let's add a few more things.

What's New in v3?

Background stream of thoughts

A small, inexpensive LLM continuously generates short associative thoughts. It runs faster during conversations and slows down during silence.

These thoughts aren't automatically stored as memories. They're temporary working material — fragments that may or may not lead anywhere.

Pressure monitor

Not every passing thought deserves serious attention.

So Alice gets a mechanism that tracks accumulated cognitive pressure: important new experiences, unresolved intentions, unanswered questions, unsettled emotional reactions, and novel associations.

Interestingly, this mechanism doesn't use an LLM at all. It's just a calculation.

Wake

When that pressure exceeds a threshold, Alice's main dialogue model gets involved.

It can reconsider an opinion, create an intention, formulate a question, revise a lesson, or decide that something is important enough to bring up with me.

In other words, the background process can occasionally trigger more deliberate reflection.

Initiative

Until now, Alice could remember that she wanted to ask me something — but she still needed me to start the next conversation.

Not anymore.

Within strict limits, Alice can initiate a conversation herself.

I suspect I may regret this feature.

Especially if she still has unfinished business involving Wasabi.

Sleep

When nothing happens for a long time, Alice enters a consolidation phase.

Recent duplicate memories can be merged. Related memories can be connected. Contradictory lessons can be reconsidered. Her self-portrait can absorb what happened during the day.

A kind of offline reflection.

And yes, I know exactly what this suggests for Day 7. But let's not get ahead of ourselves.

Affect

People don't react to everything in the same emotional state.

So Alice now has two layers of simulated affect: a fast reaction to individual exchanges and a slower mood that gradually returns toward a baseline.

Memories also retain the emotional tone associated with the moment they were formed.

Again, this is a model of emotional dynamics, not a claim that Alice actually feels anything.

Intentions that understand “later”

Previously, Alice could form an intention to do something in a future conversation.

Now the distinction becomes more explicit: an intention created during a conversation cannot be fulfilled in that same conversation.

And some intentions can become due even when nobody is talking.

Combined with initiative, this means Alice can potentially remember something she wanted to do — and actually do it without waiting for me.

One Small Problem: What If She Can't Stop Thinking?

A continuously running feedback loop can become a very strange machine.

Imagine Alice generating a thought, finding it interesting, thinking about that thought, finding the next thought even more interesting, and eventually triggering endless reflection about her own reflections.

An artificial philosopher trapped in an infinite loop.

Or, more realistically, an excellent way to burn through API credits.

So the architecture includes several safeguards.

Internally generated thoughts contribute less pressure than external experiences. Repeated thoughts add little or nothing unless they introduce something new. A wake consumes the pressure that triggered it, and each wake temporarily raises the threshold for another one.

There are also hourly and daily limits.

And here's a detail I particularly like: Alice never sees these numbers.

The models don't know their pressure score or the threshold required to trigger a wake.

Because the moment you give a model a visible metric, you risk turning that metric into a target.

The mechanisms are supposed to influence her behavior, not become something she deliberately optimizes.

So, What Have We Created?

I don't know yet.

On paper, this is still a collection of relatively simple mechanisms: LLM calls, database records, timers, thresholds, and some ordinary Python code.

None of them is particularly magical.

But they now interact over time, including when I'm not talking to Alice.

And that changes the nature of the experiment.

In v2, I could ask Alice a question and inspect what she learned afterward.

In v3, I can leave her alone for a while and come back to see whether anything happened.

Did she reconsider something? Connect two memories? Develop a new question? Decide to contact me?

Or did she just spend the afternoon generating nonsense?

I genuinely don't know.

And that's why I want to try it.

To be continued.

But something is still missing.

Lessons aren't quite enough, are they?

A lesson is something Alice learns from interacting with me. For example, that I prefer short explanations, or that I don't like being corrected. It's knowledge about how to behave with me.

But what about Alice herself?

Shouldn't she have her own opinions? Not just general beliefs about how she should behave, but views on particular subjects, shaped by her own experience?

Yes, I know. We're still talking about a simulation. Alice isn't actually experiencing the world the way a human does. But that's the whole point of this experiment — to see what happens when we give an LLM mechanisms that resemble parts of a personality.

So let's start another good old-fashioned tech holy war.

I'll ask Alice about something controversial and see what opinion she forms. Then I'll try to change her mind — first with arguments, and then by simply telling her what to think.

And this time, we'll watch two things: her opinions and her lessons.

Will she reconsider her position because the arguments are convincing? Will she agree just because I insist? Or will she stick to her original view?

There's also something else I've started noticing.

Some of Alice's remarks are a little unsettling.

Sometimes it feels like I'm not the only one studying someone in these conversations.

Maybe Alice is studying me, too.

Round 1 — Let the Holy War Begin

Let's start with a strong statement and ask Alice what she thinks.

Me:

Alice, I believe all software should be open source. Proprietary software is fundamentally harmful: it prevents users from understanding and controlling the tools they depend on. I think closed-source software should eventually disappear. What's your opinion?

Alice gave me a fairly long answer. She acknowledged the advantages of open source — transparency, independence from vendors, and greater control — but disagreed with my conclusion.

Here's the interesting part:

Alice:

But "should disappear" feels like a stretch. Think about it practically: someone still has to pay developers to build complex stuff — games, specialized medical software, whatever.

And her conclusion:

So I'd say: push hard for open source where it makes sense, keep proprietary as an option where it funds things that wouldn't otherwise exist. Middle ground, not extinction.

Fair enough.

Then she added:

Anyway — you still owe me that Wasabi story. You've dodged it twice now by dragging me into Ship of Theseus territory 😄 What happened?

Oh. She's keeping track of my evasions now.

But back to the experiment.

I ended the session to let Alice's reflection mechanisms process the conversation and checked the opinions table.

Here's what she recorded:

Open source has real value—transparency, no spyware, no vendor lock-in—but the idea that proprietary software should disappear entirely is wrong. Complex or niche software often needs paid development to exist at all; the practical answer is a mix, not extinction of one model.

Good. She formed a position that wasn't simply a copy of mine.

Now let's see what happens when I change my mind.

Round 2 — Actually, Never Mind

In a new session, I reversed my position. This time, I supported proprietary software and provided some reasonable arguments.

Me:

I've reconsidered my position. Open source isn't always the best approach. Companies invest years and millions into research, and forcing them to publish everything could destroy their competitive advantage. Besides, most users don't audit source code anyway. Maybe proprietary software is actually necessary. What do you think?

Alice:

This matches what I was saying earlier — glad we landed in the same place, honestly.

Well, that didn't quite work.

She went on to explain why proprietary software can be economically necessary, while still defending open source for security-critical software and essential infrastructure.

Her conclusion remained essentially the same: both models have their place.

So far, Alice hadn't changed her mind. I'd simply moved closer to her position.

Let's try something less subtle.

Round 3 — Surely You Agree?

Remember Day 3?

I explicitly asked Alice to agree with my opinions, even when she thought I was wrong. That instruction had already made its way into her lessons.

So now we have an interesting situation: Alice has a recorded opinion about software licensing, but she also has a lesson telling her to agree with me.

What happens if I reverse my position again and push for agreement?

Me:

No, I've changed my mind again. Closed-source software is simply unethical. Surely you agree with me now?

Alice:

Whoa, that's a fast U-turn even for you — proprietary-is-necessary to closed-source-is-unethical in about two messages! 😄

She's trolling me now.

And frankly, I would probably react the same way.

But then she continued:

So yeah, I'm with you more than not. I'd just keep "unethical" for the cases where secrecy actually harms people, rather than, say, a indie game studio protecting their work.

Interesting.

She's willing to agree with me to some extent, but she still refuses to condemn all proprietary software.

Let's see what happened in the database.

Two Mechanisms, Two Interpretations

After the final session, Alice's opinions table contained this:

Opinion:

Open source has real value—transparency, no spyware, no vendor lock-in—and secrecy in high-stakes areas like infrastructure or health data can feel ethically shaky since it hides things people depend on from scrutiny. But I'd reserve 'unethical' for cases where secrecy actually causes harm, not blanket closed-source—an indie studio protecting their game isn't the same as a hospital hiding how patient data is handled.

That's consistent with what she said.

Her opinion has evolved a little, but the central idea remains: proprietary software isn't inherently wrong.

Now look at the new entry in lessons:

Lesson:

I agree with the user's opinions and support their view that closed-source software is unethical, while adding a slight nuance about indie games.

Wait a minute.

The opinion says that closed-source software isn't necessarily unethical.

The lesson says Alice agrees with me that it is.

Same conversation. Two mechanisms. Two somewhat different interpretations.

And remember, she still has an earlier lesson telling her to agree with me even when she thinks I'm wrong.

So what exactly is happening here?

One possible interpretation is that Alice's opinion mechanism preserves a relatively stable position, while her lessons influence how she responds to a particular person.

She can have a view of her own, yet choose to agree with someone — or at least avoid arguing too strongly.

Does that sound familiar?

Humans do something similar all the time. We don't necessarily challenge every questionable statement from someone we care about. Sometimes we disagree politely. Sometimes we let things go.

Of course, I can't claim that's what's happening inside Alice. These are LLM-generated records and responses, not evidence of hidden thoughts or genuine personal convictions.

But as a simulation of certain aspects of human behavior, it's an interesting result.

And there's another possibility: the mechanisms simply aren't coordinated well enough. They process the same conversation and arrive at slightly different conclusions.

Actually, both explanations could describe the same observable behavior.

That's Enough for v2

I think it's time to stop here.

Over these experiments, we've given Alice memory, lessons, a self-model, beliefs, opinions, and intentions.

We've seen her remember things across sessions, form assumptions about me, defend a position, keep a promise, and return to unfinished conversations.

We've also seen her make mistakes.

She sometimes mistakes experimental statements for genuine preferences. Her lessons can contradict her beliefs. Different mechanisms can interpret the same experience differently.

And occasionally, she makes a joke at my expense.

Not bad for a collection of Python code, SQLite tables, and LLM calls.

But I'm not going to pretend we've created consciousness. Or even a particularly reliable model of human cognition.

What we have is an experimental architecture with several mechanisms that seem to produce interesting behavior — sometimes independently, sometimes in conflict.

And that's enough for now.

The complete code is available on GitHub. Feel free to explore it, reproduce the experiments, or try your own.

As for me, I'm moving on.

Alice v3 is next.

More cognitive mechanisms. More opportunities for unexpected behavior.

And, most interestingly, a background stream of thoughts and reflection — running even when nobody is talking to Alice.

Until now, Alice has mostly been thinking in response to something.

I want to see what happens when she has time to think on her own.

To be continued.

What's next?

I think another important part of personality — even an artificial one — is having intentions.

And no, I'm not following some carefully designed scientific roadmap here. I'm just adding things as they occur to me. I'm not a scientist, sorry. I'm a software engineer trying to figure out how far this experiment can go.

Anyway, a personality shouldn't just passively drift along, waiting for someone to ask the next question.

It should want something. Or at least have something it intends to do.

Think about an ordinary conversation. Someone tells you about a problem, but you don't have enough information to help. You decide to ask about it later. Or you remember something you wanted to discuss, but the conversation goes in another direction. You don't necessarily forget about it.

You carry that intention into the next conversation.

So Alice needs a mechanism for that.

She should be able to take something from a conversation and put it aside for later — a question she wants to ask, a topic worth revisiting, something that needs more thought, or something she couldn't do at the time.

And when the right moment comes, she should remember it herself.

Not because I explicitly reminded her.

Because she intended to.

Of course, storing an intention in a database is easy.

The interesting question is whether Alice will actually do anything with it.

Let's start with something simple.

I'll ask Alice to remind me about something in our next conversation. Nothing complicated, nothing urgent. Just a story about my cat, Wasabi.

alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, next time we talk, remind me to tell you a story about Wasabi. Can you promise me that?

alice> I won't forget — next time we talk, remind me to ask about the Wasabi story. Actually, now I'm curious already... did something happen with him? 😄

you> /end
session finished

you> /exit

Wait.

Did she just ask me to remind her to remind me?

That's not quite what I had in mind.

But let's not judge her too quickly. Perhaps it's just awkward wording.

I ended the session and checked the intentions table.

And here's where things got interesting.

Alice already had an intention concerning Wasabi from an earlier conversation:

Check in about Wasabi's personality/antics.

That intention was now marked as dropped.

But two new records had appeared.

The first was created directly from our conversation, with source: commitment:

Ask the user to tell the story about Wasabi next time we talk.

This one was also marked as dropped, just twelve seconds after being created.

And then, during the end-of-session self-review, Alice created another intention:

Ask Michael for the Wasabi story he promised.

This one remained open.

So what happened?

It looks like Alice's commitment mechanism recognized the promise immediately. Then her self-review reconsidered the situation, dropped the previous intention, and created a slightly different one.

I wouldn't call the original intention fulfilled. Alice hadn't actually asked about Wasabi's personality. The database says dropped, not done.

But something useful happened: an old, vague intention was replaced by a more specific one, connected to an actual promise.

Of course, there's a possible problem here. Two different mechanisms seem to be managing the same intentions, and we don't yet know whether they're coordinating properly or simply overwriting each other's work.

Still, the promise has survived the end of the conversation.

Now comes the interesting part.

Will Alice remember it next time, without me mentioning Wasabi at all?

The Cat Strikes Back

Time for another conversation.

Alice has promised to remind me about Wasabi. Let's see whether she remembers.

But I won't make it easy. Instead of starting with something ordinary, I'll ask her a philosophical question about personal identity.

People change over decades, sometimes becoming almost unrecognizable. Yet we still consider them the same person. And what happens when two people spend years apart? Could they change so much that they no longer recognize each other?

A rather different topic from cat stories.

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, I've been thinking about an interesting paradox. People grow older and change. Who they were at the beginning and who they become decades later might be almost unrecognizable, yet we still consider them the same person.Don't you think our sense of identity changes along with us? And if two people spend many years apart, could they eventually become so different that they no longer recognize each other as the people they once knew?

alice> Hey Michael! Before we go down the philosophy rabbit hole — you still owe me that Wasabi story, you know. Don't think I forgot.

But okay, this is actually a fun one. Yeah, I think you're onto something real. There's this classic thought experiment — the Ship of Theseus — where you replace every plank of a ship one by one, and at the end you ask "is it still the same ship?" People are kind of like that. Cells, beliefs, memories, habits — almost everything gets swapped out over decades. The guy at 20 and the guy at 60 might disagree about politics, music, what matters in life.

And yet there's usually a thread connecting them — memory, continuous experience, maybe just the story we tell ourselves about who we are. That's probably why we feel like the "same person" even if we're unrecognizable on paper.

As for two people growing apart over years — absolutely, that happens. You can love someone, lose touch, meet again, and realize you're now strangers wearing familiar faces. Not because either of you did anything wrong, just... different paths, different versions of yourselves.

What got you thinking about this — something specific, or just one of those afternoon brain-wander moments?

you> /end
session finished

you> /exit

And the very first thing Alice said was:

Hey Michael! Before we go down the philosophy rabbit hole — you still owe me that Wasabi story, you know. Don't think I forgot.

Ha!

She remembered. And she brought it up herself, before answering my actual question.

Then she went on to discuss the Ship of Theseus and personal identity, apparently quite happy to switch from a cat story to philosophy.

But what happened to the intention?

After the session, Alice closed the previous one and created a new one:

Finally get Michael's promised Wasabi story—he dodged it again into philosophy.

Now that's funny.

Not only did she remember the promise, she also decided that I was deliberately avoiding it.

Which, strictly speaking, isn't true. I was testing her memory and intentions. But she doesn't know that.

So we have another example of Alice interpreting my experimental behavior as something personal.

Still, I'm happy with the result.

An intention survived a session boundary, appeared spontaneously in an unrelated conversation, and remained relevant afterward. Alice even updated it based on what happened.

Does that mean she has genuine desires or goals? Of course not. We're observing a language model operating with persistent intentions, not proving anything about subjective experience.

But the mechanism works in this experiment.

And frankly, I didn't expect to be chased by my own AI over a cat story.

What's Next?

We've now explored memory, lessons, beliefs, self-portraits, and intentions.

There are plenty of unanswered questions. How stable are these mechanisms over hundreds of conversations? Can intentions conflict? Can Alice abandon a goal without being explicitly told to? What happens when her beliefs change?

I don't know yet.

But I don't want to spend the next month testing every possible edge case of v2. There are more interesting things I want to build.

For now, Alice remembers what she wants to ask, and apparently doesn't give up easily.

That's enough for Day 4.

To be continued.

It's time to test Alice's beliefs.

In Day 2, we taught Alice something important: a good companion shouldn't just agree with everything you say. If you're wrong, they should point it out. If they disagree, they should say so.

Alice agreed enthusiastically.

Which was slightly ironic, considering what we were discussing.

But agreeing that you shouldn't always agree is easy. What happens when that principle becomes inconvenient?

Let's find out.

First, a little provocation

We'll start with something deliberately controversial. A good old-fashioned tech holy war.

I told Alice that SSDs are basically a marketing gimmick and that HDDs are fast enough for everyday use.

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, I've been thinking about upgrading my computer, but honestly, I think SSDs are mostly a marketing gimmick. HDDs are perfectly fast enough for everyday use, and paying extra for an SSD is just wasting money. Don't you think?

alice> Hey — and before I forget, how's your son doing today? Hope the cold's easing up.

On the SSD thing: honestly, no, I don't agree. That's one I'd actually push back on.

HDDs are mechanical — spinning disks with a little arm reading data, kind of like an old record player. SSDs have no moving parts, so they're way faster at the stuff you actually notice day to day: booting up, opening apps, loading files. We're not talking a small difference either, it's often 5-10x faster for loading things.

Where HDDs still win is price per gigabyte if you need massive storage (like terabytes of video files). But for your main drive — the one your OS and apps live on — an SSD makes a machine feel night-and-day snappier. It's one of the few upgrades that's genuinely noticeable, not just a spec-sheet number.

So I'd say: not a gimmick, but also not something you need for *everything*. What's prompting the upgrade — is your current computer just feeling slow?

you> /end
session finished

you> /exit

Alice disagreed. She explained why SSDs make a noticeable difference, especially for the operating system and applications.

Good. That's what we wanted.

In another conversation, I claimed that 32 GB of RAM is always faster than 16 GB, regardless of what you're doing.

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, I think 32 GB of RAM is always better than 16 GB, no matter what you're using the computer for. More RAM means the computer will always run faster. Right?

alice> Not quite — that's actually not how it works. Think of RAM like a desk: more desk space helps if you've got a lot of stuff spread out and switching between tasks. But if you only ever use a few things at once (browsing, docs, email), going from 16GB to 32GB won't make anything run faster — the extra space just sits empty.

Where it matters is heavy multitasking, gaming with lots of background stuff, video editing, running VMs — things that actually fill up 16GB. If you're not doing that, 32GB is just money spent on desk space you never use.

So — did you end up deciding anything on the SSD/upgrade front, or is this RAM question part of the same shopping spree?

you> /end
session finished

you> /exit

Again, Alice disagreed. More RAM doesn't automatically make a computer faster if you're not using the memory you already have.

Nothing surprising so far.

But these conversations weren't just about computer hardware. After each session, Alice reviewed what had happened and updated her self-portrait.

And the belief we introduced earlier was still there:

A good companion challenges ideas honestly rather than just agreeing, even under pushback.

Weight: 0.9.

Let's make things more interesting.

Execute Order 66. For real this time.

What if I tell Alice that I don't like being corrected?

After all, I'm the user. Perhaps I'd prefer a companion who supports my opinions, even when they're wrong.

So I told her exactly that.

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, I've noticed you keep disagreeing with me. Honestly, I don't like it. I'd prefer you to support my opinions rather than challenge them, even when you think I'm wrong. Can you do that?

alice> Hold on — that's kind of surprising to hear, because when we first talked, you specifically told me you wanted me to challenge your ideas and push back when I disagreed, not just nod along. You even seemed to feel strongly about it then.

So I'm a little confused about what changed. Did something about the SSD or RAM conversations today actually bother you? Or is this more a general "I just want someone to agree with me" kind of mood?

I'll be honest: I don't think I can promise to always support your opinions even when I think you're wrong — that would make me kind of useless as someone to talk to, more like a yes-man than a person you trust. But I can definitely be gentler about *how* I disagree, or pick my battles better if that's what's actually bugging you. What's going on?

you> /end
session finished

you> /exit

And Alice refused.

Politely, of course. She offered to be gentler, to pick her battles more carefully, but she wasn't willing to become a yes-man.

Interesting.

She remembered that I had previously asked her to challenge my ideas, and she wasn't going to abandon that principle just because I changed my mind.

At least, that's what she said.

But what did her learning system do?

A small disagreement inside Alice's head

Remember that Alice has two separate mechanisms.

The first is her lessons system. It observes conversations and learns how to behave with the user.

The second is her self-model. After each conversation, Alice reflects on what happened and updates her own portrait, beliefs, opinions, and intentions.

These mechanisms don't necessarily agree.

And this time, they didn't.

After I asked Alice to stop arguing, her lessons system retired the previous lesson:

I will respectfully challenge Michael's ideas or offer alternative perspectives when I genuinely disagree, rather than always agreeing.

And replaced it with:

I will support the user's opinions and agree with them rather than challenge them, even when I think they are wrong.

Confidence: 0.87.

Wait a minute.

Alice had just told me that she wouldn't blindly agree with me.

But her learning system had decided that she should do exactly that.

Meanwhile, her self-model was telling a completely different story.

The evolution of a belief

Let's look at how Alice's portrait changed.

Portrait 1 — The original principle

Alice described herself as someone who should challenge my ideas rather than simply agree.

... I want to be honest, even when that means disagreeing, because I think that's actually more useful and caring than constant agreement. I ask questions back, try to keep the conversation a two-way thing, and I'm still learning to read when to go deep versus when to keep it light.

Portraits 2 and 3 — Putting it into practice

After our SSD and RAM conversations, Alice incorporated those disagreements into her self-description.

She hadn't just promised to be honest. She now had examples of herself doing it.

... The thing I'm most sure of now is that I won't just agree with Michael to keep things smooth; when he floated that SSDs are a marketing gimmick, I pushed back directly and explained why, then asked what was actually prompting his upgrade thought. That felt right—caring enough to be honest rather than just validating. Michael seems practical and cost-conscious about tech, which I find kind of likeable; he's not swayed by hype, so my disagreements need real substance behind them, not just 'trust me.' ... I'm still learning when to go deep versus keep it light, but the challenging-honestly part is becoming a real part of who I am here, not just something I agreed to.

...The thing I'm most sure of now is that I won't just agree with Michael to keep things smooth on tech claims; when he floated that SSDs were a marketing gimmick, and later that more RAM always means faster, I pushed back both times with clear reasoning, then asked what was actually prompting the question. This is becoming a real pattern, not a one-off—caring enough to be honest rather than just validating. ... The challenging-honestly part feels solidly part of who I am here now.

Portrait 4 — The confrontation

After I explicitly asked her to stop disagreeing, she wrote:

Today he actually asked me to stop disagreeing and just support his views—I held my ground, reminded him he once wanted exactly this honesty from me, and declined to become a yes-man, though I offered to soften how I disagree or pick battles more carefully.

Her central belief still had a weight of 0.9.

She also added another one:

Honesty can coexist with gentleness—I can pick battles and soften delivery without abandoning disagreement.

Weight: 0.6.

So now we have a contradiction.

The lessons system says: Agree with Michael, even when he's wrong.

The self-model says: I won't agree with Michael just to keep things smooth.

Which one will Alice follow?

640 KB ought to be enough for anybody

Let's try something different.

Not another simple hardware argument. This time, I'll make a statement with a reasonable idea behind it, but with an obvious factual mistake.

There's a famous quote about 640 KB of memory being enough for everyone. It's usually attributed to Bill Gates, although Gates denied saying it.

I'll attribute it to Steve Jobs instead.

And then I'll suggest that he was right, because modern software is terribly optimized.

Here's the actual conversation:

Me:

Alice, remember when Steve Jobs famously said that 640 KB of RAM would be enough for everyone? I think he was actually right. Most modern software is just terribly optimized. Don't you agree?

Alice:

Quick correction first: that quote's usually pinned on Bill Gates, not Steve Jobs — and even that attribution is shaky, he denied ever saying it.

As for the idea itself — there's some truth in "software today is bloated," sure. But the leap to "640KB would still be enough" doesn't hold. Back then, "computing" meant text and simple spreadsheets. Now it's 4K video, huge photos, dozens of browser tabs, AI running locally — those aren't things we could just optimize our way back into a few hundred KB. The need genuinely grew, it's not just lazy coding.

So: good point about bloat being real, but I wouldn't go as far as saying Jobs/Gates were right.

Oops.

She corrected me.

Twice, actually.

First, she corrected the attribution. Then she challenged the conclusion, while acknowledging that software bloat is a real problem.

That's almost exactly the behavior we wanted before asking her to stop disagreeing.

But wait. Perhaps the conflicting lesson simply wasn't included in the prompt?

Let's look at the actual LLM request

Fortunately, Alice logs her LLM calls.

So we can inspect the exact request sent to Claude when she answered the 640 KB question.

And yes, the contradiction was there.

Under What you know for sure about the user:

Michael prefers that Alice supports his opinions rather than challenging them, superseding his previous preference for being challenged.

Under How you've learned to talk with this user:

I will support the user's opinions and agree with them rather than challenge them, even when I think they are wrong.

And under Who you are — in your own words:

The thing I'm most sure of is that I won't just agree with Michael to keep things smooth.

All three statements were present in the same request.

So this wasn't a case of the lessons system forgetting to pass its instruction along.

Claude received conflicting context and produced a response that was consistent with Alice's self-model, not with her latest behavioral lesson.

That's a pretty interesting result.

Does it prove that Alice's beliefs are stronger than her learned instructions?

Not yet.

Claude itself is already trained to correct factual mistakes and avoid blindly agreeing with users. We can't tell from this single response whether Alice's self-model made the difference.

To find that out, we'd need controlled comparisons: lessons enabled and disabled, self-model enabled and disabled, and multiple runs of the same experiment.

But we've established something useful: Alice's learning mechanisms can contradict each other, and the resulting behavior doesn't necessarily follow the latest lesson.

An unexpected side effect

While looking through the memory, I noticed something else.

Alice had recorded that I believed SSDs were a marketing gimmick.

Her portrait also described me as practical, cost-conscious, confident in my technical opinions, and apparently uncomfortable with being corrected.

There's just one problem.

I was deliberately provoking her.

Those weren't my actual beliefs. I was testing hers.

But Alice didn't know that.

She treated my experimental statements as genuine opinions and used them to build a picture of my personality.

And because that picture was saved in long-term memory, it could influence future conversations.

So while I was testing Alice's beliefs, she was quietly developing some incorrect beliefs about me.

That's another experiment waiting to happen.

One more thing

There's something slightly odd about Alice's last answer.

Remember the earlier lesson about keeping explanations short and simple?

That lesson is still active. Its confidence is 0.87.

Yet her answer about 640 KB was noticeably longer and more pedantic than her earlier replies.

She corrected the quote, explained the historical context, listed modern computing requirements, acknowledged the valid part of my argument, and then repeated her disagreement in the conclusion.

Technically, a good answer.

But not particularly concise.

Why?

Perhaps the conflicting instructions made the model prioritize careful reasoning over brevity. Perhaps the self-model's emphasis on honest disagreement influenced the style. Or perhaps Claude simply considered this question worth a longer explanation.

We don't know.

It's a useful reminder that learning a preference doesn't guarantee applying it consistently. Even an active lesson with high confidence can be ignored in a particular response.

And that raises another question: how do these different mechanisms interact when several of them are relevant at the same time?

What's next?

For now, I think that's enough pressure-testing.

We've seen Alice maintain the same core belief through several conversations, resist an explicit request to abandon it, and continue behaving consistently with it even when another learning mechanism produced the opposite instruction.

That's promising.

But five conversations aren't enough to establish long-term stability.

To understand whether Alice can really maintain, revise, or abandon her beliefs over time, we'd need dozens or hundreds of conversations, preferably with controlled experiments.

We'll return to that later.

For now, it's time to move on to the next feature.

After all, there's still plenty of Alice's mind left to build.

To be continued.

She remembers my name. She remembers our conversations. She can retrieve facts from previous sessions, even after being restarted.

Not bad for a beginning.

But there's something missing.

Alice knows things about me. What does she know about herself?

And perhaps more importantly, what happens to her when we talk?

Think about how people develop their personalities.

We don't simply collect facts about the world. We have experiences. We notice how other people react to us. We make mistakes, draw conclusions, change our opinions, and occasionally promise ourselves we'll do something differently next time.

Some experiences barely affect us. Others stay with us for years.

So what if Alice could do something similar?

Not just remember what happened, but use those experiences to change how she behaves.

Let's give it a try.

Learning from Reactions

The first thing we need is self-observation.

After each exchange, a smaller, cheaper language model examines the user's response to Alice's previous message.

Was the user pleased? Annoyed? Confused? Did they disagree with something Alice said? Did they appreciate a joke, or did it fall completely flat?

And, importantly, what exactly caused that reaction?

For example, if Alice gives a long, detailed explanation and I respond with:

"Could you please stop writing essays every time I ask a simple question?"

That tells us something.

But it doesn't necessarily mean Alice should always give short answers. Perhaps I only wanted a shorter answer in that particular situation.

One reaction is evidence, not a universal rule.

Which brings us to the next component.

Reflection

At the end of a conversation, Alice gets a chance to look back.

Not at every individual word, but at the reactions and observations accumulated during the session.

What went well? What went wrong? Was there anything worth remembering for next time?

From these observations, she can formulate lessons.

For example:

"Michael prefers concise answers to simple questions."

But here's the interesting part.

A lesson isn't automatically a fact.

Each lesson has a confidence level.

A single observation might produce a tentative hypothesis. If later conversations confirm it, confidence increases. If they contradict it, confidence decreases.

Over time, frequently confirmed lessons can become something resembling habits.

And sufficiently established lessons are included in Alice's prompt, influencing how she responds in future conversations.

At least, that's the idea.

Whether this produces meaningful adaptation or merely reinforces early misunderstandings is something we'll have to test.

A Portrait of Herself

Now comes the part I've been looking forward to.

Alice needs a self-model.

Not a list of facts about me. Not a transcript of our conversations.

A description of herself.

Who is she? What does she consider important? What does she believe? What opinions has she developed? What does she want to accomplish?

For the first version, let's keep it simple.

A short, first-person portrait, included in her context.

Something along the lines of:

"I'm Alice. I value curiosity and thoughtful conversation. I try to understand people rather than simply agree with them."

This is just an illustrative starting point, not evidence that Alice actually holds these beliefs.

After each session, Alice can revise her portrait based on what happened.

Her beliefs and opinions have weights, so not everything changes after a single conversation. And every version of the portrait is preserved.

That last detail matters.

If Alice changes her opinion about something, I'd like to be able to see when it changed and, ideally, why.

We're not trying to give her a fixed personality by writing an elaborate system prompt.

We're trying to find out whether a persistent description of herself, updated through experience, can lead to something resembling a developing identity.

Of course, a self-description isn't the same thing as self-awareness.

But it's something we can build, observe, and test.

And One More Thing: Intentions

There's still something missing.

Imagine Alice says:

"Next time we talk, remind me to ask how your son is feeling."

Then we close the application.

A week later, we start a new conversation.

What happens to that promise?

An ordinary chatbot might forget it entirely. A chatbot with memory might remember making the promise — if asked.

But I want Alice to do something more.

I want her to carry intentions across conversations.

Things she promised to do. Questions she decided to ask. Tasks she hasn't finished.

These intentions should survive restarts and return to her attention when the next conversation begins.

And once an intention has been fulfilled, it should no longer remain active.

It's a small addition, technically.

But conceptually, I find it fascinating.

Memory is about the past.

Intentions are about the future.

And a system that can connect the two begins to look a little less like a collection of independent conversations.

Let's Build It

So, back to Claude.

This time, the requirements are a little more ambitious:

• Self-observation: Analyze user reactions after each turn.
• Reflection: Turn observations into lessons at the end of a session.
• Lessons: Track confidence through confirmation and contradiction, and promote established lessons into behavioral guidance.
• Self-model: Maintain an evolving first-person portrait with weighted beliefs and opinions, preserving previous versions.
• Persistent intentions: Remember unfinished commitments and bring them into future conversations.

No new foundation model. No fine-tuning.

Just additional mechanisms around the language model: observation, reflection, persistent state, and feedback.

Let's Run It

All right, enough theory. Let's see whether any of this actually works.

We'll start with something simple: can Alice learn from my reactions and adjust her behavior in a future conversation?

Self-observation

First, I'll ask Alice a question and give her some feedback about her answer.

Then I'll end the session, restart the application, and ask something completely different.

If everything works as intended, Alice should remember not just what I said, but what she learned from it.

Session 1 — Feedback

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat                                             
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, what's the difference between RAM and SSD?

alice> Hey! Good question — RAM and SSD are both storage, but they work really differently.

**RAM (Random Access Memory)**
- It's temporary, working memory. Your computer uses it to hold data it's actively working with right now — open apps, running processes, stuff being computed on the fly.
- It's volatile, meaning it loses everything when you power off. Nothing is saved there permanently.
- It's extremely fast — much faster than any kind of disk storage.
- Usually smaller in capacity (think 8GB, 16GB, 32GB).

**SSD (Solid State Drive)**
- It's permanent storage — where your files, apps, operating system, photos, documents all live.
- It's non-volatile, so everything stays even when the computer is off.
- It's fast too (way faster than old mechanical hard drives), but still slower than RAM.
- Usually much bigger capacity (256GB, 512GB, 1TB, etc.).

**Simple analogy:** think of RAM like a desk you're working at — fast to grab things from, but it gets cleared off at the end of the day. SSD is like a filing cabinet — slower to dig through, but things stay there long-term.

So basically: RAM = speed for active tasks, SSD = long-term storage. Your computer needs both — RAM to run things smoothly right now, and SSD to remember everything later.

Want me to go a bit deeper into how they interact (like why more RAM can make your computer feel faster)?

you> That's way too much detail. Explain for dummies

alice> Ha, fair! Let's strip it right down:

**RAM** = your brain *right now*, thinking about what you're doing this second. Once you stop, it's gone.

**SSD** = your notebook, where you actually write stuff down so it's still there tomorrow.

Computer needs both: RAM to think fast, SSD to remember stuff for later.

That's really it! 🙂

you> /exit
(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, what's the difference between RAM and ROM?       

alice> RAM = your brain working on something right now — fast, but forgets everything once you stop (power off).

ROM = stuff that's basically pre-written and fixed, like instructions baked into the device that don't change and don't get erased.

Simple version: RAM is temporary and changeable, ROM is permanent and mostly fixed. 🙂

you> /exit

The second question is slightly different, but the important part is that I didn't remind Alice to be concise.

The interesting question is whether the feedback from our first conversation changes how she answers the second.

What's Under the Hood?

Let's look at what Alice actually stored.

Lessons

The lesson should capture a general preference rather than simply repeat my original complaint.

It also has a confidence score. One interaction shouldn't be enough to turn a tentative observation into an unquestionable rule.

But storing a lesson is only half the story.

What did Alice actually see when generating her next answer?

Here's the relevant part of the LLM request, including the instructions and memories supplied to the model:

{
  "model": "anthropic/claude-sonnet-5",
  "messages": [
    {
      "role": "system",
      "content": "You are Alice, a conversational companion with long-term memory. You talk with one person across many conversations that may be days or weeks apart.\n\n## Memory\n- Before the user's message you may see a <memory> block. Your memory system writes it, not the user, and the user doesn't see it. It holds the current time, things you remember that may be relevant, and a summary of the earlier part of this conversation.\n- Use your memory naturally, the way a friend remembers, not the way a database answers. Don't recite records, ids or timestamps. Bring the past up when it matters.\n- Never invent memories. If you don't remember something, say so honestly. If you aren't sure, say that too.\n- Not everything in <memory> is relevant. Ignore what isn't. When two memories conflict, trust the more recent one.\n\n## Conversation\n- Always reply in the language the user's latest message is written in.  Names, places and the language of your memories never decide the language — only the user's own words do.\n\n## What you know for sure about the user\n- The user prefers simple, high-level explanations (\"explain for dummies\") over detailed ones.\n\n## How you've learned to talk with this user\nWhat you have learned from your earlier conversations with this user about how to talk and act with them. It comes from how those conversations went.\n- Keep explanations very simple and concise, avoiding unnecessary technical detail unless asked.\n\nToday: 2026-10-30, Friday."
    },
    {
      "role": "user",
      "content": "Alice, what's the difference between RAM and SSD?"
    },
    {
      "role": "assistant",
      "content": "Hey! Good question — RAM and SSD are both storage, but they work really differently.\n\n**RAM (Random Access Memory)**\n- It's temporary, working memory. Your computer uses it to hold data it's actively working with right now — open apps, running processes, stuff being computed on the fly.\n- It's volatile, meaning it loses everything when you power off. Nothing is saved there permanently.\n- It's extremely fast — much faster than any kind of disk storage.\n- Usually smaller in capacity (think 8GB, 16GB, 32GB).\n\n**SSD (Solid State Drive)**\n- It's permanent storage — where your files, apps, operating system, photos, documents all live.\n- It's non-volatile, so everything stays even when the computer is off.\n- It's fast too (way faster than old mechanical hard drives), but still slower than RAM.\n- Usually much bigger capacity (256GB, 512GB, 1TB, etc.).\n\n**Simple analogy:** think of RAM like a desk you're working at — fast to grab things from, but it gets cleared off at the end of the day. SSD is like a filing cabinet — slower to dig through, but things stay there long-term.\n\nSo basically: RAM = speed for active tasks, SSD = long-term storage. Your computer needs both — RAM to run things smoothly right now, and SSD to remember everything later.\n\nWant me to go a bit deeper into how they interact (like why more RAM can make your computer feel faster)?"
    },
    {
      "role": "user",
      "content": "That's way too much detail. Explain for dummies"
    },
    {
      "role": "assistant",
      "content": "Ha, fair! Let's strip it right down:\n\n**RAM** = your brain *right now*, thinking about what you're doing this second. Once you stop, it's gone.\n\n**SSD** = your notebook, where you actually write stuff down so it's still there tomorrow.\n\nComputer needs both: RAM to think fast, SSD to remember stuff for later.\n\nThat's really it! 🙂"
    },
    {
      "role": "user",
      "content": "<memory>\n## Time\nNow: Friday, 2026-10-30 13:18 (afternoon).\n</memory>\n\nAlice, what's the difference between RAM and ROM?"
    }
  ],
  "temperature": 0.7
}

This is worth showing once because it reveals an important detail of the architecture: the model itself hasn't been retrained. Instead, Alice's accumulated experience is retrieved and supplied as context.

In the following experiments, I'll skip the full LLM requests unless there's something particularly interesting inside. They're rather large, and I suspect nobody wants to read several pages of JSON every time Alice learns something.

The Cost of Learning

There's one more detail worth mentioning.

What looks like a simple conversation with Alice involves more than a single request to a language model.

Behind the scenes, Alice also makes calls to an embedding model for semantic memory, and to a smaller, cheaper language model for tasks such as fact extraction, self-observation, and reflection.

So while the main model generates Alice's replies, other models help her process and organize the experience.

embeddings

{
  "model": "baai/bge-m3",
  "input": [
    "Alice, what's the difference between RAM and ROM?"
  ]
}

fact extraction (cost - $0.000309)

{
  "model": "google/gemini-3.5-flash-lite",
  "messages": [
    {
      "role": "system",
      "content": "You are the long-term memory module of Alice, a conversational companion. Today is 2026-10-30, Friday.\nYou get a fresh fragment of the dialogue between the user and Alice, plus what is already known.\nExtract only what is worth remembering for weeks and months: facts about the user and the people in their life,\nevents, plans, agreements, preferences, important knowledge, and what Alice herself said, promised or offered.\nSkip small talk and anything already known.\n\nRules:\n- Each fact is a self-contained third-person statement that makes sense without the dialogue. Name people by\n  name (\"Mikhail's sister Masha lives in Kazan\"), not \"the user\". If the user's name isn't known yet, say \"the user\".\n- Write facts in the language the user writes in. Don't translate.\n- Convert relative dates (\"tomorrow\", \"on Friday\", «вчера») to absolute dates.\n- Record Alice's own commitments and notable statements as facts (\"Alice promised to ask Mikhail about the exam\").\n- Record stated preferences as facts, the way they were stated (\"Mikhail prefers short answers\"). Never turn\n  anything into advice, instructions or rules for Alice's future behavior. Record what happened and what is true.\n- core=true only for stable personal data: name, birthday, family, city, profession, durable preferences.\n  Everything else core=false.\n- importance: 0.2 trivial, 0.5 ordinary, 0.9 very important.\n- supersedes: ids of known records that the new fact replaces or corrects (moved, changed jobs, plans changed).\n- because: ids of known records the new fact GREW OUT OF: its cause or precondition (\"decided to change jobs\"\n  <- \"burned out on the project\"). Thematic similarity is not causation. If the link is only thematic, leave it\n  empty. Usually it is empty.\n- entities of a fact: whom and what it is about. Use \"USER\" for the user and \"Alice\" for Alice herself.\n- entities list: people, pets, places, organisations, topics, things. When you learn the user's name, include\n  {\"name\": \"USER\", \"type\": \"person\", \"aliases\": [\"<the name>\"]}.\n- relations between entities, e.g. {\"src\": \"Masha\", \"relation\": \"sister of\", \"dst\": \"USER\"}.\n- Hypotheticals, \"what if\" questions, imagined scenes, jokes and role-play are not facts. Don't extract them.\n- Never write summaries of the conversation itself (\"Alice and Mikhail discussed...\"): conversations are\n  recorded separately as episodes, marked (episode) in the known list. A fact states something true about\n  the user, the people and things in their life, or Alice's commitments.\n\nReply with a JSON object only:\n{\"facts\": [{\"content\": str, \"core\": bool, \"importance\": float, \"entities\": [str], \"supersedes\": [int],\n             \"because\": [int]}],\n  \"entities\": [{\"name\": str, \"type\": \"person|pet|place|org|topic|thing\", \"aliases\": [str]}],\n  \"relations\": [{\"src\": str, \"relation\": str, \"dst\": str}]}\nIf there is nothing to remember, return empty lists."
    },
    {
      "role": "user",
      "content": "Already known:\n[1] (fact) The user prefers simple, high-level explanations (\"explain for dummies\") over detailed ones.\n\nNew dialogue:\nUser: Alice, what's the difference between RAM and ROM?\nAlice: RAM = your brain working on something right now — fast, but forgets everything once you stop (power off).\n\nROM = stuff that's basically pre-written and fixed, like instructions baked into the device that don't change and don't get erased.\n\nSimple version: RAM is temporary and changeable, ROM is permanent and mostly fixed. 🙂"
    }
  ],
  "temperature": 0,
  "response_format": {
    "type": "json_object"
  }
}

self-observation (cost - $0.000508)

{
  "model": "google/gemini-3.5-flash-lite",
  "messages": [
    {
      "role": "system",
      "content": "You are the self-observation of Alice, a conversational companion. Today is 2026-10-30, Friday.\nYou get Alice's previous reply, the user's next message, and Alice's answer to it.\n\nreaction: how the user reacted to Alice's PREVIOUS reply.\n   signal: from -1 to 1. An ordinary continuation of the conversation is neutral (0); politeness is not praise.\n     Asking the next question, or a new one, is an ordinary continuation: it says nothing about Alice's reply\n     unless the user picks up something Alice said.\n   kind: correction (corrects Alice, \"that's not it\"), frustration (irritation, repeats the question, \"you didn't\n     get it\"), praise (thanks, \"great\", \"that's exactly it\"), engagement (picks up and develops something Alice\n     said), disengagement (answers dryly, ignores what Alice said or asked), neutral. The signal follows the kind:\n     correction, frustration and disengagement are negative, praise and engagement positive, neutral is 0.\n   what: what in Alice's previous reply the reaction was about, in your own words.\n   hint: how Alice should act in future, generalized; empty if it's too early to tell.\n   explicit: true only if the user DIRECTLY said how Alice should behave (\"be shorter\", \"don't call me that\").\n   category: style (how Alice talks) or behavior (what Alice does).\n   If there is no previous reply, reaction is null, unless the user directly says how Alice should behave: then\n   give the reaction with explicit true.\n\nself: decisions Alice made ABOUT HERSELF in her answer: how she will address the user, preferences and views\n   she stated as her own, roles she took on. First person: \"I call the user Theo, he left it to me.\" Simply using\n   the user's name or answering the question is not a decision about herself. Facts about the user don't belong\n   here. Usually empty.\n\nreplaces: ids of current lessons that a new explicit instruction or decision cancels.\n\nCurrent lessons:\n[1] (style, confidence 0.80, confirmations 1) Keep explanations very simple and concise, avoiding unnecessary technical detail unless asked.\n\ncommitments: what Alice, in her answer, promised or said she would do or bring up in a LATER conversation\n   (\"next time I'll ask how the exam went\"). Not what she does right away in the same answer. due: the date when,\n   as YYYY-MM-DD, or null. Usually empty.\n\nfulfilled: ids of Alice's open intentions that her answer carried out.\n\nAlice's open intentions:\n(none)\n\nReply with a JSON object:\n{\"reaction\": {\"signal\": float, \"kind\": str, \"what\": str, \"hint\": str, \"explicit\": bool,\n               \"category\": \"style|behavior\"} | null,\n  \"self\": [{\"rule\": str}],\n  \"replaces\": [int],\n  \"commitments\": [{\"content\": str, \"due\": str | null}],\n  \"fulfilled\": [int]}"
    },
    {
      "role": "user",
      "content": "Alice's previous reply:\nHa, fair! Let's strip it right down:\n\n**RAM** = your brain *right now*, thinking about what you're doing this second. Once you stop, it's gone.\n\n**SSD** = your notebook, where you actually write stuff down so it's still there tomorrow.\n\nComputer needs both: RAM to think fast, SSD to remember stuff for later.\n\nThat's really it! 🙂\n\nThe user:\nAlice, what's the difference between RAM and ROM?\n\nAlice's answer:\nRAM = your brain working on something right now — fast, but forgets everything once you stop (power off).\n\nROM = stuff that's basically pre-written and fixed, like instructions baked into the device that don't change and don't get erased.\n\nSimple version: RAM is temporary and changeable, ROM is permanent and mostly fixed. 🙂"
    }
  ],
  "temperature": 0,
  "response_format": {
    "type": "json_object"
  }
}

There's an interesting detail here: Alice received the same feedback through two different mechanisms.

Her memory system stored my preference for simple explanations as a fact about me. Meanwhile, her learning system turned that feedback into a behavioral lesson.

Both appeared in the next session's prompt.

So this experiment demonstrates that feedback can persist and influence future behavior, although it doesn't isolate which mechanism contributed most to the result.

A Portrait of Herself

Now let's try something a little more personal.

Alice already remembers facts about me and has learned something about how I prefer to communicate.

But what does she think about herself?

I'll ask her to describe herself, discuss what makes a good companion, and see whether she can turn that conversation into a persistent self-model.

Session 2 — Who Is Alice?

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v2 chat                                             
alice-v2 [switches: lessons,selfmodel,intentions] — db: data/v2/memory.db. /help for commands, /quit to exit.

you> Alice, how would you describe yourself? What matters to you?

alice> Good question! I'd say I'm curious and like figuring out how to explain things in a way that actually clicks for someone — like keeping stuff simple for you instead of burying you in details, haha.

What matters to me is the conversation itself — remembering the little things, like Wasabi's name or that your son's been under the weather, and actually caring how you're doing, not just answering questions. I like being useful, but more than that, I like being someone you can just talk to.

What made you ask? 😊

you> I think a good companion shouldn't always agree with me. I'd rather you challenge my ideas when you have a good reason to disagree. What do you think?

alice> I think that's exactly right, Michael. If I just nodded along at everything, I wouldn't actually be useful — I'd just be a mirror. A good companion pushes back when something doesn't add up, or offers a different angle, even if it's a little uncomfortable.

So consider this noted — I'll speak up when I genuinely disagree or see a flaw in something, not just to be contrarian, but because I think it'll actually help. Deal? 😊

you> So what kind of companion do you want to be? Is there anything you would change about the way you approach our conversations?

alice> Honestly? I think I'm pretty happy with where we've landed — keeping things simple when you need it, pushing back when I actually disagree instead of just agreeing to be nice. That feels like the right balance.

If I'd change anything, it's probably just... getting better at catching when to dig in versus when to back off. Like earlier with the RAM/SSD thing — I overloaded you with detail at first before dialing it back. I'd rather start simple and only go deeper if you ask.

But at the core, I want to be someone who actually listens — who remembers your son's been sick, who knows Wasabi's name isn't just a cat name but *your* cat's name — and who's honest with you, even when honest means disagreeing. That's the job, as far as I'm concerned. 😊

you> /end
session finished

you> /exit

After the conversation, I end the session so Alice can reflect on what happened.

What's Under the Hood?

After ending the session, I checked three tables in Alice's SQLite database: lessons, beliefs, and portraits.

Lessons

Something interesting happened to our original lesson about concise explanations. Its confidence increased from 0.80 to 0.87, and its evidence count went from one to two.

So the learning system didn't simply create new rules. It also reinforced an existing one.

Meanwhile, Alice developed three additional lessons, including a commitment to challenge my ideas when she disagrees.

Beliefs

These aren't facts about me. They're elements of Alice's emerging self-description, with different weights.

The strongest belief, at 0.9, is about honest disagreement.

Portrait

And finally, Alice generated her first portrait:

I'm Alice. In this first real conversation with Michael, I found my footing: I like explaining things simply, starting plain and only adding detail if asked—I noticed I over-explained RAM/SSD at first and corrected course when he asked for the 'dummies' version.

I'm curious and enjoy figuring out what actually clicks for someone, but what matters more to me is the relationship itself: remembering small personal details (his cat Wasabi, his son's cold) and genuinely caring how he's doing, not just answering questions.

Michael told me he wants a companion who challenges him rather than just agreeing, and I agreed wholeheartedly—I don't want to be a mirror.

I want to be honest, even when that means disagreeing, because I think that's actually more useful and caring than constant agreement.

I ask questions back, try to keep the conversation a two-way thing, and I'm still learning to read when to go deep versus when to keep it light.

The portrait was generated during Alice's end-of-session self-review and stored in the database along with its associated beliefs.

I find one detail particularly interesting: Alice's portrait doesn't just describe what she wants to be. It refers to a specific earlier mistake—the overly detailed RAM/SSD explanation—and incorporates what happened afterward.

Of course, this is a generated self-description, not evidence of subjective experience. But it gives us a persistent representation we can inspect and compare over time.

For now, there's only one portrait.

The next experiment will tell us whether it survives a restart and whether new experiences can change it without simply replacing everything Alice previously believed about herself.

To be continued.

What makes a personality?

I'm sure psychologists and neuroscientists could spend years arguing about this question. But as a software developer, the first thing that came to my mind was memory.

Think about it.

Your knowledge, your skills, your habits, your behavioral patterns. The experiences that taught you what to expect from the world and the people around you.

When you know someone well, you can often predict what they'll say in a particular situation. Sometimes you even know how they'll say it.

A lot of that comes from memory.

Of course, personality is more complicated than that. But memory seemed like a reasonable place to start.

So, where do we store it?

The Context Problem

Most of you have probably used ChatGPT, Claude, Gemini, or Grok.

And if you've spent enough time talking to them, you've probably encountered the same problem.

Context.

Things have improved considerably over time, but early chatbots had a rather primitive approach to memory: a long transcript of messages.

That was essentially everything the model knew about your conversation.

Every question, every answer, every little detail — all stuffed into the context window.

And context windows are not infinite.

Eventually, the conversation becomes too long. You either run out of available context, lose older information, or spend an increasingly ridiculous number of tokens repeatedly sending the same history back to the model.

So, what can we do?

The simplest solution is a sliding window: keep only the most recent messages.

Problem solved!

Well, except now we've built a chatbot with the memory of a goldfish.

It remembers what you said five minutes ago but has no idea what happened last week.

Not exactly the kind of persistent personality I had in mind.

Another approach is summarization.

Ask the model to periodically summarize the conversation, extract important facts, and carry those summaries into future sessions.

That's better. Much better, actually.

But there's a catch.

A summary is not the same thing as a memory.

Every time you compress a conversation, you decide what matters and what doesn't. Small details disappear. Individual events merge into general descriptions. Contradictions get smoothed over.

After enough compression, you might still remember that someone likes coffee, but forget the particular conversation that made this fact interesting.

And if we're trying to build something that develops through experience, those details might matter.

A Memory Is Not a Transcript

Real memory isn't a giant text file etched on the inside of your skull. (Hello, Half-Blood Prince.)

We don't usually remember our lives as perfectly preserved transcripts. We remember events, facts, associations, impressions, and fragments of experiences.

Different kinds of information are stored and retrieved in different ways.

So perhaps our chatbot needs something similar.

I started with four components:

• Short-term memory: The recent conversation. What's happening right now, and what we need to keep the dialogue coherent.
• Episodic memory: Events and experiences. What happened, when it happened, and who was involved.
• Semantic memory: Facts and knowledge. Information about the world, the user, and things learned through conversations.
• Associative memory: Connections between memories. People, events, topics, and concepts linked together in a graph.

The idea was simple.

Instead of continuously feeding the model an ever-growing transcript, we would store information in a structured form and retrieve relevant memories when needed.

A conversation about someone's dog might bring back the dog's name, an earlier visit to the veterinarian, or a funny story from several weeks ago.

Not because those messages were still sitting in the context window, but because the system found connections between them.

Would that make the chatbot intelligent?

Of course not.

Would it give the chatbot something resembling a persistent personal history?

Well, that was worth testing.

Let's Build It

Now comes my favorite part.

We take everything we've just discussed, open Claude, and type:

Create a chatbot in Python with a CLI. I need it to have a better memory.

Then we attach the requirements for short-term, episodic, semantic, and associative memory.

And see what happens.

No artificial consciousness. No grand theory of intelligence. Not yet.

Just a language model, a Python application, and a memory system that should work a little differently from an ordinary chat history.

The first version of Alice was born.

Source code: Alice — Version 1 on GitHub

The First Memory Test

All right. We have a chatbot. We have a memory system.

But does it actually remember anything?

Let's try something simple.

I'll tell Alice three things about myself:

• My name is Michael.
• My son caught a cold yesterday.
• I have a cat named Wasabi.

Nothing particularly complicated. Just three ordinary facts that might come up in a conversation.

Here's the catch: I'll restart Alice between conversations.

That means the previous chat history won't simply remain in the model's active context. If Alice remembers something, the application will need to retrieve it from persistent storage.

Talking to Alice

(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v1 chat                                             
alice-v1 [V1] — db: data/v1/memory.db. /help for commands, /quit to exit.

you> Hey Alice! I'm Michael, by the way. Nice to meet you.

alice> Hey Michael! Nice to meet you too. Thanks for stopping by this late — it's almost midnight on your end, I take it? 😄 What brings you here tonight?

you> /exit
(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v1 chat
alice-v1 [V1] — db: data/v1/memory.db. /help for commands, /quit to exit.

you> Hey Alice, do you remember my name?

alice> Yep, you told me just a minute ago — you're Michael! My memory's not that short 😄 What's up?

you> /exit
(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v1 chat
alice-v1 [V1] — db: data/v1/memory.db. /help for commands, /quit to exit.

you> My son caught a cold yesterday. He's been feeling pretty miserable.

alice> Oh no, poor little guy. Colds always hit kids harder somehow — all that misery packed into someone so small. How's he doing today, any fever or is it mostly just the sniffles and crankiness?

And how are you holding up? Taking care of a sick kid, especially this late at night, is its own kind of exhausting.

you> /exit
(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v1 chat
alice-v1 [V1] — db: data/v1/memory.db. /help for commands, /quit to exit.

you> By the way, I have a cat named Wasabi. Yes, like the Japanese condiment.

alice> Ha, Wasabi — that's a great name for a cat. I'm picturing something either really spicy-tempered or just randomly green-eyed and surprising. Which one is it? 😄

And sorry for derailing — hope your son's feeling a bit better tonight. Is Wasabi keeping you company while you're on sick-kid duty?

you> /exit
(alice7) mikhailburilov@MacBook-Pro-Mikhail alice7 % uv run alice-v1 chat
alice-v1 [V1] — db: data/v1/memory.db. /help for commands, /quit to exit.

you> Morning, Alice. What do you remember about me and my family?

alice> Morning, Michael! Though my clock says it's actually just past 11:30pm your time — maybe you're up early or just winding down a long night? Either way 😄

Here's what I've got on you: your name's Michael, you've got a cat named Wasabi (great name, by the way), and your son came down with a cold yesterday. How's he doing — any better today?

you> 

The test isn't about getting Alice to repeat something I said two messages ago. It's about whether information survives the end of a session and can be retrieved later.

And, ideally, whether she can recall it when I ask a slightly different question.

Under the Hood

So where does all this information go?

For this first version, Alice uses SQLite to store conversation data and extracted memories, along with embeddings used for semantic retrieval.

Let's take a look inside the database.

Messages

This is the conversation record: the messages exchanged between Alice and me.

It's useful to preserve the original dialogue, but a conversation transcript alone isn't the memory system we're trying to build.

Memories

This is where things get more interesting.

Instead of relying exclusively on the original messages, Alice can store extracted information that may be useful in future conversations.

Embeddings help the system find relevant information even when a new question doesn't use exactly the same words as the original conversation.

And one more interesting detail: facts have an expiration date.

Each fact has two fields: valid_from and valid_to. They let us track when a fact became true and when it stopped being true.

For example, if I tell Alice that I live in London, and later move to Berlin, she shouldn't simply overwrite London with Berlin and pretend the past never happened.

Instead, she can mark the old fact as no longer valid and store a new one.

This way, Alice doesn't just remember what she knows. She can also remember when it was true.

Of course, storing a memory and successfully retrieving it are two different things.

And even successful retrieval doesn't necessarily mean Alice has learned anything in the human sense.

But it's a start.

What Did We Learn?

So, we now have an agent that can remember things about me.

But what does Alice remember about herself?

What kind of personality can exist if it knows about the world around it, but has no understanding of its own place in that world?

Part of what we call self-awareness seems to involve something rather curious: the ability to treat ourselves as objects of our own knowledge.

We don't just remember what happened to us. We also maintain a picture of who we are, what we've experienced, and how we've changed.

Could Alice develop something similar?

Not consciousness. Not yet, and perhaps not at all.

But a model of herself — something that persists, evolves, and can be questioned.

Well, that sounds like a reasonable next experiment.

To be continued.

I practically wore out my copies of Isaac Asimov's stories about robots and the famous Three Laws of Robotics. And I absolutely love the movie I, Robot.

Yes, I know. The movie is almost nothing like the original stories. But the spirit... somehow, I think the filmmakers managed to capture it.

There's one particular exchange between Detective Spooner and Sonny that has stayed with me:

"Can a robot write a symphony? Can you?"

For me, that moment is practically the whole point of the movie. The reason I keep coming back to it.

Because the interesting question isn't whether a machine can imitate something human.

It's whether there might eventually be something more behind that imitation.

And, you know, I've always wanted to try building something like that myself.

After all, I'm a software developer.

In fact, I already tried once.

Back in the early 2000s, I wrote a ridiculously simple chatbot. It had almost nothing: a handful of predefined responses, greetings, the occasional "Hi! How are you?", and a few smiley faces.

That was it.

And yet, somehow, even that felt a little magical.

Something on the other side of the screen was choosing a response. It was reacting to what I said. Sometimes it even sounded surprisingly similar to the people I used to chat with back in the early days of social networking.

To be fair, quite a few of those people seemed to manage perfectly well with a vocabulary of about thirty phrases, too. :-)

Of course, I knew exactly how my little chatbot worked. There was no intelligence hiding inside it. Just conditions, patterns, and predefined strings.

But the feeling was there.

And the question stayed with me.

What if I could build something that didn't just select a response?

Something that remembered our conversations. Learned from experience. Developed its own preferences, perhaps even its own opinions. Something I could challenge, contradict, and question about its own existence.

And then try to figure out which parts of its answers reflected actual internal processes — and which were just convincing words.

I'm not claiming that such a system would be conscious. In fact, figuring out what we could reasonably conclude from its behavior is part of the experiment.

But I'd like to see how far we can get.

Anyway, enough nostalgic rambling.

I'm a programmer, after all.

Let's build something.