68 lines
3.6 KiB
Markdown
68 lines
3.6 KiB
Markdown
# Creation-owned Automation runtime placement
|
|
|
|
## Outcome
|
|
|
|
The surface that creates an Automation owns its execution placement for the
|
|
Automation's lifetime:
|
|
|
|
- Desktop creation produces a `desktop` Automation and continues to use the
|
|
authenticated desktop runner introduced by the existing Automations work.
|
|
- Web and Cloud Chat creation produce a `cloud` Automation. Den schedules the
|
|
occurrence, wakes the owner's existing OpenWork Cloud container when it is
|
|
stopped, and runs a native OpenWork thread headlessly inside that container.
|
|
|
|
Both surfaces read the same Den Automation and run history. Placement is shown
|
|
on list cards and receipts, but it is not an editable setting. Moving execution
|
|
between Desktop and Cloud requires creating a new Automation on that surface.
|
|
|
|
## Cloud lifecycle
|
|
|
|
A Cloud agent run reserves and persists its worker, workspace, native thread,
|
|
and deterministic user-message identity before it submits the prompt. Lease
|
|
recovery reattaches to that thread and observes-or-submits that exact message
|
|
instead of starting duplicate work. Den heartbeats the run while it waits,
|
|
requires an observed idle state after forwarding cancellation, records native
|
|
assistant/tool events and usage, and keeps active Cloud runs out of idle-stop
|
|
selection. Run deadlines include container wake-up and request admission.
|
|
|
|
Cloud creation requires the current owner to have an existing per-user Cloud
|
|
worker and an authorized model. It does not silently allocate a new Cloud
|
|
environment. A stopped worker is valid and is woken at execution time; a
|
|
missing or failed runtime is recorded as a durable failure and moves the
|
|
Automation to needs-attention. Timeouts are terminal receipts rather than
|
|
automatic retries because an agent may already have produced external side
|
|
effects; the user can inspect the native run and choose Run now explicitly.
|
|
Runtime readiness polling retains its pre-existing 120-second cap and terminal,
|
|
non-retryable outcome; signed-preview routing does not add another queued attempt.
|
|
|
|
Before prompt admission, Den probes and repairs the worker's persisted
|
|
`openwork-cloud` MCP registration for the selected model. A missing Connect
|
|
configuration or model projection becomes durable needs-attention rather than
|
|
a headless run that silently lacks the user's connected services.
|
|
|
|
The native thread client uses both the collaborator token and the internal
|
|
host credential when it talks directly to the resolved Cloud runtime. No provider
|
|
credential or worker token is copied into the Automation receipt.
|
|
|
|
## Relationship to Workflow Automations
|
|
|
|
Workflow Automations from the Workflow Artifacts work remain Cloud-owned
|
|
and keep their existing Den Code Mode executor. This feature adds ordinary
|
|
agent actions as a second Cloud execution kind; it does not change Script
|
|
snapshot validation or artifact result retention.
|
|
|
|
## Verification boundary
|
|
|
|
Focused tests cover the Cloud-only MCP creation contract, deterministic prompt
|
|
admission, terminal errors, cancellation observation, dual worker credentials,
|
|
Cloud wake/idle lifecycle behavior, runtime-specific agent guidance, and
|
|
cross-surface execution labels. Den Web provides once/daily/weekly create and
|
|
edit flows plus activate/deactivate, archive, run-now, cancel, native thread,
|
|
usage, and event receipt controls. The testkit acceptance tape covers the
|
|
Web/Desktop creation language and verifies that no placement picker is exposed.
|
|
|
|
The deployment-shaped Daytona journey—stop a real user's container, let a due
|
|
occurrence wake it, execute against live model and Connect configuration, then
|
|
observe idle shutdown again—remains required for the production rollout and
|
|
merge decision. It is intentionally not claimed by local or mocked proof.
|