Jarvis Voice Runtime Architecture Diagram

Requests and execution

Jarvis CLI uses the production environment: concise answers, JSON results and optional verbose diagnostics. Web, API, voice and CLI share orchestration logic.
Explicit and scheduled recipes use ordered foreground steps. The workflow meta-tool may discover and run a recipe; its switch does not disable explicit or scheduled workflows.

Email and reusable files

The opt-in Gmail inbox authenticates approved senders, verifies attachments into Stash, limits available actions and sends a reply only to the sender in the original thread.
Craft edits images/video/PDFs through its configured gateway. Exports are copied into Jarvis Stash; editable_project_ref and document layer/clip IDs support revisions. Docling converts existing documents and preserves remote task receipts.

Durable background work

Only selected, reviewed Web tools enter the background queue. The separate worker uses leases and writes completion or attention deliveries back to the original conversation. Local observers and reviewed remote callbacks share this job contract.
The job ledger is one control database for both modes, separate from MemoryDB. API, CLI and nested workflow steps reject queued receipts as completed work.

Modes and process ownership

JARVIS_MODE chooses configuration and data; LLM_PROVIDER chooses the backend. Native launchers use the production environment; Docker uses its own runtime and mounted config/data.
The ToolRegistry singleton is shared within a process. Stdio MCP containers belong to that process; remote HTTP/SSE services are connections. Memory currently starts its own registry when loading the workflow catalog or validating a workflow schedule.