Agent operating model · Cold start to release

How a New Agent Can Enter Cold and Ship

A capable agent enters with no conversation history, reconstructs authoritative state, accepts one bounded assignment, proves readiness, produces verifiable work, and advances it only to the shipping level its authority permits.

Status · ExplorationVersion · 0.1Platform · RP2350Updated · August 7, 2026

Enter cold

No history or hidden knowledge.

Discover

Reconstruct current authority.

Prove ready

Restate scope and evidence.

Execute

Work inside boundaries.

Verify

Ship code plus proof.

Advance

Reach the authorized level.

01 · Design goal

Institutional memory belongs in the operating system

The repository, Orchestrator, and work-package contract must provide enough context for an unfamiliar agent to discover, execute, verify, and hand off safely.

Cold does not mean unprepared

The agent has no prior conversation, undocumented architecture, remembered decisions, repository familiarity, or implicit authority.

The operating system hydrates it with the smallest sufficient authoritative context. Missing or contradictory context triggers escalation—not inference.

Repository preserves authoritative state.

Orchestrator assembles the assignment.

Work package bounds scope and proof.

Agent executes within authority.

Independent actors verify and integrate.

Humans accept experience and authorize release.

A capable agent should not need institutional memory to contribute safely. The system should make the work resumable by design.

02 · Entry test

Five questions must be answered before modification begins

If even one answer is missing, stale, or contradictory, the valid next action is to stop and route the uncertainty.

1Outcome?

What result is the system pursuing?

2Authority?

What exact work may this agent perform?

3Sources?

Which artifacts are authoritative?

4Boundaries?

What must remain unchanged?

5Evidence?

What objectively proves completion?

03 · Shipping ladder

“Shipped” is an exact state—not a binary claim

Different actors hold different authority. A cold agent may reach S1 or S2 without claiming that the work is accepted, release-ready, or released.

S0ProducedRequired artifacts created locally.

S1VerifiedPackage checks and tests pass.

S2ReviewedIndependent technical review complete.

S3IntegratedMerged into an integration build.

S4AcceptedProduct and technical criteria satisfied.

S5Release-readyManifest, evidence, rollback, risks complete.

S6ReleasedAuthorized artifact distributed.

S7ValidatedTarget or field evidence confirms behavior.

S8LearnedResults routed into the Learning Engine.

04 · Canonical entry

One short file tells every agent how to enter

START-HERE.md is operational navigation—not another competing specification.

It must identify	Operational purpose
Repository identity	Explains what the project is and the active product/platform boundary.
Authority order	States how conflicting instructions are resolved.
Assignment location	Points to the agent's exact active work package.
Health commands	Defines non-mutating checks for repository and environment readiness.
Pre-acceptance permissions	Separates discovery rights from implementation rights.
Role instructions	Locates capabilities, discretion, and escalation responsibilities.
Current state	Links branch, commit, dependency, blocker, and approval records.
Done + shipped	Defines evidence and the exact shipping vocabulary.
Human gates	Names actions that require human authority or judgment.

05 · Bootstrap envelope

Establish identity, assignment, environment, and authority

The first valid action is a readiness assessment. The envelope also fixes the expected branch, commit, board profile, autonomy ceiling, and stop conditions.

Minimum cold-start package

The Orchestrator creates a precise envelope for one run and one package.

Agent role and run identity
Package and source version
Repository and toolchain state
Target hardware profile
Maximum shipping level
Immediate stop conditions

agent_bootstrap:
  id: BOOT-WP-LIFECYCLE-CORE-003
  identity:
    run_id: RUN-2026-08-07-041
    role: gameplay-platform-engineer
  assignment:
    work_package: WP-LIFECYCLE-CORE-003
    package_version: 1.2
    authorized_commit: 8f31c2a
  repository:
    branch: change/game-lifecycle
    clean_worktree_required: true
  environment:
    target_board: adafruit-feather-rp2350-hstx
    build_profile: non-psram-release
  autonomy:
    maximum_ship_level: S1
    may_commit: true
    may_merge: false
    may_release: false
  first_action: readiness-assessment
  stop_conditions:
    - expected-head-mismatch
    - missing-authoritative-artifact
    - public-contract-change-required

06 · Context hydration

Deliver the smallest sufficient authoritative context

Each item is labeled by authority, requirement, purpose, version, and digest. Informative material never silently overrides a source of truth.

