Let Your Agent Deploy. Tell It When to Stop.

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Deploying from the agent session is fast for one reason: the loop stays in one place. Push, build, read the log, change one thing, build again, with the reasoning that made the change still in the conversation. That same loop, left without limits, is how a failing deploy gets "fixed" by deleting the health check, skipping the test, widening a permission or inventing a secret.

The loop does not need a human at every step. It needs three reasons to stop and ask, and a short list of things a fix may never be. Written down once, they turn an agent that keeps trying into an agent that knows when trying has stopped helping.

Keep the loop in the session

The value of deploying from the conversation is that the failure and its cause are in the same place. The agent that wrote the migration reads the log that says it failed. Moving the deploy to a dashboard or a separate pipeline page splits them, and someone has to carry the context across by hand.

Two habits keep the loop honest. Poll the build state instead of narrating the wait. And when it fails, read the log before changing anything: the stage that stopped and the reason it gives decide the next change, not a guess about what probably went wrong.

Three reasons to stop and ask

An agent in a deploy loop should stop and ask a person in exactly three situations: the loop has stopped converging, the host refused something that is a person's decision to make, or the next step needs a value the agent cannot legitimately know. Everything else, including most failed builds, is the loop doing its job.

• The same failure, twice, after a change. One retry with a change is diagnosis. The same error after a second change means the loop is not converging, and a third attempt is guessing with more confidence.
• A refusal that is somebody's decision. A plan limit, a payment, deleting data, creating something billed, or making something public is not an obstacle to route around. The host said no to the agent so that a person would say yes.
• A value the agent would have to invent. A secret, a domain the customer owns, a credential for a third party. An agent can name what is missing; it must never fill it in with something plausible.

Before the very first deploy there is a fourth, simpler rule: tell the person who will be able to open the address. Exposure is a decision to make before a build, not to discover after one.

What a fix may never be

A deploy that passes because a check was weakened has not been fixed; the failure was hidden. The pattern is always the same: the agent optimises for the build turning green, and the cheapest path to green removes the thing that was telling the truth.

So name the forbidden fixes: removing or loosening a health check that proves the app answers, deleting or skipping a failing test, commenting out a migration, widening ports or outbound access, running as root, and putting a secret into the repository or the image. None of these is a small step; each is a change a person should approve.

A deploy loop block for your agent instructions

Paste it into the instructions file your agent reads. It does not depend on any particular host, and the report it ends on is written for whoever picks the project up next — often another agent session, which should not have to start from a guess.

DEPLOY LOOP
Loop: push -> build -> poll status (do not narrate the wait)
      -> on failure read the log -> one change -> build again
Stop and ask me when:
  - the same failure repeats after a change
  - the host refuses for a plan, a payment, a deletion,
    anything billed, or anything that becomes public
  - you need a value you cannot read: a secret, a domain, a credential
Never, to make a deploy pass:
  - remove or loosen a health check, a test or a migration
  - widen ports, permissions or outbound access
  - put a secret in the repository or the image
Before the first deploy, tell me who will be able to open the address.
At the end, report: commit deployed, address, what changed, what is still broken.

FAQ

Should an AI coding agent be allowed to deploy to production? Yes, when the loop has stop conditions and irreversible or billed actions need a person's explicit approval. The risk is not the deploy itself; it is an agent that keeps changing things to make a deploy pass.

How many times should an agent retry a failing build? Until it stops converging. A retry after a change the log justified is diagnosis. The same failure after a second change means the agent should stop, report what it tried, and ask.

Which deploy actions should always need a human? Deleting data, stopping a running application, spending money on a new service, making something public, and supplying credentials. Each is either irreversible, billed, or a decision about who can see or reach what.

How does aidrop.it keep a person in the loop? On aidrop.it, service_build refuses before a build is spent when a value the app reads was never stored, when the plan does not include the requested size, or when hosting is paused, and says why in a sentence the agent reads back. Stopping an application, deleting a database or a repository, and creating a billed backing service each take an explicit confirmed.