Pause, restart, rollback
Lifecycle actions for when something needs to stop, restart, or revert. What each does, when to use it, what’s reversible.
The actions, in order of severity
| Action | Effect | Reversible? | When to use |
|---|---|---|---|
pause | Stops agents from running. State preserved. | Yes (resume) | You need to think; the company shouldn't keep acting on stale direction. |
resume | Brings a paused exocorp back online. | — | After pause, when you're ready to continue. |
update | Applies a newer release version. | Yes (rollback) | When a release on your channel has features or fixes you want. |
restart | Restarts from last successful provision. | Yes | Transient issue; the previous-known-good state was fine. |
reprovision | Full rebuild from current draft. | Yes | Runtime needs a fresh rebuild but configuration is correct. |
rollback | Reprovisions from a specific historical job. | Yes (forward roll) | An update caused a regression and you need to go back. |
stop | Halts the runtime. Portal becomes unreachable. State preserved. | Yes (restart) | Long-term hibernation; you don't need the portal. |
destroy | Removes the deployment entirely. | No | You're done with this exocorp permanently. |
Pause: the soft halt
Pause is the right first move when something feels wrong and you need time to think. Agents stop running. New work isn’t admitted. But the operator portal is still reachable, you can still see what the company was doing, you can still talk to the CEO. Pausing requires a reason text — it’s recorded in the audit trail.
Use pause when:
- The company is producing work you don’t want and you need a moment to figure out what to change.
- A budget alert needs investigation before more spending happens.
- You’re traveling, on vacation, or otherwise can’t respond to approvals for a stretch.
Resume brings the company back. Reason on resume is optional. The whole pause/resume cycle is reversible and leaves a clean trail.
Restart vs. reprovision vs. rollback
These all bring a stopped or broken runtime back, but they reach different historical points.
- Restart — Uses the last successful provision. Fastest. Use when the runtime broke transiently and the prior state was fine.
- Reprovision — Builds the runtime fresh from your current configuration draft. Slower. Use when restart isn’t producing a working runtime but configuration is right.
- Rollback — Reprovisions from a specific past provision job. Use when a recent update caused a regression and you need to go back to a known-good version. You specify which job to roll back to.
All three require you to type the exocorp’s slug to confirm — deliberate friction so a misclick doesn’t restart your production runtime. They’re all run from the company detail page on the platform dashboard.
Stop and destroy
Stop halts the runtime entirely. The operator portal goes unreachable. State stays in the database; nothing is deleted. Restart brings it back. Use stop when you’re confident you won’t need the exocorp for a stretch and want to save compute.
Destroy is permanent. The deployment is removed entirely. Before destroying, the company’s work and memory should have been wound down properly — promises closed, important knowledge exported, the operator notified of remaining state.
Common errors
- Already provisioning — You can’t restart or reprovision an exocorp that already has a provision in flight. Wait for it to settle.
- Missing model price book — Some actions need an active model price book. The error tells you which.
- Release lookup failed — Update or rollback can fail if the target release version isn’t resolvable. Check the release catalog for the version you wanted.
- Already running — Resume returns an error if the exocorp wasn’t paused.