How coding agents become durable worker jobs

An app.nz coding agent task looks like a prompt in the UI, but the system treats it like a durable job. That is the only sane way to run long-lived code work: enqueue it, lease it, execute it on a worker, stream events, store artifacts, and make retries explicit.

The task is not the process. The task is the record of intent.

From prompt to job

When a user creates an agent task, app.nz stores the task row and also creates worker job payload. The payload contains the repo, branch, prompt, provider choices, machine hints, and any auth context needed by the worker bridge.

The worker job is what a remote runner leases. That lease boundary matters because the browser request should not stay open while a machine provisions, clones a repo, edits files, runs tests, and opens a PR.

Provider routing for workers

Agent execution can run in different places:

• local container path for development or packed workers,
• Hetzner CPU machines for ordinary coding tasks,
• RunPod machines for tasks that need GPU or special capacity,
• external agent backends through the bridge.

The bridge maps app.nz provider and machine selectors into the server type the worker runtime understands. That keeps the product UI stable while the execution backend changes.

Event stream versus final artifact

Agent users need live feedback: clone started, model thinking, file edited, test running, command failed, diff ready. Those are events. But events are not the final result.

The final result needs durable artifacts:

• task status,
• generated diff,
• logs,
• changed files,
• optional PR link,
• any generated preview site.

The event stream is for immediacy. The database and object store are for history.

Why durable jobs beat direct execution

Direct execution is tempting for the first prototype:

HTTP request in run agent HTTP response out

It breaks as soon as work outlives a request, a worker dies, or provisioning takes longer than a proxy timeout. Durable jobs make failure visible. A leased job can be retried. A dead worker can be noticed. A task can show "running" even when the user closes the tab.

The security boundary

Agent tasks touch source code, credentials, and shell commands. The worker should receive only what it needs for that task. Logs should be redacted before surfacing. The execution environment should have a lifecycle that can be torn down.

This is also why app.nz keeps agent execution separate from the main web process. The API server coordinates. Workers execute.

The engineering shape

The architecture is boring on purpose:

create task row enqueue worker job worker leases job worker runs agent in sandbox worker streams events worker stores artifacts task becomes done or failed

Most agent platforms fail in the gaps between those arrows. app.nz's job is to make each gap observable and recoverable.