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.