Your Agent Workflow Is Mostly Code and People

On October 3rd, my astro-coach agent attempted to resolve a production Supabase environment issue. The problem repeatedly triggered model usage limits, preventing a successful fix. The agent diagnosed the issue and suggested a specific action to attempt. The environment settings were baked into the application build, but there was a hang in the execution state.

The agent had no choice but to retry the fix until a model usage limit terminated the operation. After the incident, the agent still required a human to verify the login message and confirm whether users could log in. The agent's main contribution was making the decision to retry the operation. The agent workflow consists of software operations and human decisions, with the model determining some transitions.

In this case, the agent's loop involved invoking the code operation, losing visibility, and trying again. A hang in the execution state did not clarify whether the operation failed, completed without returning a response, or was still in progress. Repeating the command did not resolve this uncertainty; it could add another attempt with unclear relationships to the first.

The usage limit halted the activity without confirming production correctness. The handoffs in the workflow required specific inputs, records of the state, and the next owner. The weakest handoff was the interruption of execution, as the agent had incomplete information but could still initiate another production attempt. To improve the workflow, the environment bake should be a separate script that runs once, reports the build attempt, artifact, verification results, and final status, without exposing secret values.

The script should prevent duplicate work by using an operation identifier and provide honest reporting of uncertainty until the underlying build or deployment state is checked.