AI delivery model
Helmhive keeps workspace intent separate from provider-specific execution. Each kind of job has an immutable envelope defined in application code that fixes its maximum tools, filesystem access, output contract, required capabilities, and network policy. A profile can narrow an envelope; it can never expand it.
Runners
Section titled “Runners”A runner is an isolated process that connects outbound over HTTPS, holds its own provider login, and reports what it offers: provider, adapter version, authentication state, placement labels, supported capabilities, concurrency, and the fingerprint of its execution environment. Runners have a control state (Active, Draining, Disabled, Revoked), a reported status (Online, Needs attention, Offline), and an authentication state. Only an Active, Online, Authenticated runner is schedulable. See Manage runners.
Envelopes and profiles
Section titled “Envelopes and profiles”Envelopes exist for the connection test, implementation and review probes, change planning,
change implementation, change review, and policy suggestion. All governed-change envelopes
require structured output, the domain:code label, and disabled network access; only
implementation envelopes allow workspace writes; review envelopes add diff review and forbid
writes.
A profile adds purpose, instructions, provider mappings with primary and fallback models and a reasoning effort, tool policy, output contract, session policy, memory policy, and required labels. Requirements are unioned with the envelope’s. A review profile must stay read-only. Every job stores the exact profile revision and a full snapshot, so later edits never change running or historical work. See Configure profiles and models.
Models
Section titled “Models”Runners publish their model catalogue at registration and on every heartbeat. Profiles map intent to a provider’s model identifiers; scheduling refuses an explicit model no compatible runner advertises, and automatic selection uses the runner-reported default.
Routing
Section titled “Routing”For a governed change, planning, implementation, and review each resolve the active profile’s provider mappings on the server. The first mapping is preferred when a registered runner has a valid credential, fresh authenticated health, the mapped model, and every required capability and label. Review prefers a different provider from implementation and falls back to the same provider in a separate fresh context. When no mapping is eligible, the job fails closed at queue time.
Sessions
Section titled “Sessions”A profile chooses fresh, resume, or fork. Continuity is bound to the workspace, profile, provider, runner credential, and workspace-or-service scope; a different runner starts its own chain. Provider session identifiers never reach the browser, and an administrator can reset a binding. Governed change work always starts fresh.
Memory
Section titled “Memory”Memory is a small, explicit set of approved decisions and constraints, scoped to the workspace or one service, each with a source, sensitivity, optional expiry, and audit trail. When a job’s profile allows it, the control plane injects at most twenty active records, bounded to two thousand characters each, labelled as context rather than authority. Governed change jobs receive none; their context is the immutable request, confirmed criteria, plan, exact source, patch, and bounded check evidence.
What is audited
Section titled “What is audited”Profile revisions, memory changes, session resets, runner transitions, registration and rotation, selected models, and injected memory identifiers, without recording native session identifiers or credentials.