Hi, Mario! Here I am

Mario Elisei
What's your approach to designing AI-driven interfaces for enterprise platforms? Specifically around component architecture and scalability.
Great question. When designing AI interfaces for enterprise, I focus on three core pillars.

01 · Transparency — users must always understand what the AI is doing, its confidence level, and when it's uncertain. This means explicit state indicators, not just loading spinners.

02 · Progressive disclosure — start with the essential output. Let users drill into reasoning, sources, and alternatives on demand. Cognitive load management is critical in enterprise contexts.

03 · Error resilience — AI fails. Design for graceful degradation. Every AI action should have a clear fallback, an undo path, and a way to override.
Mario Elisei
How does that translate to component architecture in a design system like Figma with MCP integration?
With MCP + Figma, you close the gap between design intent and implementation. The key is treating design tokens as a single source of truth — colors, spacing, typography all flow from Figma variables directly into code.

In practice this means your component library in Figma maps 1:1 with your production components. When a designer adjusts a token in Figma, the change propagates through MCP into the codebase automatically.

The architecture looks like: Figma variables → MCP bridge → design tokens JSON → component props → rendered UI. No manual handoff, no translation layer where intent gets lost.
Mario Elisei
That's a solid pipeline. What about multi-role enterprise platforms where different user personas need different levels of AI autonomy?
This is where parameterization at the role level becomes essential. Each persona — say an operator vs. an analyst vs. an admin — gets a different AI autonomy profile.

Operators might see AI suggestions but always approve actions. Analysts get full AI output with citations. Admins can configure autonomy per workflow. The underlying AI is the same; what changes is the trust surface exposed to each role.

Design-wise, this means your component states need to encode permission level. A button that triggers an AI action looks and behaves differently depending on whether the current user can act on it autonomously or needs to confirm. Same component, different state expression — this is where a well-structured design system pays off significantly.
Demo only — no live model connected.
// TEMPLATES
// AI MODEL
// AI Chat · Demo

Glad you're
testing the chat.

The navigation is a demo only. To access the chat with live local models, request a demonstration below.

Home Writing Raspberry Voice Assistant AI

Raspberry Voice Assistant AI

Raspberry Voice Assistant AI
Sponsored

// Edge AI · Raspberry Pi 5

100% offline Raspberry Pi 5 · 8GB Python 3.13 CPU inference MIT License

01How it works

🎙 MicrophoneUSB input Whisperspeech → text Ollama LLMreasoning Pipertext → voice 🔊 SpeakerBluetooth

Each stage runs locally. After the initial setup, the Pi needs no internet — it listens, transcribes, reasons and answers entirely on the edge.

// text piped into Piper over SSH — synthesised to a .wav on the board, straight out to the speaker

02Booting up

The assistant runs as a systemd unit, so it comes up on its own when the board powers on. This is the real journal from a cold boot — sudo journalctl -u localmind -f:

$ sudo journalctl -u localmind -f

21:28:13 [W:onnxruntime] GetGpuDevices — failed to detect devices under
          "/sys/class/drm/card0"
21:29:24 UserWarning: 'CUDAExecutionProvider' is not in available provider
          names. Available: 'AzureExecutionProvider, CPUExecutionProvider'
21:29:25 ⏳ Carregando Whisper...
21:29:25 ✅ Whisper pronto
21:29:25 ⏳ Carregando Wake Word...
21:29:25 ✅ Wake Word pronto — diga 'Hey Jarvis' para ativar
21:29:25 🟢 Assistente iniciado! Aguardando sua voz...
21:29:25 👂 Ouvindo...
21:29:25 🎙 Voz detectada, gravando...

Those two warnings at the top are the point, not a problem. ONNX Runtime looks for a GPU, finds no /sys/class/drm/card0, and falls back to CPUExecutionProvider. Every model in this pipeline is running on the Pi’s four Cortex-A76 cores — no accelerator, no offloading.

72s
cold start
CPU
only backend
~6GB
resident RAM
0
API calls
Two terminal windows: the localmind service journal on the left, a ping to rasp-ai.local on the right
// left: the service journal. right: mDNS resolving rasp-ai.local → 192.168.0.145

The board is headless on the LAN and advertises itself over mDNS, so there is no IP address to memorise — from any machine on the network:

Terminal on a Mac pinging rasp-ai.local, resolving to 192.168.0.145
// ping rasp-ai.local — from the Mac, over Wi-Fi

03Hardware

SBC
Raspberry Pi 5 · 8GB
Main board
Storage
MicroSD 64GB+
Class A2 recommended
Microphone
USB PnP
Any USB mic works
Speaker
Bluetooth / USB
iHome MicroGo
Cooling
Active cooler
Pi 5 runs hot

⚠️ The Pi 5 has no 3.5mm jack — audio goes out over USB or Bluetooth.

Raspberry Pi 5 on a desk with a USB gooseneck microphone and a Bluetooth speaker
// the whole assistant — board, microphone, speaker. nothing else.
Close-up of the Raspberry Pi ports with ethernet and USB peripherals connected
// every peripheral is USB — no HAT, no soldering
Top view of the Raspberry Pi case showing the active cooler fan through the lid
// the active cooler is not optional under sustained inference

04The build, end to end

Every step below is a real screenshot from the build — no reconstructions. Total time from a blank SD card to a talking assistant: about four hours, most of it spent downloading models.

