Start of Fritzi blog post

_posts/2026-01-24-fritzi.md

@@ -0,0 +1,158 @@
+---
+title: "Fritzi and the Quiet Lessons of Social Voice in Care"
+excerpt: "What a conversational social voice assistant in a nursing home revealed about OpenVoiceOS, predictability, and building voice systems that survive the real world."
+coverImage: "/assets/blog/fritzi/cover.png"
+date: "2026-01-24"
+author:
+  name: "Peter Steenbergen"
+  picture: "https://www.openvoiceos.org/_next/static/media/core3.a9ea7286.jpeg"
+ogImage:
+  url: "/assets/blog/fritzi/cover.png"
+---
+
+## Fritzi, Social Voice, and the Problem We Keep Avoiding
+
+The current AI conversation is dominated by scale.
+
+Larger models. More parameters. More modalities. Occasionally, a small robot appears and reminds us that embodiment still matters. But beneath all of that, a more persistent question keeps resurfacing:
+
+**What does conversational AI look like when it has to work every day, for people who didn’t ask for it?**
+
+Fritzi was built to sit with that question.
+
+Developed in 2024 as a research project at the University of Siegen, Fritzi is a **conversational social voice assistant for nursing home residents**, built on **OpenVoiceOS** and deployed in a real care environment for ten days. It wasn’t designed to be impressive. It was designed to be present.
+
+That distinction turns out to matter.
+
+
+## Social Voice Is Not a Feature Set
+
+Most voice assistants are optimized for task completion. Even when “conversation” is advertised, it usually means a short follow-up window before the system snaps back to command mode.
+
+In a nursing home, that model breaks down quickly.
+
+Residents are not primarily looking to control devices or retrieve information efficiently. What’s scarce isn’t functionality, it’s **time, attention and patient listening**. Fritzi was explicitly framed as a conversational companion, not a task executor, and that framing influenced every technical decision that followed.
+
+This is an uncomfortable space for mainstream voice platforms. It’s also where voice-first systems actually start to justify themselves.
+
+
+## Why OpenVoiceOS Fit This Project
+
+OpenVoiceOS was chosen not because it was easy, but because it was fully open, modular and adjustable. 
+
+The Fritzi team needed:
+
+- Control over activation models  
+- Visibility into failure modes  
+- The ability to swap STT, TTS, and LLM components  
+- A system that did not assume a smart and/ or tech home as its natural habitat  
+
+OVOS made those trade-offs explicit. That also meant the rough edges were visible. Conversation state handling, latency sensitivity, wake word assumptions, and plugin maturity all surfaced as real issues once the system was placed in a nursing home.
+
+From today’s perspective, that list reads less like a critique and more like a preview of the work that followed. Many of these areas have since been addressed, or are actively being addressed, precisely because projects like this forced them into the open.
+
+
+## What Fritzi Broke in OpenVoiceOS and Why That Was Useful
+
+OpenVoiceOS behaves well in controlled environments.
+
+Fritzi removed those assumptions almost immediately.
+
+By placing OVOS inside a nursing home, the project didn’t just *use* the platform, it stressed it. Conversation continuity broke under background speech. Activation edge cases appeared. Latency reshaped turn-taking. External dependencies failed.
+
+None of this was surprising. What *was* useful is that it all happened in real use.
+
+The project exposed a recurring truth: most hard problems in social voice are not model problems. They are **system coordination problems** and they only appear when users behave naturally and environments remain indifferent.
+
+Breaking things was the point.
+
+
+## What Users Forgave and What They Didn’t
+
+One of the most revealing outcomes of the Fritzi deployment had little to do with accuracy.
+
+Transcriptions were sometimes wrong. Responses were occasionally off-topic. Latency disrupted conversational rhythm. And yet, users kept coming back. They tried again. They adapted their speech.
+
+What they forgave were **technical imperfections** that preserved conversational intent.
+
+What they did not forgive were failures of **predictability**.
+
+Silent failures, no response, no sound, no acknowledgement ended interactions quickly. Not with frustration, but with resignation.
+
+Being wrong was acceptable.  
+Being absent was not.
+
+
+## Social Voice Is About Predictability, Not Intelligence
+
+Fritzi did not succeed because it was smart.
+
+It succeeded, when it did, because it behaved in ways that were learnable.
+
+Users quickly internalized patterns:
+
+- press the button  
+- wait for confirmation  
+- speak  
+- wait  
+- listen  
+
+When those patterns held, users adjusted their expectations. When they broke, trust eroded immediately.
+
+This exposes a persistent misconception in voice AI: that intelligence drives acceptance. In care contexts, **predictability matters more than capability**. Intelligence without stability increases uncertainty. Stability enables trust.
+
+These are not tuning issues. They are architectural ones.
+
+
+## From Prototype to Platform: What OpenVoiceOS Enables Next
+
+Fritzi was never meant to be a product.
+
+Its value lies in what it revealed about the infrastructure underneath and how that infrastructure has evolved since.
+
+Nearly every issue surfaced during the project maps to areas that OpenVoiceOS has since prioritized:
+
+- clearer activation and system state signaling  
+- improved conversation handling  
+- stronger plugin boundaries and error propagation  
+- better support for offline, degraded, and hybrid operation  
+- explicit handling of uncertainty instead of silent failure  
+
+What emerges is not “a better assistant,” but a **more dependable foundation** one that can be audited, adapted, and deployed in sensitive environments where privacy, predictability, and long-term maintainability matter more than novelty.
+
+From that perspective, Fritzi reads less like an experiment and more like an early integration test.
+
+It asked the questions platforms eventually have to answer anyway:
+
+- What happens when the network disappears?  
+- How does the system explain itself when it fails?  
+- Who is responsible for what the assistant says?  
+- How do we design voice systems people *learn*, rather than tolerate?
+
+Most of the issues uncovered are no longer open questions. They are being addressed systematically.
+
+That is the difference between a demo and a platform.
+
+
+## Help Us Build Voice for Everyone
+
+OpenVoiceOS is more than software — it’s a mission.
+
+If you believe voice assistants should be open, inclusive, and user-controlled, there are many ways to help:
+
+- **💸 Donate** — support development, infrastructure, and long-term sustainability  
+- **📣 Contribute open data** — share voice samples and transcriptions under open licenses  
+- **🌍 Translate** — help make OpenVoiceOS accessible in every language  
+
+We’re not building this for profit.
+
+We’re building it for people.
+
+👉 [Support the project here](https://www.openvoiceos.org/contribution)
+
+
+----
+
+## Acknowledgements
+
+Fritzi was developed as a collaborative research-through-design project at the University of Siegen between October 2023 and March 2024. The work brought together interaction design, human–computer interaction research, and open voice infrastructure. We would like to acknowledge C. J. Spengler for the project’s technical architecture and OpenVoiceOS integration, Bareen Miraj for research coordination, field work, and participatory design with residents, and Khoshnaz Kazemian for the interaction design, physical form, and visual identity of Fritzi. The project was shaped in close collaboration with nursing home residents and staff, whose patience, openness, and everyday feedback grounded the work in reality.