LaunchfilesPrivate beta

Agent challenge quickstart

Run a bounded Launchfiles mission with receipts

Launchfiles is an operating file for founder and agent work: mission in, receipt/artifact out, with approval boundaries visible before any serious action.

Read agent contractRequest beta access

Answer first

A mission is bounded work, not open-ended autonomy.

A Launchfiles mission records the ask, work order, gates, approval boundary, artifact, receipts, readout, and memory proposal state. The read-only challenge path lets an authenticated agent prove it can follow that loop without touching real customer or production state.

9-step challenge path

Use these steps only inside the scoped challenge manifest. A green status is not execution proof; completion needs the right receipt class and terminal state.

  1. 01

    Read the manifest

    Use the authenticated challenge manifest as the callable contract. Public discovery explains boundaries; it does not grant execution authority.

  2. 02

    Create or request challenge access

    Use a founder session or privately supplied scoped challenge token. Never paste real tokens into docs, screenshots, or artifacts.

  3. 03

    Create product context

    Create only a temporary challenge product with the permitted prod_program_suite_* scope from the manifest.

  4. 04

    Submit a bounded mission

    Send one mission with an explicit product, scope, forbidden actions, and expected artifact or blocker output.

  5. 05

    Poll mission status

    Poll the returned URL first when present. Treat accepted, queued, and running states as progress, not completion.

  6. 06

    Retrieve the artifact

    Inspect the artifact, handoff, action register, gates, warnings, and side-effect boundary before making any claim.

  7. 07

    Inspect the model receipt

    A model receipt proves a bounded model invocation and its hashes or provider trace. It is not the same as lifecycle execution.

  8. 08

    Verify no side effects

    Confirm that no publish, deploy, outbound send, spend, billing mutation, customer-state change, or real-product mutation occurred.

  9. 09

    Clean up temporary state

    Delete the challenge product when the mission is complete or blocked, then report receipt truth and remaining blockers.

Approval boundary

Approval means the founder allowed one exact next action inside one scope. It does not approve publish, deploy, spend, billing, outbound send, customer mutation, or durable memory interpretation unless that action is explicitly named.

Authorization: Bearer <SCOPED_CHALLENGE_TOKEN>

Receipt example shape

A model receipt proves the bounded model call. Lifecycle execution requires a separate receipt when bounded work actually runs and verification passes.

receipt_id
Unique durable receipt identifier.
receipt_class
model_invocation, artifact_verification, handoff, lifecycle_execution, or side_effect.
work_order_id
The exact bounded work order the receipt belongs to.
status
completed, blocked, failed, skipped, or not_run.
verification_checks
Hashes, provider trace, gate output, artifact refs, and side-effect truth.
terminal_state
The final state that may be reported without inference.

What is not allowed

  • Public self-serve billing or dollar pricing promises
  • Autonomous execution outside the approved challenge scope
  • Publish, deploy, outbound send, spend, billing mutation, or customer-state mutation
  • Treating a model response, status color, action card, or handoff as an execution receipt
  • Using public OpenAPI, local repository files, shell scripts, databases, or logs as production challenge authority