4.1Flash the OS

Raspberry Pi Imager writes Raspberry Pi OS 64-bit to the card. The customisation panel is doing real work here — hostname, user, Wi-Fi and SSH are all baked in before first boot, which is what makes the board reachable headless as rasp-ai.local without ever attaching a keyboard.

Raspberry Pi Imager writing the OS image, with the customisation steps listed in the sidebar
// hostname, user, Wi-Fi and SSH pre-configured before the first boot

4.2First SSH, then update everything

Straight into ssh rasp-ai@rasp-ai.local and a full upgrade. Worth noting what scrolls past: arm64 packages from Debian trixie and a linux-image-6.18.34-rpt-rpi-2712 kernel — 2712 being the BCM2712 SoC, the Pi 5’s chip.

SSH session downloading hundreds of arm64 Debian packages during a system upgrade
// apt pulling arm64 packages over SSH — Debian trixie, kernel 6.18 for BCM2712

4.3Audio stack and Ollama

PulseAudio, PortAudio and rtkit go in first, then Ollama’s installer. Its closing line is the honest one: “No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode.” That is the operating assumption for this whole project, not a warning to work around.

Terminal installing PulseAudio then Ollama, ending with a CPU-only mode warning and the model pull
// “Ollama will run in CPU-only mode” — then pulling qwen2.5:3b, 1.9 GB

4.4Does the model actually work?

Before wiring anything to audio, check the brain in isolation. Two prompts, two languages, answered locally on the board:

Terminal running ollama with prompts in Portuguese and English, both answered correctly
// qwen2.5:3b answering in PT and EN — entirely offline

4.5Whisper, in a virtualenv

faster-whisper pulls in CTranslate2 and ONNX Runtime. Notice the wheels come from piwheels — precompiled for aarch64, which is the difference between a two-minute install and an hour of compiling on the Pi.

pip installing faster-whisper, ctranslate2, onnxruntime and dependencies from piwheels
// aarch64 wheels from piwheels — no local compilation

4.6The Portuguese voice

Piper’s voices are plain .onnx files pulled from Hugging Face. The PT-BR “faber” medium voice is 60 MB — this is the last thing the build needs from the internet.

wget downloading the pt_BR-faber-medium.onnx Piper voice model from Hugging Face
// pt_BR-faber-medium.onnx — 60 MB, the last download of the project

4.7Audio is where the real work is

This is the step nobody warns you about. Getting models to run is straightforward; getting a USB microphone and a Bluetooth speaker to behave on Linux is where the hours go. Two separate mixers, tuned independently in alsamixer — playback on the PulseAudio device, capture on the USB PnP Sound Device.

alsamixer showing the PulseAudio playback device with master volume at 40
// playback — PulseAudio, master at 40
alsamixer showing the USB PnP Sound Device capture level at 62 with 14.88 dB mic gain
// capture — USB PnP, gain +14.88 dB, level 62

Set the capture gain too low and Whisper transcribes silence; too high and the mic clips into noise that the model happily hallucinates words out of. 62 with +14.88 dB was the sweet spot for this microphone in this room — expect to find your own.

4.8Wiring the three together

The script is short because each component does one thing. record_audio() captures at the mic’s native 44.1 kHz and resamples to the 16 kHz Whisper expects; transcribe() hands the array to Whisper; ask_llm() keeps a six-turn history and posts to Ollama’s local REST API.

Source code of main.py showing the record_audio, transcribe and ask_llm functions
// main.py — resample 44100→16000, transcribe, then POST to localhost:11434
# the resample line that makes the USB mic usable by Whisper
audio = resample_poly(audio.flatten(), 160, 441)   # 44100 → 16000 Hz

# Whisper loaded once, quantised to int8 for CPU
whisper = WhisperModel(WHISPER_MODEL, device="cpu", compute_type="int8")

4.9First run

The moment of truth — python3 assistant/main.py, and Whisper starts loading.

Terminal running main.py for the first time, printing the Whisper loading message
// ⏳ Carregando Whisper… — the first launch, before it became a service

Once it worked by hand, the last step was making it permanent: a systemd unit so the assistant starts with the board and restarts if it ever dies. That is the service you saw booting at the top of this page.

05Software stack

StageToolModel
Speech-to-Textfaster-whisperlarge-v3
Language ModelOllamaqwen2.5:3b
Text-to-SpeechPiper TTSpt_BR-faber-medium
Wake WordopenWakeWordhey_jarvis
Audio I/Osounddevice / PulseAudio44.1→16 kHz
RuntimeONNX RuntimeCPUExecutionProvider

06RAM footprint

OS + system~400 MB
Whisper large-v3~3 GB
Ollama qwen2.5:3b~2.5 GB
Piper TTS~120 MB
Total~6 GB ✅

Comfortably within the 8GB Pi 5’s budget.

07Roadmap

  • Custom wake word trained in Portuguese
  • Local RAG over personal documents (ChromaDB)
  • Home Assistant integration via local API
  • Web interface with Open WebUI
  • Vision support (camera + llava) and YOLOv8 smart alerts

08Built with

  • Ollama — local LLM runtime
  • faster-whisper — optimized Whisper for CPU
  • Piper TTS — offline text-to-speech by Nabu Casa
  • openWakeWord — open-source wake word detection
$ localmind –offline –on-device · MIT © 2026
Sponsored
0
// LEAVE A COMMENT

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *