Architecture Reference · v0.11.7

vak — a layered map of every component

vak is a local-first Rust harness for running general-purpose agents without giving up the receipts. Its mechanism is one core, many surfaces: a single auditable, policy-gated core drives a CLI, a Tauri desktop app, an HTTP/SSE server, and chat gateways. This document lays out all 18 workspace crates plus the two web frontends as a dependency-ordered stack — foundations at the bottom, surfaces on top.

18 Rust crates 2 SolidJS frontends 4 surfaces edition 2024 tokio async runtime

The dependency stack

Five layers, one direction of trust

Each layer depends only on the ones beneath it. Effects flow downward through the same gates on every path; the surfaces at the top implement no privileged shortcuts of their own — they compose the core, the permission engine, the brokered tool registry, and the append-only ledger.

L4 Surfaces Where humans and gateways enter
vak CLI vak-server HTTP/SSE + gateways vak-desktop Tauri 2 vak-tray vak-desktop/ui SolidJS vak-admin-ui SolidJS
compose & expose ↓
L3 Orchestration Assembles the running system
vak-core vak-flow vak-eval vak-ops
drive ↓
L2 Capability engines The agent and its extensions
vak-agent vak-mcp vak-store
build on ↓
L1 Records & primitives Ledger, config, tools, hooks
vak-session vak-tools vak-config vak-hooks
rest on ↓
L0 Foundations No internal dependencies
vak-llm vak-permission vak-delivery

Component catalogue

What each crate does

Grouped by layer, bottom-up. Every crate names its principal source modules so the map points straight into the tree.

L0

Foundations

No internal dependencies — the trusted base
vak-llmcrate

Provider clients, streaming, model routing, and usage accounting. The one thing nearly every other crate depends on.

modules: anthropic · openai · openai_responses · google · registry · route · sse · stream · models · work
vak-permissioncrate

The policy engine every effect passes through before dispatch. Rules in, allow/deny/prompt out — the heart of "nothing acts without permission."

modules: engine · rules
vak-deliverycrate

Outbound message transport with a durable outbox and templating — the wire chat gateways and notifications send over.

modules: client · outbox · telegram · templates
L1

Records & primitives

Depend only on foundations
vak-sessioncrate

The append-only JSONL ledger: event types, contracts, receipts, and recall. Branching and compaction append rather than rewrite, so every session is reconstructable.

modules: log · index · search · types
uses: vak-llm
vak-toolscrate

The built-in tool set plus the broker and sandbox boundary: filesystem, shell, search, and web, each brokered through the permission gate. Landlock enforces containment on Linux.

modules: bash · edit · read · write · grep · glob · broker · sandbox · landlock · webfetch · webbrowse
uses: vak-llm
vak-configcrate

The layered configuration model — defaults through user, project, environment, and CLI — with unknown keys warning rather than failing startup.

uses: vak-llm
vak-hookscrate

Lifecycle hook dispatch — user-supplied extension points around agent events, themselves policy-gated.

uses: vak-permission
L2

Capability engines

The agent loop and its extensions
vak-agentcrate

The agent turn loop: goal tracking, steering, spend limits, a failure circuit-breaker, and stop policy. Where a session's model calls and tool dispatches are actually driven.

modules: goal · task · steering · spend · circuit · stop_policy · context · workspace
uses: session · tools · hooks · permission · llm
vak-mcpcrate

Model Context Protocol client and manager — external MCP servers surfaced as brokered tools, so extensions get the same gate as built-ins.

modules: client · manager · tool
uses: vak-tools
vak-storecrate

A SQLite FTS5 rebuildable index over the JSONL ledgers — full-text session search and recall that can always be regenerated from the source of truth.

uses: vak-session · vak-llm
L3

Orchestration

Assemble the running system from the engines below
vak-corecrate

The composed core the surfaces share: checkpoints, memory, worktrees, FinOps, routing, the Docker sandbox, skills, learning, tasks, transcripts, and the system prompt. This is the "one core."

