After the Task Moves to the Cloud: Engineering Open Nua Cloud Agent Runtime

Open Nua Engineering

Putting an Agent on a server, calling a model, running tools, and streaming a response is a straightforward starting point. The harder questions come next. Who keeps the task running when the user leaves? Can a timed-out request be sent again? Which instructions should yesterday’s conversation use after an upgrade? What happens if authority is revoked while a task waits for human input?

The answers determine whether a Cloud Agent Runtime can become a dependable part of a product.

In decoupling execution from clients, we described how desktop work stopped depending on a particular window. Moving execution into an independent Runtime takes that boundary further: clients can leave while the execution service owns the task; processes can be replaced while confirmed facts remain.

This article explains the engineering choices behind that responsibility chain, from delivery and admission to execution and recovery.

Give each fact an owner

A convenient early design puts login, model proxying, session connections, scheduling, and sandbox management in one service. Later, every restart, scaling decision, or authorization change touches the entire chain.

We separated these responsibilities:

A client expresses intent and displays results. The Host presents a consistent session. The Supervisor manages execution. The Gateway checks authority as calls cross access boundaries.

The diagram groups durable state to emphasize that it cannot live only in process memory. Ownership remains distinct: session projections rebuild the interface, job events describe execution, and checkpoints continue computation. None replaces the others.

This lets identity and model services avoid becoming long-running task schedulers. A client connection no longer determines a Worker’s lifetime. The execution service and its infrastructure must still be available: independence from a window is not independence from an operating environment.

Deliver a definite set of execution inputs

If instructions, tool permissions, or dependencies change halfway through a task, “resume” loses its meaning.

Open Nua now uses Plugins as the delivery source for new Cloud Agents. A Plugin fixes instructions, selected Skills, service declarations, access policy, and dependencies. The workspace separately configures the model, execution identity, tool connections, credential references, and resource limits. The platform verifies the pinned package version and digest, then creates an execution snapshot.

Two kinds of change remain distinct:

• Changing instructions, declared permissions, or packaged dependencies requires a new Plugin version.
• Changing the deployed model, identity, or limits creates deployment configuration that the platform validates again.

A stable release entry points to the current version. Existing sessions retain their bound snapshots. Publishing affects subsequent new sessions; it does not replace instructions or versions in old history. A rollback changes subsequent selection without erasing past execution.

We tested upgrade, rollback, and upgrade again with the feedback assistant, then checked the version and digest recorded by each run. That is stronger evidence than a working version selector: it establishes that the release entry and execution history represent different facts.

Acceptance and completion happen at different times

When a client receives no response, a request may not have arrived, may have been rejected, or may have been durably accepted before its response was lost.

Treating every case as “execution failed; try again” can create a second execution in the last case.

Admission therefore needs a stable identity. The platform assigns an idempotency key to a logical command, and the Runtime persists the corresponding job and receipt. Retransmission first recovers the original result. The same key is not permission to submit different content.

Accepted means the system has taken responsibility for the work. It does not mean the model succeeded, every tool succeeded, or a business result was delivered. Execution events, task status, and application writeback still follow.

When the receipt cannot yet be confirmed, we retain that uncertainty and keep the original identity while querying or replaying the controlled command. This does not make arbitrary tools safe to retry. Sending a message or changing a ticket still needs application-level idempotency and reconciliation. Deduplicating Runtime admission does not guarantee exactly-once external effects.

Reconnection, recovery, and retry need different rules

These operations often hide behind one Retry button, but they change different layers of state.

Client reconnection restores an observation position. The Host rebuilds messages, tools, pending input, and execution progress from durable session state and events. The client should not restart a task or send another user message just to restore the page.

Worker recovery replaces a process. The Supervisor retrieves the original job, checks checkpoint compatibility, obtains current ownership, and continues with a new attempt. An old process ID has little value here. The original job, snapshot, checkpoint, and elapsed budget matter.

Explicit retry is a new execution decision. It needs admission and a relationship to its source. It cannot masquerade as a transport retransmission or assume that previous business writes should run again.

This is why a conversation ID alone is insufficient. A Session identifies the ongoing work, an execution identity identifies an admission, and an Attempt distinguishes the process attempts carrying it out. Changing the observer, replacing a process, and starting work again should leave different records.

Recovery also has limits. A checkpoint preserves resumable computation; it cannot rewind the outside world. Incompatible state must block recovery. An uncertain side effect needs reconciliation, not a rerun that hides the uncertainty.

