Skip to content
Mimic Docs

Workflow Packs

Use Workflow Packs to manage runtime packaging and release state for worker automation.

What this surface controls

  • Pack identity (name, slug, family metadata)
  • Draft runtime bundle state
  • Published versions and stage promotion
  • Installation records and pinned version per environment/site

Open /app/workflow-packs to browse packs. Open /app/workflow-packs/{id} to manage one pack.

Standard operator flow

  1. Ensure or reopen a pack from a worker key.
  2. Deploy a draft to a target agent for validation.
  3. Publish draft to a version (internal_verified, pilot, or production).
  4. Promote versions through stages after review.
  5. Create installations and pin each installation to a version.
  6. Roll back installation if validation fails.

Builder integration

Builder deploy can attach workflow-pack context:

  • workflowPackId
  • workflowPackVersionId
  • workflowPackInstallationId
  • runtimeBundleId
  • runtimeBundleManifestKey

This keeps VM execution, run evidence, and release lineage linked.

VM draft publish flow

Use the two-step transport for VM-origin draft updates:

  1. Call POST /api/workflow-packs/{id}/publish-from-vm/upload to receive uploadUrl + uploadKey.
  2. Upload the source zip directly to S3 with the presigned URL.
  3. Call POST /api/workflow-packs/{id}/publish-from-vm/finalize with uploadKey, base draft identifiers, and file inventory.

Use legacy POST /api/workflow-packs/{id}/publish-from-vm only for compatibility with older VM scripts.

Guardrails

  • Packs and installations are organization-scoped.
  • Draft publishing uses conflict checks to prevent overwriting moved draft heads.
  • Use pinned versions for predictable production behavior.
  • Keep RPA-first selectors as baseline; use model fallback only for non-deterministic edges.