modules: checkpoints · memory · worktree · finops · routing · sandbox_docker · skills · learning · reflection · tasks · digest · inbox · transcript_md · custom_commands · security_events · health · backup
uses: agent · config · hooks · llm · mcp · permission · session · tools
vak-flowcrate

Static, declarative multi-step flows — checked and run through the same agent and permission machinery as an interactive turn.

uses: agent · llm · permission · session · tools
vak-evalcrate

Deterministic and live evaluation harness — exercises the agent against fixtures or real providers, gated identically to production runs.

uses: agent · llm · permission · session · tools
vak-opscrate

Service lifecycle management — installing and controlling vak as a durable background service (macOS LaunchAgent / Linux systemd user unit).

modules: services
uses: vak-config
L4

Surfaces

The four ways in — same core behind each
vakCLI binary

The headless surface: vak exec, plan, flow, eval, config dump, sessions, checkpoints, memory, and a doctor. Depends on nearly every crate.

modules: cli · doctor · install · backup · digest · inbox · memory · tasks · format
uses: agent · config · core · delivery · eval · flow · llm · server · session · ops · permission · tools
vak-serverHTTP/SSE + gateways

Exposes the session, run, approval, transcript, diff, and steering contracts over HTTP/SSE, plus chat gateways (Slack, Discord, Telegram), an admin API, rate limiting, and a core pool.

modules: gateway · channels · slack · discord · telegram · events · admin · admin_ui · core_pool · rate_limit · heartbeat · delivery
uses: agent · config · core · delivery · llm · ops · session · store · flow · hooks · tools
vak-desktopTauri 2

The native client host: isolated worktrees, streaming chat, diff review, an editor, a PTY terminal, previews, side chats, and best-of-N comparison. Embeds the server contracts.

modules: main · pty
uses: core · delivery · config · ops · server · tools
vak-desktop/uiSolidJS

The desktop front end (package vak-ui): SolidJS + Vite, xterm.js terminal, Shiki syntax highlighting, and the chat, composer, and diff components.

stack: solid-js · vite · @xterm/xterm · shiki · @tauri-apps/api
vak-admin-uiSolidJS

The admin console front end, built on the same token set as the desktop UI so the two surfaces read as one product. Served by the server's admin API.

stack: solid-js · vite · typescript
vak-traytray app

A menu-bar / system-tray companion for controlling the background service without a full window.

uses: vak-ops · vak-config

Cross-cutting mechanisms

The five things every surface shares

These are the product's load-bearing guarantees. They live in the lower layers precisely so no surface can route around them.

Append-only ledger

Every session is a JSONL event log. Branching and compaction append; nothing is rewritten, so any state is reconstructable. vak-session · vak-store

Permission before dispatch

Tools, workers, flows, plans, evals, and server runs all clear the same policy engine before any effect. Missing containment fails closed. vak-permission · vak-tools broker

Receipts for every dispatch

Each provider call and tool run leaves an auditable receipt in the ledger — usage, cost, and outcome — so behavior doesn't vary by surface. vak-llm · vak-session

Sandbox boundary

Filesystem and command effects run inside a brokered boundary: Linux Landlock, an optional Docker sandbox, and workspace-scoped writes. vak-tools · vak-core sandbox_docker

Typed failure

Errors are typed, partial work is preserved, and failure states are explicit — a first-class contract, not an edge case to hide. across every layer

Policy surface

Three permission modes

The gate every effect passes through resolves against one of three modes. full-access is never selected automatically after a denial, failure, retry, prompt, or model recommendation.

ModeFilesystemCommandsIntended use
read-onlyWorkspace reads onlyRestrictedAudits, exploration, review
workspace-writeReads and writes inside the canonical workspaceSandboxed and policy-gatedEveryday coding — the default
full-accessUnrestricted host accessUnsandboxed, still rule-gatedExplicitly trusted, supervised work

Configuration

Layered, predictable resolution

Configuration merges left-to-right; later sources win. Privileged project keys — permissions, hooks, MCP servers, gateway, sandbox, provider endpoints — require workspace trust.

defaults‹ ~/.config/vak/config.toml‹ .vak/config.toml‹ environment‹ CLI