Architecture

Rivet packages a repeatable team workflow. Coding harnesses already provide editing, terminals, MCP clients, and agent tools; Rivet reuses those capabilities and adds explicit operations where shared configuration, state, verification, or recovery needs them.

From your coding harness

Uservia coding harness

↓

Rivet protocolsGuided host workflow

From your terminal

Terminal userfrom your project

↓

rivet run "task"Direct CLI entry

↓↓

Rivet CLI

↓

Workflow service

Private run stateand evidence

Project checksand Git worktrees

Memory & tool providersConfigurable

Delegated model executionOptional

Both entry paths use the same CLI and workflow service. Provider availability varies; see integrations and models.

Project identity

• Command: rivet.
• Project policy: .rivet.
• Runtime environment: RIVET_* variables.
• Private state: Rivet-owned directories under the repository's Git common directory.
• Harness skills: rivet- prefix.
• Package, releases, and documentation: maintained in the Rivet repository.

Harnesses and models are different

A harness provides tools and an execution environment. An API or local text model does not automatically have those tools. Model adapters must declare capabilities and their actual execution status. The framework must not require a second model process simply because the active harness calls its CLI.

The feature bridge supports both spawned adapters and an active-host contract. In host mode, Rivet prepares one durable action and isolated worktree, while the current harness performs the edit. Result submission revalidates the exact action, scope, evidence, and repository changes before integration. This keeps the workflow provider-independent without treating a model registry entry as execution authority.

Evidence

A model's success message is not a passing test. Rivet ties recorded outcomes to repository changes and actual checks. External delivery is separate from local verification.