Taking over a job must fence out the old owner

Saving jobs in a database does not solve recovery on its own. An old Supervisor may temporarily lose contact, a new one may take over, and the old process may return and try to write results.

We constrain this with durable ownership, leases, and an increasing epoch. State writes carry the current owner and epoch. After takeover, stale values cannot commit new state. If a heartbeat cannot establish continued ownership, the running side stops its execution.

Recovery does not restore a fresh time budget either. The original absolute deadline remains in force. Waiting for human input or replacing a Worker cannot extend the task indefinitely.

Rejecting a stale database write does not retract a request already sent to an external service. Ownership, controlled proxies, and application idempotency must work together. Existing recovery and revocation tests establish specific control paths; concurrent failures, loss of connectivity, and cleanup timing still need broader coverage.

The initiator is not the source of authority

A background Agent might be created by an administrator, triggered by a business event, and then run independently. Reusing its creator’s account would silently give it the administrator’s access.

Open Nua distinguishes three identities:

• The Principal determines authorization, resource ownership, and usage attribution.
• The Initiator records the person or event that caused the work.
• The Workload identifies the Agent version, configuration digest, and runtime instance actually executing it.

Causation does not grant permission. An independent Agent Principal needs its own grants and does not inherit its creator’s access to private Plugins.

Short-lived execution authority binds the Principal, workspace, snapshot, model, and resource limits. Admission checks it, and renewal and recovery check current authority again. Waiting for human input is no exemption: an answer can resume work only while that work remains authorized.

Credentials have different boundaries depending on their use. For controlled remote-tool proxying, deployment stores a credential reference; the Gateway validates the call context and injects authentication. That path does not hand the long-lived secret to the model or Sandbox. Capabilities that inject credentials into an execution environment have a different exposure boundary and need separate authorization and controls. The proxy guarantee must not be generalized to every execution path.

Revocation can deny subsequent authorization and calls and drive execution toward a stop. It cannot undo an operation already accepted by an external service.

Computation, files, and deliverables have separate persistence contracts

Persistence is another word that can promise too much.

A checkpoint can continue computation without guaranteeing that every Sandbox file was saved. When workspace persistence is enabled, saves occur at explicit execution boundaries; abnormal termination can lose uncommitted file changes. Recovery follows the committed workspace record, not an arbitrary “latest snapshot” in storage.

An Artifact delivered to a user is a separate resource. It must be explicitly published, registered with a durable reference, and authorized again when downloaded. A temporary sandbox directory cannot serve as a permanent download address. Even a completed task needs separate checks that publication succeeded and the bytes can actually be retrieved.

These distinctions make each promise precise: whether the page can be rebuilt, computation can continue, files have been saved, and a user can take the result away.

Use the feedback assistant to test the platform’s boundary

The feedback assistant connects these contracts in a concrete workflow. The application receives feedback and attachments and assembles the context the Agent may use. Cloud Runtime generates internal analysis and a reply draft. The result returns to the application for human review and publication to the reporter.

The Plugin owns Agent instructions, and the Runtime owns execution. The feedback application keeps its tickets, triggers, dispatch idempotency, review, and public replies. Adding a cloud Agent did not move the feedback domain into the Runtime.

We exercised this chain with the maintainer’s synthetic feedback, including real model calls, draft writeback, review, and reading the published reply back. The assistant currently establishes that the delivery chain works. It does not yet provide complete evidence-based investigation, linkage to existing issues, and sustained follow-through. Background automatic consumption remains disabled.

That is a useful acceptance result. Working infrastructure and a useful application have separate completion criteria. The next step is to develop real investigation and handling capabilities around feedback work, while keeping ticket rules in the application that owns them.

What the evidence supports today

The implementation supports an independent execution service, pinned delivery, durable sessions and jobs, human input, controlled recovery, authorization, and execution visibility. We verified the principal workflows in the maintainer’s actual client and service environment, with automated tests and controlled failure scenarios providing additional evidence.

This is not evidence of large-scale multi-tenant production operation. Cross-tenant workspace-backup isolation, long-task budget governance, further failure timings, and sustained operations still require work. Some client timeout behavior also remains under investigation. Passing tests and a successful business chain cannot stand in for those scopes.

Our understanding of a Cloud Agent Runtime has become more concrete: it must preserve that work was accepted, which version it uses, who authorizes it, where it stopped, and which outcomes remain uncertain.

Models and clients can keep changing. Clear ownership of these facts gives applications a dependable foundation for building their own Agent products.