Agent Starters

A named, reusable per-seat starting point. Composes an agent role, startup context, optional native session source, and provenance into something a user or rig can choose when creating, refreshing, or packaging a seat.

This registry-backed startup context is distinct from the rig agent-image surface and from a VM image. See the current behavior below before treating optional session provenance as an executable native session source.

Use this when

• Creating a new seat from a known-good starting context.
• Refreshing a seat with rig expand and starter_ref.
• Authoring a new starter (registry entry).
• Inspecting an existing starter's provenance, freshness, or recommended status.
• Promoting / deprecating starters in the registry.
• Composing a starter with a Composable Priming Pack (record manifest id/version, runtime, source session id or transcript path, ready-check evidence, freshness state).

Don't use this when

• You want VM-style deterministic state capture. Starters don't capture VM state.
• You want to copy provider auth material into a starter. Starters refer to session sources and context; they do NOT copy credentials.

What makes a starter valuable

A starter is valuable when it is functional — it carries the context the seat needs to do its task well. Functional is the only measure of a good starter. Size is not: a smaller starter is not a better one, and a bigger one is not worse. Whatever it took for the seat to become genuinely capable at its job is the right starter — 80K tokens or 800K.

Capture the seat as it naturally is at a functional, proven point. Don't pad it with context the seat doesn't use, and — just as important — don't strip context out to make it smaller. Size is an outcome of what the seat needed, never a target.

Never compact, summarize, or shrink a seat in order to make or "lean" a starter. There is nothing valuable in "smaller," and compaction is lossy — you would trade away the exact capability the starter exists to preserve. (Compaction is a separate last-resort step for a seat genuinely near its context limit, with its own before/after plan — never part of capturing a starter.)

Authoring lifecycle — 6 conceptual states

1. Captured — a useful seat/session/context pattern is identified.
2. Named — it becomes an Agent Starter with stable id and owner.
3. Inspectable — runtime, context inputs, session source, and provenance are visible.
4. Used — a rig member or rig expand operation starts from it.
5. Promoted — evidence shows it is recommended for a role or bundle.
6. Deprecated — replaced, stale, unsafe, or incompatible.

Failure modes (5)

1. Overclaiming image semantics — UI/docs imply deterministic VM-style state capture. Say "starter," name what's included, show provenance.
2. Hidden provenance — users can't tell what session, context, or spec a starter came from. Refuse promotion until provenance is inspectable.
3. Stale starter — points at outdated doctrine, missing files, or invalid native session source. Inspect must report staleness honestly.
4. Secret leakage — starter packages or displays provider auth material. Refuse. Refer to session sources and context, never copy credentials.
5. Runtime mismatch — starter used with unsupported runtime. Refuse with a clear error.

Registry entry and current behavior

Save one entry as <registry-root>/reviewer-v1.yaml. The resolver selects an explicit root or OPENRIG_AGENT_STARTER_ROOT; absent those, it checks the home registry ~/.openrig/agent-starters and a configured fallback.

starter_id: reviewer-v1
role: Review the assigned change against its stated outcome.
context: Read the current task and the source needed to judge it.

The current resolver checks the entry shape and credential boundary, then delivers this YAML itself as one required guidance_merge startup file on a fresh start. It does not interpret arbitrary context refs, load a native conversation from this example, or seal an image. A RigSpec member combining starter_ref with session_source.mode: fork is currently rejected; use a separate supported session-source path when native continuity is the outcome.

Member usage:

members:
  - id: reviewer
    starter_ref:
      name: reviewer-v1

When a starter points at a primed session produced from a Composable Priming Pack, record:

• manifest id/version
• runtime
• source session id or transcript path
• ready-check evidence
• freshness state

Proof matrix

Surface	Test type	Authority
Registry schema accepts minimal starter	unit	daemon or config-layer prototype
Inspect shows provenance and included context	unit / snapshot	daemon or CLI
Member can use starter_ref	integration	daemon
Unsupported runtime or stale source refuses honestly	unit + integration	daemon
No secret material copied into starter artifact	grep / fixture	tester
Bundle can include or reference starter	package inspection	bundle layer

Dependencies on other primitives

• Separate path: session-source-fork — native conversation-source continuity; currently not composable with starter_ref
• Firm: specification-system — declarative starter and member references
• Soft: rig-bundles-and-shareable-artifacts — shareable starter packaging
• Soft: context-engineering-and-retrieval — richer declarative context assembly
• Soft: seat-continuity-and-handover — refresh and swap workflows over starters

Required-before-RSI

Agent Starters need queryable provenance and honest inspect output before RSI loops can rely on them for seat refresh. A workflow must be able to answer: "what starter did this seat use, what source session or context was included, and is that starter still recommended?"

See also

• session-source-fork skill — low-level fork primitive that makes native session-based starters possible