When an agent gets it wrong

Three different things go wrong, and they take opposite responses. Work out which one you have before you reach for a button.

The run broke

Something failed that has nothing to do with your code. Retry it. Completed work is kept, and the retry picks up from where it stopped.

If the same run breaks repeatedly in the same place, stop retrying. That is no longer a transient failure.

The agent stopped because something was ambiguous

This is the one people misread. An agent that halts has usually reached something it could not resolve and handed the turn back rather than inventing an answer and building everything else on it. That is the behavior you want.

Retrying the identical run is the least useful response, because nothing about the ambiguity has changed. Work out what was unclear, resolve it, and plan again.

Often the ambiguity is upstream. An initiative that comes out consistently confused is usually the symptom of a document that was published too early.

The run finished and the result is wrong

There is no error for this. From the system’s point of view nothing failed. It needs your judgment, and there is a clear order of preference.

Comment on the pull request first. Leave review comments and Taiga addresses them on the PR. This is the cheapest correction available: the branch, the completed work and the review thread all survive, and the agent has the specific thing you objected to in front of it. Prefer it to any restart.

Plan again when the shape is wrong. If the code does what the plan said and the plan was the wrong idea, no number of review comments will fix it. Replanning discards the implementation plan and starts a fresh one. Nothing is deleted: the set-aside run stays in your history, and an open pull request is left open for you to close or reuse.

Fix the intake when it happens twice. The third time you write the same review comment, the correction belongs in your instructions, at the scope where it is true. See Write intake agents can act on. This is the only response that stops the problem recurring.

Rejecting the work

Closing the pull request without merging is how you reject a build. It is a deliberate dead end: there is no resuming from it, and the forward path is a fresh run. If you only meant to pause, reopening the pull request restores the review.

Before you conclude the agent was wrong

An agent works from two things: your standing context, and whatever was produced before this step. Check both before blaming the run.

Was the constraint written down anywhere? A rule that lives only in a conversation is not standing context, and the agent did not ignore it so much as never see it.

Was the thing this was built on right? When output is consistently wrong, the fault is usually upstream of where you noticed it.