Taxonomy

AI Model

Layer 0. A foundation model. Takes tokens in, produces tokens out. Stateless. No tools. No memory. No loop.

Examples: Claude Opus, GPT-5, Gemini, Codex model, Devstral. The model is raw processing power. It cannot do anything useful without an operating system around it.

Analogy: A CPU. Raw compute. Cannot do anything useful without an operating system.

Agent Core

Layer 1. The model-driven control loop that observes state, selects actions, and iterates toward a goal.

This is the decision-making policy — the "reason, plan, choose, act, observe, repeat" logic. The agent core decides what to do next. It does not provide the tools, environment, or infrastructure that make those actions possible. Key properties: runs in a loop (not single-shot), non-deterministic, goal-directed, selects from available actions but does not define them.

Analogy: The control loop of a process. It makes decisions, but it needs an OS to provide system calls, I/O, and resource management.

Agent Harness (Harness Runtime)

Layer 2. The tools, context management, permissions, memory, lifecycle, and execution environment that make an agent core operational.

A harness includes: tool definitions and execution, context management, state persistence, lifecycle management, guardrails, subagent capabilities, skill/knowledge systems, and system prompts. It wraps a single agent core. It is opinionated — it makes choices about how things work. Canonical examples: Claude Code, Codex CLI, Devin.

Analogy: A container (Docker). Takes a process (agent core) and wraps it with a filesystem, networking, resource limits, and a defined environment.

Agent Harness Framework

A complete, opinionated methodology for agent development, designed as a coherent system of harness assets.

A harness framework is the content and methodology. An AgentSpec is the specification format. Harness frameworks are distributed AS AgentSpecs, but not every AgentSpec is a framework. A single skill with a hook is an AgentSpec but not a framework. Frameworks have skills designed to compose together, an initialization step, an opinion about workflow order, and internal coherence. Examples: G-Stack (YC dev lifecycle), GSD, Superpowers (TDD workflow), Agent Focus.

Analogy: A Linux distribution is to a package format as a harness framework is to an AgentSpec. Ubuntu and Arch are both distributed as packages, but they are coherent systems with opinions.

Agent

A harnessed agent core. The agent core is the decision loop; the harness is the environment that makes it operational.

In ordinary speech, "agent" means the whole running thing. In analysis and design, it splits into core (chooses actions) and harness (makes actions possible). Together they form the practical unit that most people mean when they say "agent."

Analogy: A running container. The process (core) plus the container runtime (harness) working together.

Agent Rig

Layer 3. A desired-state control-plane object that composes one or more agent instances into a reproducible local system.

A rig defines the topology of a multi-agent setup: which agents exist, what roles they play, how they relate, and the policies for materialization. It has three concerns: topology (who exists and how they relate), bindings (how the topology attaches to operational coordinates), and layout (how it is displayed to the human). A single-agent rig is valid. An orchestrator is optional, not required.

Analogy: Docker Compose / Terraform. Defines multi-container (multi-agent) topology declaratively. Can be instantiated, torn down, and re-instantiated.

Agent Pod

A bounded context group within a rig. Contains members (agents), pod-local edges, and optional continuity policy.

Pods are the unit of shared working context and continuity responsibility. Members within a pod share context and can have pod-local edges (collaborates_with, can_observe). Each pod can specify a continuity_policy: ha_pair, checkpoint_all, or none.

Agent Profile

A named configuration variant within an AgentSpec that selects a subset of declared resources.

Profiles filter — they never inject resources not declared in the base spec. You define your own profile names. A profile may override startup and lifecycle defaults. This is how one AgentSpec serves multiple roles: a "reviewer" profile activates review skills, a "coder" profile activates coding skills.

Rig Topology

The core of a rig. Who exists and how they relate.

Agent nodes and their roles (orchestrator, worker, reviewer, observer), relationships (delegates_to, spawned_by, can_observe, collaborates_with, escalates_to), and hierarchy or peer structure. The topology is the rig's essence — portable and durable.

Edge

A declared relationship between two agents in a rig topology.

Edges can be pod-local or cross-pod (using qualified references like pod_id.member_id).

AgentSpec

A portable, reusable single-agent blueprint defined in an agent.yaml file.

Contains resources (skills, guidance, hooks, subagents, runtime_resources), profiles, imports, startup files and actions, and lifecycle defaults. Does not contain rig topology, final runtime/model bindings, secrets, or ephemeral state.

RigSpec

A portable, declarative artifact that describes a rig's desired state. File: rig.yaml.

Contains pods with members and edges, cross-pod edges, rig-level startup overlays, and a culture file. Does not contain live session IDs, active pane refs, or process IDs. Startup files layer in a fixed additive order from agent base through operator debug append.