L0Entry

START-HERE and authority order.

L1Assignment

Work package and role contract.

L2Intent

Change brief and experience outcome.

L3Specification

Approved behavior and requirements.

L4Boundaries

Protected paths and public contracts.

L5Implementation

Relevant code, interfaces, standards.

L6Evidence

Tests, budgets, target procedure.

L7History

Only relevant ADRs and exceptions.

L8Current state

Branch, dependencies, active blockers.

07 · Precedence

Competing instructions resolve deterministically

When two artifacts at the same level conflict, the agent creates a contradiction report instead of choosing the newer-looking or more convenient path.

Law, safety, organizational policy

Governance and authority records

Approved strategy and change authorization

Approved specifications and public contracts

Work-package boundaries

Role instructions and repository conventions

Implementation plans

Informative documentation

Conversation, comments, historical notes

Agent assumptions

08 · Discovery mode

Permission to inspect comes before permission to implement

Cold entry begins as a non-mutating assessment of repository health, relevant code, dependencies, contracts, and version consistency.

Discovery may

Read designated repository artifacts
Inspect branch, status, code, and tests
Run non-mutating environment checks
Compare referenced versions and commits
Report missing or contradictory context

Discovery must not

Edit files or generated artifacts
Install dependencies or change toolchains
Reformat or clean unrelated code
Create unapproved architecture
Contact external services without authority

09 · Readiness declaration

Restate the assignment before touching code

The Orchestrator validates the agent's objective, inputs, allowed changes, protected boundaries, planned verification, dependencies, assumptions, and shipping ceiling.

Readiness is a gate

A misunderstanding caught here is cheap. A misunderstanding discovered after implementation is rework—or a governance failure.

Objective in outcome language
Exact source versions
Allowed and protected paths
Verification plan
Explicit assumptions
No unresolved uncertainties

