Reads the actual failure
The agent works from the build output and the state of the machine, not from a guess about what usually goes wrong. Its diagnosis is attached to the deployment that produced it.
Build agent
The build breaks at 2am. The agent has already read the log.
Most deployment failures are dull: a missing dependency, a wrong Node version, a permission on a directory. The agent recognises those and fixes them. When the fix is not something it is allowed to run unattended, it stops and asks.
Capabilities
Anything unrecognised waits for you
A command the allowlist does not recognise is classified destructive: it becomes a request rather than an action, and nothing runs until someone with the authority to say yes has read it and said it.
Commands are allowlisted, not filtered
The gate is an allowlist of operations that may run unattended, not a denylist of dangerous ones. A denylist loses to a base64 payload or an interpreter one-liner, so anything the allowlist does not recognise is escalated to a human rather than scanned and waved through.
Every action is written down
The proposal, who approved it, when, and what it produced are all recorded against the deployment. An approval that timed out is recorded too.
01
Why the approval gate is the product
An agent with a shell on your production box is a liability unless something stands between the two. That something is an allowlist: a small set of low-risk operations the agent may run on its own, and an explicit approval step for everything else. The decision is recorded against the deployment it belongs to.
We built the gate before we built the automation. A pending approval has a lifetime — it can be approved, declined, or it can expire — and each of those is a state the deployment can be resumed from. Nothing is left half-applied because someone closed the tab.
- Only allowlisted low-risk commands run unattended
- Anything unrecognised is escalated, not refused
- Approvals expire rather than hanging forever
- The decision and its outcome are recorded together
02
What it is good at, and what it is not
It is good at the failures that have one obvious cause and one obvious fix — a package that is not installed, a build step run in the wrong directory, a service that needs restarting after a config change. These are the failures that waste an evening for no intellectual reward.
It is not an engineer. It will not redesign your build, untangle a dependency conflict that needs a judgement call, or tell you that the architecture is the problem. When it cannot see a fix it says so and leaves the deployment failed, which is the correct outcome.
The complete product starts on Free.
Every plan includes every Deploy Bridge capability. Paid plans raise usage ceilings; they do not unlock this feature.