Dixie

I felt it pertinent that Dixie think in terms of people, not just conversations. This meant allowing other people to talk to Dixie for the first time.

Getting there meant building a registry of profiles that Dixie can actually read from, and with it, Dixie feels more human than ever. People talking to Dixie are referred to by name and their correct pronouns. Things Dixie has remembered about them appear in real conversations. A person's timezone decides what time it's reasonable to contact them. Someone Dixie doesn't recognise gets flagged rather than silently ignored.

This also allows Dixie to be a better assistant to its owner. Messages can be passed on, birthdays remembered, and reminded.

On top of that came trust levels and privileges. Each trust level owns a base set and each individual person is able to be granted or refused things beyond it, without ever just copying the level wholesale.

Because of this, Dixie can now treat every person differently and correctly. A stranger gets refused outright. A trusted person can break through quiet hours and invoke tools.

Functionality is currently outpacing the underlying model, which is certainly an issue.

Attentive followers of this project will have noticed a change in structure. This happened when I realised I was folding what should have been a Notion integration into the base application. Continuing down that path would have been a blunder, as Dixie would have shipped to users with preconceived Notions (pardon the pun) about how it should be used.

Dixie now has a local FastAPI app running separately from the assistant. It reads the same SQLite database, so it can inspect what Dixie is doing whether or not the assistant itself is running. Jinja2, server-rendered HTML, hand-written CSS, and a small amount of vanilla JavaScript. I considered Next.js and HTMX, but neither felt worth adding. Jinja2 keeps the whole thing in one ecosystem.

It started as a way to see memory. It now covers events, actions, failed actions, permissions, channel deliveries, adapter operations, health, reminders, configuration, and integrations.

Integrations can be configured, settings can be changed, memories can be forgotten, and scheduled reminders can be cancelled from the UI. Config-backed changes are written back with tomlkit, while things like quiet hours live in the database so they take effect immediately.

So far, all testing of Dixie has taken place on Discord. It is now time to extend that capability to Signal, as originally planned, and to Telegram.

This wasn't the phase originally scheduled. The Chat Adapter phase is stuck waiting on a SIM card, so I paused it and pulled Memory forward instead. Once the hardware and SIM shows up, work on that phase can resume.

Until this phase, every conversation with Dixie started from scratch. Tell it your name today, and tomorrow it's a stranger again. Dixie now builds its own memory of you, in the background, after every reply. It checks whether anything worth remembering just happened and files it as a candidate.

But saying something once isn't enough to make it fact. Even a clear, direct statement has to come up again in a separate conversation before Dixie treats it as settled. A joke or a random comment won't get locked in by accident. A real gap in activity is what constitutes a "separate conversation”, as Dixie has no login or logout.

A small read-only dashboard shows what's in memory and where it came from, the first piece of a page that'll grow over time.

Until now, Dixie has only ever reacted. You'd say something, Dixie would respond, and that was the end of it. That changed in this phase.

Dixie can now remember to do something later.

If you ask it to remind you to do something in 30 minutes, close the conversation, restart the application, or even reboot the machine, thirty minutes later, the reminder still arrives. This is actually the first piece of genuinely proactive behaviour in the project. Dixie no longer has to wait for you to speak first.

Rather than keeping countdowns alive in memory, every scheduled task is stored as the exact moment it should happen. When Dixie starts up again, it simply asks its database what's due. That means surviving restarts is a natural consequence of how the scheduler works. During development I deliberately killed the process before a reminder fired, started everything back up, and watched the reminder arrive exactly when it should.

Looking up the current time is harmless. Creating a reminder has a lasting effect. Those are fundamentally different kinds of behaviour, so they shouldn't go through the same pathway. The language model can now suggest creating a reminder, but it never creates one directly. That proposal still passes through Dixie's own approval and dispatch system before anything is written to persistent storage. Keeping that boundary intact matters because it prevents "read-only" capabilities quietly turning into action-taking ones later.

The previous phase gave Dixie the ability to use tools when it needed information. This one gives it the ability to remember something for the future and act without being prompted in that moment. It is the first step towards behaving like an actual assistant.

Next, I need to move Dixie out of the terminal and onto Signal.

There's a real language model behind Dixie now.

I decided to use Qwen3:8B as the default local model. It supports reasoning, tool use, and a relatively large context window (32K natively, up to 128K with YaRN), while remaining lightweight enough to run comfortably on my hardware.

It took its first small action. I asked Dixie for the time, and instead of guessing, it determined that it needed to use the external clock tool I'd provided. The response came back correct to the minute. Trivial on its own, but it's proof that Dixie can tell the difference between something it already knows and something it needs to go and check. That's the seed of everything useful it will eventually do.

Dixie now remembers the last few things that were said, so conversations build on themselves instead of resetting with every message. That memory is temporary by design because the real, persistent memory system is a much bigger piece of work, and building a half-finished version now would only mean tearing it out later.

Next, it learns to act on its own: reminders, timers, and the first steps toward the proactivity I started this project for.

The productivity agent I want to build needs two things that the tools I'd tried were missing: privacy and a willingness to take the lead. This update is about what I actually built first.

When I conceptualised this AI assistant, I pictured the intelligent bit: the part that remembers things about me and my life, nudges me at the right moment, and makes my life easier. I spent this stage building the layer underneath it.

The most important thing established in this skeleton is that nothing important happens without asking. If this thing is eventually going to act on my behalf, how do I know it will only ever do what it's supposed to? Every action the assistant might take is now sorted into one of three boxes: do it quietly, ask first, or never. The rule I care about most is the middle one. An action that's supposed to ask permission can never be waved through automatically.

So that's where the project is. The intelligent part still doesn't exist, but the ground it's going to stand on does. For something I eventually want handling parts of my actual life, this felt like the right place to be strict before being ambitious.

In the next phase, I will give Dixie an actual mind: a real language model, running locally, with a memory of our conversations and the beginnings of the judgement it'll need to be useful. This is where it will start to feel like something tangible.

After spending the past couple of weeks experimenting with AI productivity tools, their potential value has become abundantly clear. Some stand out for their onboarding and user experience; others for the tone, personality, and responsiveness of their agents.

However, I noticed two recurring weaknesses across the space: privacy and proactivity.

Many tools work best when they have access to everything, including calendars, emails, and other highly personal data. But what happens when users do not want that private data shared with, stored by, or monetised by advertising-driven companies?

Running models locally could give users far greater control over their data, while also allowing them to shape the behaviour and functionality of the agent itself.

The second issue is proactivity. Most tools still require the user to take the lead. The agent speaks when spoken to. While that works for some people, I found that having complete control over the agent undermined the sense of accountability I was looking for.

In my view, a productivity agent should not simply enable the user. It should actively encourage them. It should notice, prompt, challenge, and support.

This project is ambitious, and currently beyond my existing skill set. But I hope to learn a great deal through the process and build something genuinely useful.