Architecture
How live voice, the task agent and the authenticated desktop service work together.

Two brains, shared desktop tools
The default jarvis command and jarvis run start the dual-brain runtime. Gemini Live receives microphone audio and handles spoken replies. Supported everyday functions call the desktop service; complex requests are delegated to JarvisV2 through an authenticated A2A connection.
Microphone ↔ Gemini Live
├─ Desktop service → supported local actions
└─ A2A → task agent → files, terminal, web, MCP, skillsServices with specific responsibilities
The A2A service coordinates high-level tasks. The desktop service owns persistent organizer items, jobs, activity, context and application bridges. Both brains can use the same desktop tools.
The old terminal chat UI, browser chat UI, desktop web dashboard and legacy UI protocols have been removed. Local services remain because the assistant and integrations need them.
Separate provider choices
Voice uses Gemini Live. The task agent uses your separately configured provider or compatible local model server. Audio-file transcription and speech generation have their own providers. A local task model does not make the default voice session offline.
Follow the actual data path
Desktop metadata and activity records persist locally. A model request can include relevant context and file contents, which are then processed by your configured provider. Sharing prepares file copies and dispatches them only through connected messaging accounts.
The source includes explicit outcomes such as accepted, completed, partial and unconfirmed. A queued job, an application dispatch and a verified result mean different things.