Agent Starters

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.