Project case study

Alpha · Running on WindowsC# · .NET 10 · WinForms · Ollama · Vosk

Focal Agent

A local-first Windows assistant that joins private AI chat, offline voice input, and explicit plugin permissions in a native desktop experience.

View source on GitHubExplore the architecture
The assistant keeps model choice, microphone state, and plugin authority visible to the user.
RoleCreator and developer

Windows product design, local model integration, offline speech pipeline, plugin host, and consent flow.

PlatformNative Windows desktop

A .NET 10 WinForms application with tray controls and packaged local speech assets.

Current stateWorking alpha

Local chat, voice capture, and the first permission-gated plugin path are implemented; broader automation remains roadmap work.

The challenge

Make desktop AI useful without making it opaque.

A desktop assistant sits at an unusually sensitive boundary. It can hear a microphone, inspect the machine, invoke tools, and send prompts to a model. Convenience alone is not enough; users need to understand where inference runs and when the assistant is asking for additional access.

Focal Agent starts with a local path. Ollama serves the language model on the same Windows machine, Vosk performs speech recognition offline, and plugins declare named commands in manifests. Commands marked as protected stop at a native Yes/No prompt before the child process is launched.

System design

One Windows shell coordinates three deliberately separate boundaries.

Conversation, speech, and system inspection share the interface, but not the same authority. Each integration has its own protocol, failure path, and visible state.

01 · Inference

Keep the default model local

The app checks Ollama at localhost, starts its server when needed, verifies the configured model, and pulls it if absent.

02 · Speech

Recognize voice offline

NAudio captures a 16 kHz mono stream and Vosk converts completed utterances into editable prompt text.

03 · Tools

Isolate plugins by process

Manifest commands execute out of process through JSON stdin/stdout instead of loading third-party code into the UI runtime.

Engineering decisions

Turn local-first principles into observable application behavior.

01 · Local model lifecycle

Own the setup path

Constraint
A local assistant is frustrating if users must manually coordinate a model server before every session.
Decision
Probe Ollama's local API, start ollama serve when unavailable, wait for readiness, and verify llama3.
Tradeoff
The alpha hard-codes one model and a five-minute request timeout; model management and profiles remain future product work.
02 · Permission model

Stop before protected work

Constraint
Natural-language intent must not silently become operating-system authority.
Decision
Require a native confirmation for manifest commands marked requiresPermission and for model responses using the permission-request contract.
Tradeoff
The current convention is an alpha foundation, not yet the richer capability policy and audit system envisioned by the roadmap.
03 · Plugin supervision

Bound external execution

Constraint
A plugin can hang, crash, write malformed output, or disappear from disk.
Decision
Validate manifests, redirect all process streams, enforce a 15-second timeout, kill timed-out process trees, and reject empty or unsuccessful responses.
Tradeoff
Process isolation adds startup overhead but creates a much clearer operational boundary than in-process extensions.
04 · Windows experience

Behave like a desktop utility

Constraint
An assistant should remain accessible without permanently occupying the foreground.
Decision
Use a native WinForms window with system-tray actions to show the app, start or stop listening, and exit.
Tradeoff
The Windows-native approach supports the current product goal while postponing cross-platform UI concerns.

End-to-end behavior

The alpha already closes three useful loops.

Typed prompts travel to Ollama's non-streaming generate endpoint and return to the conversation view. Spoken input stays local and becomes editable text before submission. Plugin actions remain explicit menu selections with command descriptions and permission checks.

Errors are also part of the experience: the interface distinguishes an unreachable model server, model timeout, missing speech assets, plugin timeout, nonzero exit, empty output, and plugin-reported failure.

Conversation

Local Ollama chat

Readiness checks, automatic server startup, model discovery and pull, prompt policy, and visible response state.

Voice

Offline speech to prompt

Microphone capture, bundled Vosk model discovery, recognition, and insertion into the same editable prompt box.

Plugins

Permission-gated inventory

Manifest discovery, command menus, consent, supervised execution, and formatted JSON results from five Windows inventory commands.

Repository evidence · August 2026

The implementation makes its boundaries measurable.

These figures describe the current public main branch rather than the full README roadmap.

3Working interaction paths

Typed chat, offline voice capture, and external plugin commands converge in one desktop UI.

15sPlugin execution limit

A timed-out plugin is terminated with its process tree instead of running indefinitely.

16 kHzSpeech input

Mono microphone samples feed the bundled English Vosk recognition model.

5Packaged tool commands

The inventory manifest exposes system, disk, network, process, and service queries.

Where it stands

A functioning local-first assistant with an intentionally narrow alpha surface.

The code proves the core interaction and safety boundaries. It does not yet claim the persistent memory, cloud-provider breadth, or automation engine described in the long-term roadmap.

Implemented

  • Native Windows chat interface and tray controls
  • Local Ollama server and model readiness flow
  • Offline Vosk voice recognition
  • Manifest-based plugin discovery and validation
  • User approval before protected plugin commands
  • JSON process protocol with timeout and error handling
  • Packaged read-only inventory integration

Roadmap

  • Real cloud-provider integrations
  • Conversation history and persistent memory
  • Capability-based permissions and audit history
  • Tool calling driven by structured model output
  • File, clipboard, and screenshot workflows
  • Configuration profiles and complete settings
  • Multi-agent workflow orchestration

Go deeper

Read the product direction and inspect the working boundaries.

The repository documents the target experience and exposes the current Windows implementation.

Repository Product goals and roadmap Plugin system Desktop, Ollama, and voice flow Plugin supervision Inventory plugin case study