Run your first customer pilot
Turn a checked workflow into a supervised process you can operate.
Start with one bounded job, a disposable copy of its inputs, and a person who can review the result. For example: propose a small code change, run the project's existing tests, then let a maintainer approve the diff. Keep publishing, merging and customer communication behind that approval until you have evidence for automating them.
The published release is alpha.6 on the documented Ubuntu setup. Native local execution and Docker are in the alpha.7 source preview. A green platform CI run does not verify subscription login on your friend's machine. Laufwerk remains an alpha; read the current capabilities, licensing and limits before customer adoption.
Define success before the agent runs
Write down the input, allowed changes, acceptance check and destination of the result. Keep the acceptance check outside the agent's editable files when possible. A generated test can add coverage, but should not replace the checks you supplied.
For a code-change pilot, require all of these:
- The existing test suite passes, including a regression for the requested behavior.
- The diff stays within the intended files and preserves existing functionality.
- A reviewer inspects the change before it reaches the customer.
- A failed check stops publication or write-back.
Use human decisions when approval belongs inside the workflow. Approval is an explicit step you implement; Laufwerk does not automatically add it to arbitrary workflows.
Exercise the failure path too
Before using real customer inputs, deliberately give the workflow a failing verification command. Confirm that the destination stays unchanged. Then interrupt a disposable run and use Inspect and debug to understand its recorded state.
For an external action such as creating a ticket, use a stable request identity and retain the external receipt. If the process stops after sending the request but before recording its result, check the external system before retrying. A new execution key starts new work and can duplicate an earlier action; it is not a recovery mechanism.
Managed working copies help separate candidate edits from source files. Local direct mode edits immediately, and host-side tools can have effects outside a working copy. Choose the execution mode to match the job rather than assuming every tool is isolated.
Keep enough evidence to decide
For each pilot attempt, record the run ID, exact package versions, execution mode, source revision, acceptance result and review decision. Use the CLI's timings command to separate setup, agent work and verification. Include failed and repaired attempts in the record.
Compare equivalent tasks and checks. Report first-time image preparation separately from warm runs. Three successful demonstrations are useful evidence for those tasks; they do not establish an uptime target or a general model-quality score.
Raw runtime records and transcripts can contain customer data, authentication material or private resume state. Share a sanitized error and minimal reproduction with support, rather than uploading the state directory.
Give the pilot an owner
Someone needs to notice pending approvals, expired provider login, failed verification and uncertain operations. Start with supervised runs. Add a persistent service only when you have defined who checks its status and how it stops accepting new work during maintenance.
Pin the CLI and consumer packages to the same exact release, and retain the lockfile. Keep the project's identity and existing workflow bundles across upgrades. Do not regenerate the project to make an old error disappear.
Runtime state lives outside the source checkout, under ~/.laufwerk/state by default. A Git backup alone is insufficient. For a consistent offline backup, first stop all processes using that state, then preserve the state directory along with the consumer configuration and source. Protect that backup as sensitive data. It does not include external services or guarantee recovery of a running sandbox; unresolved actions still need inspection. Restore rehearsal belongs on an isolated host with no production queue worker running.
Expand after the pilot earns it
Start another use case when the current one produces useful results, rejects known bad results, and has a recovery path you have actually exercised. Increase scope one step at a time: more inputs, then unattended scheduling, then narrowly defined automatic publication. Keep human review where your checks cannot establish correctness.