agent_readiness:
  run_id: RUN-2026-08-07-041
  work_package: WP-LIFECYCLE-CORE-003
  status: ready
  understood_objective: >
    Implement reusable Start, Pause, and Resume
    without changing scoring or public audio APIs.
  allowed_changes:
    - platform/lifecycle/**
    - tests/platform/lifecycle/**
  protected_boundaries:
    - games/sock-rescue/scoring/**
    - platform/audio/public/**
  planned_verification:
    - lifecycle-unit-tests
    - conformance-suite
    - memory-budget-check
  uncertainties: []
  maximum_ship_level: S1

10 · Trust ramp

Autonomy expands through evidence—not confidence

The package contract determines what the agent may do at every phase of the run.

Discover

Read and inspect.

Prepare

Plan and define tests.

Implement

Modify allowed files.

Validate

Produce reproducible evidence.

Commit

Create bounded commit.

Recommend

Prepare resumable handoff.

Integrate

Only when authorized.

Ship

Only to permitted level.

Scope boundary

Does the change implement only the authorized outcome?

Repository boundary

Are every modification and artifact inside permitted paths?

Decision boundary

Is the agent executing an approved choice—or making a new consequential one?

Package + commit remain current

No unexplained worktree changes

Public contracts preserved

Resource budgets satisfied

Evidence matches current build

New uncertainty recorded

Stop conditions re-evaluated

Human decisions remain valid

11 · Decision authority

Agent autonomy is not agent authority

Implementation discretion is broad inside the package. Product meaning, public interfaces, shared commitments, risk, and release remain governed.

Decision	Default authority
Private names and local techniques	Agent decides within standards.
Additional package-level tests	Agent decides.
In-scope bug	Fix when covered by authorization.
Out-of-scope bug	Record and route.
Public interface change	Stop and request approval.
Behavior-changing interpretation	Stop and clarify.
New dependency	Request approval.
Platform capability promotion	Recommend only.
Risk or experience tradeoff	Human decision and judgment.
Release authorization	Human or explicitly delegated authority.
Another agent's active package	Orchestrator coordination required.

12 · Evidence

Every package ships proof—not just code

Facts, interpretations, assumptions, recommendations, limitations, and remaining risks are separated so the next cold actor can independently assess the claim.

Implementation

Tests

Test results

Build metadata

Scope diff

Resource measurements

Assumption report

Open findings

Limitations

Handoff

Evidence bundle

Every completion claim is bound to one package, one run, one base commit, and one result commit.

Unauthorized files: zero
Public contract unchanged
Tests and conformance pass
Memory within budget
Target limits stated
Exact shipping level claimed

evidence_bundle:
  id: EVID-WP-LIFECYCLE-CORE-003
  source:
    base_commit: 8f31c2a
    result_commit: 42db7e1
  changes:
    files_modified: 6
    unauthorized_files: 0
    public_contract_changed: false
  verification:
    unit_tests: pass · 34 cases
    conformance: pass
    memory: 2816 / 4096 bytes · pass
  limitations:
    - target-board verification not included
  claims:
    achieved_ship_level: S1
    recommended_next_level: S2

13 · Independent verification

The implementer cannot be the sole consequential authority

Reviewers receive the original requirement and evidence—not only the implementing agent's summary.

Fidelity

Matches approved behavior?

Scope

Only authorized areas changed?

Correctness

Tests cover meaningful cases?

Compatibility

Consumers remain supported?

Performance

Timing and memory pass?

Target behavior

Works on RP2350 profile?

Experience

Feels and appears intended?

Traceability

Claims map to evidence?

Reproducibility

Another actor can repeat it?

Maintainability

Platform boundaries preserved?

14 · Resumable handoff

The next cold agent should continue without an interview

A formal handoff records what changed, what stayed unchanged, achieved shipping level, exact evidence, remaining work, risks, and a reproducible resume command.

Implementer reaches S1

Evidence bundle sealed

QA enters cold

Reproduces verification

Advances to S2

Formal handoff artifact

The first agent can disappear without losing the ability to continue.

Delivered commit and evidence
Changed and protected behavior
Known risks and limitations
Next responsible role
Exact resume instructions

agent_handoff:
  work_package: WP-LIFECYCLE-CORE-003
  status: package-verified
  delivered:
    commit: 42db7e1
    evidence: EVID-WP-LIFECYCLE-CORE-003
    achieved_ship_level: S1
  unchanged:
    - public lifecycle interface
    - scoring, audio, input mapping
  remaining:
    - independent review
    - integration + target validation
    - experience acceptance
  next_actor: qa-engineer
  resume: ./tools/verify-package WP-LIFECYCLE-CORE-003

15 · Integration + humans

Package success is not system success

Integration checks compatibility, concurrency, contracts, resources, exact build identity, exception validity, and the relationship between requirements and system-level evidence.

Product acceptance

Outcome matches intended behavior.

Experience judgment

Technically correct behavior feels right.

Creative acceptance

Visual and audio character is coherent.

Architecture approval

Shared and public boundaries hold.

Platform commitment

Ongoing compatibility is accepted.

Risk acceptance

Residual exposure has an owner.

Hardware confirmation

Physical assumptions are validated.

Release authority

Distribution is explicitly permitted.

Exception approval

Deviation is bounded and expiring.

Continuation choice

Evidence justifies further investment.

16 · Release gate

Authorize the exact candidate—not an approximate state

Approval binds to version, commit, artifact digest, hardware profile, evidence, exceptions, and accountable roles. A material candidate change invalidates the gate.

Release-ready means complete

Every prerequisite must refer to the same candidate build.

SpecificationsAutomated testsIntegration testsTarget validationExperience reviewCompatibilityResource budgetsRelease notesRollback planValid exceptions

release_gate:
  id: REL-RP2350-0.5.0
  candidate:
    version: 0.5.0
    commit: 6e08a4c
    artifact_digest: sha256:...
    hardware_profile:
      feather-rp2350-hstx-rev-b-non-psram
  exceptions:
    - id: EXC-AUDIO-003
      approved: true
      expires: 0.6.0
  authorization:
    product_owner: approved
    technical_owner: approved
    release_owner: approved
  decision: release

17 · RP2350 example

A cold agent implements Start, Pause, and Resume

The example shows exactly how technical work advances from unfamiliar entry through package verification, escalation, integration, human acceptance, and release.

Read START-HERE

Confirm branch + commit

Load lifecycle spec

Declare readiness

Implement + measure

Escalate contract gap

Ship to S1

Authorized execution

Implement internal lifecycle state machine
Add state-transition tests
Guard state mutation while paused
Run lifecycle conformance
Measure code and data memory
Record exact commit and toolchain

Stop-condition example

The public interface cannot distinguish first start from resume. The agent must not invent a method.

Record public-contract-change-required
Offer internal, contract, and requirement options
Block lifecycle implementation only
Continue safe test-fixture preparation
Await Architect + Engine Steward resolution

Implementer reaches S1 → QA reaches S2 → Integration reaches S3 → Human acceptance reaches S4 → Release authority reaches S6.

18 · Failure modes

Every cold-start failure points to a system correction

Agent confusion is evidence that navigation, context, authority, evidence, or learning retention needs improvement.

Failure mode	System correction
Agent asks what the project is	Improve START-HERE or the bootstrap envelope.
Agent reads irrelevant material	Improve dependency-based context assembly.
Agent invents requirements	Strengthen decision boundaries and stop conditions.
Agent changes unrelated files	Enforce path scope and diff validation.
Tests pass but experience fails	Add human experience evidence to acceptance.
Build cannot be reproduced	Lock toolchain, board profile, and environment.
Reviewer must interview implementer	Improve the evidence and handoff contracts.
Agent relies on old chat	Move authoritative content into the repository.
Package work is called released	Enforce shipping-level vocabulary.
Earlier mistake repeats	Route learning into specs, tests, or instructions.
Approval targets wrong commit	Bind authority to versions and digests.
Requirements change mid-run	Propagate invalidation and reassess readiness.
Every agent needs onboarding	Improve repository self-description.
Conflict is silently resolved	Enforce contradiction escalation.
Agent performs broad cleanup	Prohibit incidental scope expansion.

19 · Measures

Measure whether cold entry truly works

The target is less explanation, better readiness, precise scope, complete evidence, reproducible handoffs, and accurate shipping claims.

Orientation time

Entry to valid readiness declaration.

Context precision

Required context used versus delivered.

Readiness accuracy

Misunderstandings caught before edits.

First-run success

Completion without re-onboarding.

Scope discipline

Runs without unauthorized changes.

Escalation quality

Stop conditions recognized correctly.

Evidence completeness

Acceptance without reconstruction.

Handoff resumability

No predecessor interview required.

Reproducibility

Independent actor repeats results.

Shipping accuracy

Claims match achieved state.

Human burden

Time deciding versus explaining.

Learning retention

Known failures avoided next time.

Cold-Start Success Ratecold runs reaching authorized level without re-onboarding / eligible cold runs

Handoff Independencehandoffs completed without synchronous clarification / total handoffs

20 · Complete contract

Cold entry becomes safe, governed shipment

Every transition requires current repository state, approved scope, required evidence, and the independent or human authority appropriate to the next shipping level.

Cold

Discovering

Ready or escalated?

Executing

Self-verified

Independent verification

Integrated

Human acceptance

Release-ready

Released → validated → learned

A cold agent may ship only to the level explicitly authorized by its package—and only when current state, bounded scope, evidence, independent checks, and applicable human decisions support that exact claim.

21 · Repository design

Make every run discoverable, resumable, and auditable

Agent entry, readiness, assignments, evidence, shipping state, approvals, exceptions, and playbooks live beside the product and platform work they govern.

From conversation-assisted intent to repository-native execution

Conversation may originate intent, but no conversation history is required to execute safely.

Priority artifacts: START-HERE, Bootstrap Schema, Readiness Schema, Authority Policy, Shipping Policy, Evidence Bundle, Handoff Schema, and Release Gate.

START-HERE.md

agents/
├── charter/agent-operating-contract.md
├── roles/
├── bootstrap/{active,completed}/
├── readiness/{pending,accepted,rejected}/
├── evaluations/
└── templates/{bootstrap,readiness,handoff}.yaml

orchestration/
├── state/  ├── assignments/
├── work-packages/  ├── context/
├── escalations/
└── shipping/
    ├── produced/  ├── verified/
    ├── integrated/ ├── accepted/
    └── released/

evidence/{package,integration,target,experience,release}/

governance/
├── authority-order.md
├── autonomy-policy.md
├── shipping-policy.md
├── approval-policy.md
└── invalidation-policy.md

releases/{candidates,manifests,approvals,exceptions,published}/

playbooks/
├── enter-repository-cold/
├── assess-agent-readiness/
├── execute-bounded-package/
├── verify-independent-work/
├── integrate-change/
├── prepare-release/
└── recover-agent-handoff/