Analogy: A docker-compose.yml or terraform config. Version-controlled. Shareable. Forkable.

RigRun

One live instantiation of a RigSpec. The actual running system on a machine right now.

Contains active session IDs per agent, bound workspace paths, bound surface/pane refs, current agent status, and last-seen timestamps. A RigRun is ephemeral — it exists while the system is alive.

Analogy: A running Docker Compose stack. Live, ephemeral, observable.

RigSnapshot

A point-in-time observed state of a RigRun. Exists for crash recovery, reboot recovery, and checkpoints.

Contains full topology at capture time, all binding instances, resume metadata per agent, per-agent checkpoints, and health info. A snapshot is an observation, not a prescription — it records what WAS, not what SHOULD BE.

Analogy: A VM snapshot or backup. Point-in-time capture.

Checkpoint

A compact, human/agent-readable summary of a single agent's state at a point in time.

Contains summary of work completed, current task, next step, blocked-on status, key artifacts produced, and confidence level. The critical artifact for cold restore when process-level resume is not possible. Checkpoints exist per-agent but are managed at the rig level.

RigBundle

A portable archive that bundles a RigSpec plus vendored AgentSpecs into a single shareable .rigbundle file.

Contains a RigSpec with rewritten agent_ref values, vendored AgentSpecs with full resource trees, and a bundle.yaml manifest with per-file SHA-256 checksums. Enables machine-to-machine portability without external references.

Analogy: A distributable archive. Everything needed in one file.

Workspace

The code root an agent can act on (cwd). A directory tree that defines the scope of the agent's work.

Examples: a git repo checkout, a monorepo subdirectory. Multiple agents can share a workspace (for collaboration) or have isolated workspaces (for independence).

Analogy: A volume mount or working directory.

Agent Session

One live execution of a harness bound to a workspace.

A session has a start, a duration, and an end. It accumulates conversation history, tool calls, and state. Scoped to a workspace, has a lifecycle (start, running, ended/suspended), and can be resumed in some harnesses. Subagents run within a session; rig nodes are separate sessions.

Agent Runtime

The execution substrate and policy boundary for an agent. Defines what the agent can physically do.

Properties include: execution environment (local shell, container, VM), permission boundary (sandboxed vs unrestricted), resource limits (CPU, memory, network), and approval mode. A sandbox is a type of runtime with restrictive policy boundaries, not a separate coordinate.

Analogy: A host or VM. The execution substrate.

Surface

The human-visible UI container where an agent's session is displayed and interacted with.

Examples: a tmux pane, an IDE terminal panel, a browser pane. Surfaces can be rearranged without affecting the session. tmux and similar tools are session hosts and visibility surfaces, not runtimes — the harness runs INSIDE a surface.

Analogy: A display or terminal.

Worktree

One way to materialize an isolated workspace using a git worktree.

Creates a separate checkout at a specific branch, providing filesystem-level isolation between agents working on the same codebase. Multiple agents can work on different branches simultaneously without full repository duplication.

Configuration Scope

Where an agent's configuration lives and who can see it. Controls sharing, privacy, and override order.

Think of it like environment variables — some are project-level (shared with the team), some are personal (your machine only), some are temporary (this session only). Scopes: project_shared (checked into repo, teammates see it), project_local (on your machine, gitignored), user_global (your personal defaults across all projects), session_ephemeral (one run only, then gone).

Agent Continuity Policy

A pod-level policy that governs how agents within a pod handle state continuity and recovery.

Options: ha_pair (shared memory high-availability — members can take over for each other), checkpoint_all (all agents write checkpoints for cold restore), none (no coordinated continuity). Works with restore_policy at the agent level to determine recovery behavior.

Agent Managed Software

Software systems operated by agents within a rig, where the agents handle configuration, maintenance, and user interaction on behalf of the human.

A rig can package actual software alongside the agents that manage it — the agents spin it up, configure it, and operate it for you. Instead of needing a developer or IT department to manage a software system, an agent does it proactively. Example: a secrets manager agent that ships with Bitwarden, configures it for your needs, and handles all secrets operations when asked. This pattern — agent managed software — is what made Open Claw viral: an always-on agent operating software systems on your behalf. With OpenRig, any rig can include managed software via the rig environments spec.

Rig Environment

Software and services packaged into a rig that agents spin up and manage as part of the topology.

A section in the RigSpec that declares software dependencies the rig needs to operate. Agents in the rig are responsible for launching, configuring, and maintaining these services. This is what enables agent managed software — the rig doesn't just define agents, it defines the infrastructure those agents operate.