Agent lifecycle
An agent's runtime, its issue and the application's deployment each have their own progress. Read them together: “agent stopped” does not mean “issue done,” and “change merged” does not mean “application updated.”
From queued work to a running session
The following stages describe the workflow rather than a single API enum.
| Stage | What it means | What to check |
|---|---|---|
| Queued | Work is recorded but execution has not started | Dependencies, approval, pause policy and capacity |
| Assigned | A worker or slot has been selected | Assignment identity and target workspace |
| Starting | The runtime accepted startup and is preparing the session | Readiness rather than the acknowledgement alone |
| Working | The agent is inspecting, editing or verifying | Conversation, tool activity and current diff |
| Waiting | Progress depends on a check, decision or external condition | The specific dependency and who can resolve it |
| Delivering | Reviewed work is moving through publication and deployment | Approved revision and current delivery stage |
| Finished | The run ended | Issue acceptance and remaining delivery work |
Starting an assigned slot through REST is asynchronous. The response contains a command id and a provisioning status. It acknowledges the request before the agent is ready, and does not allocate additional capacity. The REST control guide provides exact request examples and the supported readiness surfaces.
Continue or redirect work
Send a follow-up in the existing session when its context still applies. Name the issue, correction and expected result: “Keep the current schema; fix duplicate handling in the transform and rerun its focused test.” Record a material scope change on the issue too, so a later session inherits it.
When delegating, give each helper an independent responsibility and an explicit completion condition. The coordinating agent must review and integrate the results. Multiple agents editing the same files without coordination increases conflict risk and can erase the expected benefit of parallel work.
Stop, pause and recover
Pausing a workstream gates new assignments. Stopping an assigned agent requests termination of that runtime and is asynchronous. Neither action rolls back an already published application change. Confirm termination before assigning a replacement writer to the same work.
A persistent workspace and recorded conversation support resuming interrupted work. A replacement process still needs to inspect what was saved: issue context, local changes, commits, checks and any delivery already attempted. Persistence does not imply that every process or model context continues unchanged.
Finish against the issue's acceptance
For a fully managed application change, the evidence chain normally includes the reviewed diff, required checks, publication/deployment status and a bounded application request at the intended revision. Redgold operates those delivery steps within the configured approval policy; the customer evaluates whether the result meets the objective.
For work on an externally hosted repository, completion follows that repository's agreed scope and CI/release process. Record that boundary explicitly instead of reporting an external merge as a Redgold-managed deployment.
Continue with supervision and recovery for deciding what to do when these stages stop advancing.