How the agent proposes a fix

The build agent is a failure-recovery path inside a tracked deployment, not a general chat interface or a process that rewrites source before any error exists. It becomes available after Deploy Bridge establishes SSH and has an active AI provider. When a later step throws an error, the runner records the error, asks the agent for one bounded remediation and either retries the same step after applying it or leaves the deployment failed. Without an active provider, with agent fixes disabled or at the team's period ceiling, the original failure proceeds without an invented fallback.

Context is assembled from the failing run

Diagnosis receives the run kind, failing step key and title, the error message, server distribution and package manager, available Docker version, and project stack, language and port where a project exists. It also includes the project directory, Docker network, supported database engines, prior agent interventions and recent output belonging to the failed step. The current Dockerfile, Compose file and environment template are attached with size bounds. Environment lines whose keys resemble credentials, tokens, passwords, DSNs, URLs or URIs have their values replaced before the template is sent to the model.

The response is a typed remediation

The model must return a JSON object conforming to the remediation schema. It supplies a diagnosis, confidence, action kind, short summary and the fields required by that action. Supported actions install host packages, replace a Dockerfile, Compose file or Nginx template, set environment entries, run one shell command, provision a supported database or abort. File edits must contain the complete replacement rather than a diff. Invalid shapes and incomplete payloads are rejected before recording an action. An abort is retained as an abandoned action and the deployment stops with the supplied explanation.

Narrow fixes are preferred by instruction

The diagnostic instruction asks for the smallest effective change. A Dockerfile correction is preferred to installing a host package, and a named package installation is preferred to an arbitrary command. It directs database connection failures towards sibling-container provisioning and tells the model to account for the application's bind address and declared port. It also supplies prior attempts so the model can avoid repeating a failed intervention. These are instructions to the model, not the security boundary. The returned proposal still passes deterministic payload checks and risk classification in application code before execution is considered.

Risk classification decides the next state

A proposal is classified as safe or destructive. The label is intentionally conservative: destructive includes changes outside the project's directory and operations that cannot be recognised as safe, not only explicit data deletion. Safe actions are recorded as applied and executed without a human decision. Destructive actions are recorded as awaiting approval, attached to the deployment and presented with diagnosis, summary and details. The deployment status changes to awaiting approval and the runner pauses. Classification occurs before remediation, so the model cannot make its own assertion of safety authoritative.

A successful edit persists beyond the retry

Dockerfile, Compose, Nginx and environment changes made by the agent are written back to the stored blueprint as agent-generated. A provisioned database is added to the blueprint's database declaration. This persistence prevents the next deployment from rediscovering exactly the same defect. The current remote file is also rewritten when the action needs to affect the paused run. After application, Deploy Bridge retries the same failed step and records whether that retry succeeded or failed. A successful remediation does not skip the rest of the deployment sequence or turn a later failure into success.

Recovery is bounded and observable

The implementation allows at most two agent attempts for one step and six interventions in one deployment. The plan's monthly agent-fix ceiling is checked before the model call and reserved atomically when the action record is created. An awaiting approval holds an attempt; rejection or abandonment releases it, while applied, approved and failed actions count as spent. The run page displays agent actions with their kind, diagnosis, summary, risk-driven status, details and outcome. Once the agent reaches a bound, cannot produce a valid remediation or sees an external cause it cannot solve, the correct terminal state is a failed deployment.

Diagnosis remains evidence, not certainty

A proposal is based on bounded log output and generated configuration, so it can be wrong even when the JSON is valid and confidence is high. The safety gate constrains what may execute unattended; it does not prove that a change will repair the application. The retry is the operational test. Review the action history alongside the step logs, especially where one fix changes the blueprint used by later releases. If the agent aborts on a compile error, missing paid credential or inaccessible private registry, correct that external input and start a new deployment rather than treating the absence of a fix as an agent malfunction.