Keep and move your work

You can use Laufwerk now and choose a different runtime later. Your workflows, prompts, tools and checks live in your repository. You operate the storage, and dataset exports are ordinary JSON you can read without a Laufwerk server.

The migration work is explicit: code that calls Laufwerk needs adapting, and another engine cannot automatically resume its suspended runs.

1. Keep the code and starting files

Preserve workflow source, prompts, skills, tools, schemas and checks. Keep any files or external artifacts the process depends on. Ordinary business logic is reusable; identify calls to workflow, Activity, Session, Workspace and Human APIs as the parts a new runner must replace.

2. Export evidence and archive state

From your consumer project:

bunx laufwerk@0.0.1-alpha.14 datasets list --json
bunx laufwerk@0.0.1-alpha.14 datasets snapshot drafts --version 1 --name migration --json
bunx laufwerk@0.0.1-alpha.14 datasets export SNAPSHOT_ID --output ./migration/drafts-v1 --include-logs

Use your dataset name/version and the returned snapshotId. Repeat for other datasets, using separate destinations. Follow nextCursor when listing a large collection. Each export contains a manifest.json with selected examples, records, schemas, provenance and the requested retained logs.

A dataset export is not an installation backup. Also preserve the project storage, normally ~/.laufwerk/state/projects/<projectId>/, including runtime and engine databases, saved bundles and workspaces. Let runs settle and stop writers before copying, or use a consistent backup procedure. Copy external files separately; a recorded URL is only a reference.

Export format and limits explains what is retained and what cannot be reconstructed from it.

3. Run one workflow elsewhere

Start with a script or another engine. Reuse the task logic, prompts and checks; replace Laufwerk calls with your runner's equivalents. Reconnect providers and tools, and implement the saved progress, retries and human waits this workflow actually needs.

Your adapter chooses the original inputs and restores any required files. Historical answers and feedback belong on the evaluation side, so the replacement has to solve the original problem rather than read its answer.

4. Verify before switching

Evaluate representative cases against the same checks and outcomes. Compare quality, time and cost. Route new work to the replacement once it meets your requirements. Finish or reconcile old runs before retiring the old runner; copying its database does not transfer live execution into another engine.

Let better models simplify the process

The README's application of the Bitter Lesson is practical: keep today's prompts, routing rules and agent decompositions open to replacement as models improve. Benchmark simpler alternatives on real inputs, failures, human corrections and verified outcomes. When a simpler approach meets your requirements, remove the workarounds while keeping necessary permissions and business checks.

The lasting investment is your working process and what you have learned from it. The code, cases and evidence help you evaluate the replacement. They do not automatically train a model or guarantee improvement.

You have reached the end of the reading path. Choose a task guide to build or operate your own workflow, or use the API reference while writing code.

← A complete research-and-draft workflow · Back to the reading path →