Ari

Why a name mattered

A system with no identity is just a tool. You interact with a tool the same way every session: command in, output out.

A companion is different. It has a consistent tone. It responds the same way on a Wednesday at 3pm as it does on a Monday morning. You know what to expect from it.

The name is Ari. That is not branding. It is an anchor for how the system should behave. Every reply, every response style, every decision about whether to give a short answer or a longer one — all of that now has a reference point. Does this sound like Ari, or does it sound like a chatbot?

That question turned out to be more useful than any personality specification document.

The assistant profile

Ari has a defined personality: professional, helpful, direct, and calm. No filler. No fake enthusiasm. Short replies unless a longer one is genuinely needed.

The profile also includes response style rules. That part is easy to underestimate. Most AI systems sound inconsistent because the prompt describes a personality but gives no rules for how that personality expresses itself in practice. Does it use bullet points? How long is a normal reply? Does it ask follow-up questions or just answer and stop?

Ari answers and stops. It does not pad. If the question has a one-sentence answer, the reply is one sentence. That rule alone changed how the system felt to use.

The profile is also wired into both the voice loop and the browser panel. The same Ari in the terminal is the same Ari in the browser. That consistency was the main thing Week 4 was trying to achieve.

The cockpit UI

The browser panel from Week 3 was useful for testing, but it was still organised like a set of separate commands. Week 4 rebuilt it as a cockpit.

A cockpit shows you the current state of the system at a glance. Ari’s cockpit now shows:

• Live focus — what Ari thinks you should be working on right now
• Status — whether the local system is running correctly
• Tasks — the current scored task list
• Task capture — add a task without leaving the panel
• Command buttons — digest, focus, review, plan, status as single-click actions
• Microphone input — speak directly into the panel
• Speak and stop controls — manage audio output
• Clearer error messages — when Ollama is not loading, the panel now says why

The cockpit made testing faster. Memory, tasks, and focus visible in one place means you can verify that the system has the right state before asking it a question. That matters more than it sounds when the underlying model can be slow or unavailable.

What went well

The simple assistant profile worked better than a big character system would have. Ari does not need lore or backstory to feel consistent. It needs clear rules about how it responds and a name to organise those rules around.

The identity fallback was the most useful thing built this week. If Ollama is not running — which happens when the machine is low on memory or the GPU allocation fails — Ari can still answer questions about itself. Who are you? What do you do? How does this work? Those questions get answered locally, without the model. The system does not go silent when the model is unavailable. It just becomes more limited.

The cockpit improved testability significantly. Three weeks of CLI commands, one panel. That is a meaningful quality-of-life improvement for anyone actually running this system daily.

What did not go well

Free-form chat still has a hard dependency on Ollama loading the model correctly. When Ollama fails — which it does, because of memory pressure or GPU allocation problems on the machine — Ari can handle identity questions locally but cannot hold a real conversation.

That is not a small limitation. The most interesting use of a companion is the free-form interaction. Asking it something you did not plan to ask. Following a thread. That only works when the model is available and stable.

Browser voice input also exists in the cockpit, but it has not been properly tested under real conditions. Microphone reliability and transcription accuracy need more sessions with actual use before trusting them.

What the plan had to become

The original Week 4 scope was more ambitious. Animation. Voice cloning. Plugin support. A complex personality architecture.

None of that got built. The reason is the same one that has come up every week: the useful version is smaller than the planned version.

Animation on top of an unstable model connection is noise. Voice cloning before the basic voice loop is reliable is skipping steps. Plugins before the core identity is stable is scope creep.

What actually needed to happen in Week 4 was simpler: make Ari feel like a consistent presence, make the system easier to use daily, and make failures visible instead of silent. That is what got built. The other things will come when the foundation is solid enough to support them.

Visible local state turned out to be the most practical thing in the cockpit. You can see what Ari knows. You can see whether the model is available. You can see the task list before asking for a focus recommendation. Debugging a system you cannot see is slow. Debugging a system with a cockpit is fast.

Where DeskSpirit is now

Four weeks. Voice loop. Memory layer. Scoring engine. Named assistant. Cockpit UI.

The system runs locally on one machine, has no external services, requires no accounts, and does not send anything anywhere. Ari responds from local memory and a local model. When the model is unavailable, it fails gracefully and tells you why.

It is not finished. Free-form chat needs a more stable runtime. Voice input needs real-world testing. The scoring engine has edge cases that surface when the task list gets large.

But it is useful enough to run daily. That was the goal from the start.