Tools & providers

Two capability surfaces sit under the daemon: a registry of ~110 built-in tool wrappers it executes on behalf of any client, and the LLMProvider abstraction that routes completions to a local model or to the claude / codex CLIs. Everything runs through the daemon — clients never open a socket to the cloud themselves.

The tool registry

Every executable capability — read a file, run a shell command, open a PR, tail pod logs, sample a Parquet file — is registered exactly once as a Tool and exposed through a single registry + executor. The pieces live under src/daemon/tools/:

• registry.ts — the unified registry every tool registers into.
• executor.ts — validates input against the tool's JSON schema, fires the approval gate when required, then runs it.
• builtins/ — the ~110 built-in wrappers, one domain per subdirectory.

A single registration serves two callers: the LLM (via the tool-call protocol) and daemon controllers (via kind: 'tool' tasks). Same schema, same execution, same approval flow.

Categories

Tool IDs follow a domain_verb_noun convention (a handful of deeper namespaces use domain:sub:action). One row per capability domain, with real IDs drawn from src/daemon/tools/builtins/:

A related docs family (docs_retrieve, docs_project_context, docs_summary_get) surfaces indexed documentation to the same callers.

LLM providers

All model interaction goes through one interface, LLMProvider, defined in src/shared/types.ts. Application code never imports an SDK directly — it holds an LLMProvider and calls its methods:

• complete(messages, opts) — one completion.
• stream(messages, opts) — token stream (async iterable).
• embed(text) — embedding vector (empty array if unsupported).
• completeStructured<T>(...) — schema-enforced JSON (see below).
• supportsTools — whether the provider can drive tool-calls.

Two implementations back it:

# claude: structured output via native --json-schema
$ claude --print --output-format json --json-schema '<inline>'
# codex: structured output via --output-schema
$ codex exec --output-schema <tmpfile> --json
# auth + quota belong to the CLI's own OAuth session — no keys on our side

Structured output

src/agent/providers/structured-output.ts gives providers a schema-validated JSON path. It compiles the caller's JSON Schema with ajv (draft 2020-12, singleton compiled-validator cache) and validates every response. On a validation mismatch the helper re-issues the completion with the errors appended to the conversation, retrying up to maxAttempts (default 3) so the model can self-correct.

The provider's wire layer enforces the schema natively where it can — Ollama via format, the CLIs via --json-schema / --output-schema — and ajv re-validates as a defensive backstop. A provider without a native structured-output API sets its capability flag off and throws a clear "not supported" error, so callers gate on the flag at config time.

Where next