Architecture
How Hypervibe's components fit together, who owns each decision, how the parts talk, where state lives and which boundaries keep it safe.
On this page
Hypervibe is the fully managed agentic factory. This page maps who owns each decision, how the parts talk, how the code is layered and deployed, where state lives and which security boundaries hold.
Each decision has exactly one owner #
Every work transition, configuration write, effect, credential refresh and update has one owner. The Hypervibe service is the system of record and runs no work. Shared Work is the one owner of tasks and runs, and every executor uses it. The machine runtime is the supervised part of Hypervibe on each machine.
| Owner | Owns | Never |
|---|---|---|
| Hypervibe service | Identity, configuration, grants, secret records without their values, the registry of skills, tools, hooks and packages, and the inventory | Runs work, installs, or holds a credential value |
| Shared Work | Tasks, runs, attempts, dependencies and claims | Shares them with a second scheduler or task queue |
| Rocket! | The session and its journal, context, behavior profiles per model, approvals, and which tools to call under policy | Holds a credential, calls a model itself or keeps a private queue |
| Lanes | Messages, decisions, attention and the workspace view | Decodes an engine's conversation or holds a credential |
| Throttle | Inference admission, replay and settlement, and custody of every credential | Sets its own policy unprompted |
| Reactor | Admission, leases and receipts for builds, agent tool calls and other registered resources, and installing Hypervibe itself | Decides which resources exist, or runs inference |
| Fleet, the privileged operations workspace | Operator tools, under revocable grants | Keeps a store of its own |
| Machine runtime | Processes, terminals and checkouts on its machine | Gains authority while disconnected |
| Verifier and receiver | The verdict and the disposition | Stand in for each other |
A session is Rocket!'s resumable journal, append-only, and it resumes as the same session after a kill; a lane outlives the processes behind it. Recovering a session, cancelling a job, delivering a message and accepting a result are different operations. An owner commits its change and its receipt together, acts on the outside world afterwards, and holds any unknown effect until it is resolved.
Inference is provider-neutral. Rocket! journals each turn in a neutral form, and Throttle alone decides whether an item in a provider's own form, such as a reasoning block, is sent again. A versioned capability catalogue sits between them and refuses any model it does not list. Throttle explains the design.
A closed protocol family carries every kind of traffic #
Control, inference and terminal bytes travel on separate paths that share one identity and grant model and one command registry, so a keystroke never waits on a database.
| Channel | Carries | Owner |
|---|---|---|
| Lanes host interface | The Lanes host's own API, and federation between hosts | Lanes |
| Session bridge | One conversation, in Rocket!'s own protocol | Lanes carries it; Rocket! owns the content |
| Inference protocol | Model requests and streamed answers, on a path of their own | Throttle |
| Service interface | Commands, each named by its registered action, and one change feed | Hypervibe service |
| Terminal stream | Raw terminal bytes, with backpressure | The machine runtime and Lanes |
| Hooks | Hook events, from a single emitter; policy hooks that return a decision run separately, in Rocket! | Lanes |
Only the Lanes host routes messages and decisions, and any new socket, envelope or message store needs a recorded architecture decision. Native contracts are primary. ACP (the Agent Client Protocol) and MCP (the Model Context Protocol) are optional adapters; MCP is generated from the command registry, for outside agent clients only. An outside system reaches an agent only as a registered action or a mention provider, under a grant.
Identity and grants decide what anyone may do #
The Hypervibe service holds the identities of people, devices and machines. Agents act under grants of their own and never hold a credential. A grant is permission for a subject to act with a capability at a scope: the service issues it, the component that consumes it verifies it, and the owner of the effect checks it again at use. An installed package, a mention or instruction text grants nothing, and an approval binds to the exact action, target and arguments.
On a personal install, your operating-system account is your identity and there is no sign-in. Team members join by invitation and sign in with Google.
Layers and deployments are separate contracts #
| Boundary | Means | Does not imply |
|---|---|---|
| Product | A name that explains capabilities, such as Reactor | Its own database, scheduler or code tree |
| Rust package | A compile-time API and dependency boundary | A process or an install package |
| Process role | A supervised failure, resource or privilege boundary | A second authority over the same state |
| Artifact | Immutable files for one target, selected by digest | Mutable state, grants or credentials |
| Composition | The roles, bindings and prerequisites of one install | Dependency-free use or a hidden fallback |
Dependencies point inward: owner implementations build on pure logic, and pure logic builds on shared contracts. A capability is offered only once it qualifies, and a missing required capability reads unavailable, never as a degraded success. A release set is a tested bill of materials, not a requirement to update every part at once. The first release plans four ways to install, compared in Choose a profile: Just me, team member, team server, and build or agent machine.
State stays with its owner, and derived views never decide #
| Owner's store | Keeps |
|---|---|
| Hypervibe service | Configuration, identity, grants, secret records, commissions and work records |
| Throttle | Usage, its ledger and every credential value, sealed |
| Reactor | Jobs, logs, artifacts and verdict receipts |
| Lanes host | Workspaces, attention and its operation ledger |
| Derived joins | The run receipt and GraphLake, rebuilt from the owners' records; they never decide |
Only shared Work changes work records. In the first release, records local to one machine, such as commissions, and team records, such as settings and membership, never merge. Device-local state stays on the device, and the personal store never reaches a team server. Context and evidence explains the derived joins.
Security boundaries hold where the effect happens #
- No secret value appears in command arguments, logs, prompts, unencrypted backups, browsers or phones. Throttle releases a value only as a short-lived lease to the one process that needs it.
- Text never becomes authority. A
!hypercommand or an@mention is live only from a trusted composer, the command-aware input in Rocket! or Lanes, and a message goes to an inbox, never typed into a terminal. - A personal install must prove that agents cannot reach the owner's control channel or keys.
- Organizations are isolated, and "not found" and "not visible" are one answer.
- Only one holder types into a session at a time. Taking it from someone else opens a decision for the holder, and nothing changes unless they approve.
- A disconnected machine gains no authority.
Where to go next #
- Products for what each component does.
- Work and quality for tasks, verdicts and acceptance.
- Context and evidence for GraphLake and cost attribution.
- Deploy and operate for personal and team installs.
- Glossary for the product's words.