Agent work and durable state
Maintaining a managed application involves two kinds of state: the application's records and the work used to change its behavior. Redgold keeps issues, conversation history and delivery evidence so a change can be understood beyond one agent session.
From objective to execution
A workstream groups an application objective and its issues. An issue carries a bounded change, dependencies and acceptance criteria. An assigned agent works in a repository workspace, reads the relevant context, edits the application contract and records verification evidence. Fleet capacity and scheduling policy determine when eligible work can start.
flowchart LR
Work[Workstream objective] --> Issue[Issue and acceptance criteria]
Issue --> Run[Assigned agent run]
Run --> Workspace[Repository workspace]
Run --> History[Conversation and tool history]
Workspace --> Review[Diff and checks]
Review --> Delivery[Managed publication and verification]
Delivery --> Issue
The agent runtime and the application runtime serve different purposes. An agent workspace is where a change is authored. The deployed pipeline executor serves application requests. Closing an authoring session is not an application shutdown; starting an agent is not an application deployment.
What survives, and where
| State | Durable record or boundary | Recovery implication |
|---|---|---|
| Objective and acceptance | Workstream, issue and comments | Another run can recover the task's purpose |
| Source changes | Workspace checkout and Git commits | Inspect local edits and the recorded revision before continuing |
| Conversation and tool activity | Persisted session history | Recover prior evidence; do not assume identical model replay |
| Current process | Agent runtime | A restarted process may need a fresh session and context |
| Intended release | Reviewed Git change and published artifacts | Identify what was approved |
| Running release | Deployment and verification evidence | Confirm what actually reached users |
| Application data | Managed datasets | Independent of the authoring session's lifetime |
Persistent workspace storage supports continuity across sessions. It does not make every terminal process or in-memory context durable. Before recovering an interrupted run, inspect the issue, workspace diff, commit and latest check result. Avoid starting a second writer while the original assignment may still be active.
Coordination and authority
A proposed workstream can hold issues before its human approval. Automatic scheduling checks the workstream root's approval and pause policy, together with issue eligibility and capacity. Adding an issue does not prove it was dispatched; a dispatch acknowledgement does not prove the agent has started.
Application permissions, repository permissions and approval decisions remain separate from task instructions. A prompt to connect an external system cannot grant credentials or tenant access. Redgold supplies the managed execution environment; the configured account policy determines which actions it may take.
Recovery follows the last verified boundary
If tests failed, resume from the failure and changed files. If a change merged but publication failed, recover delivery for the approved revision. If deployment succeeded but the smoke request failed, investigate the running contract and application data. Repeating the whole task can create duplicate edits or writes.
For externally hosted repositories, the same work records can lead to an external pull request and that repository's checks. Its hosting and release policy remain with the configured external system. See agent lifecycle and supervision and recovery for the customer workflow.