Reopening work an AI agent already closed

Reopening work an AI agent already closed is the right move when new evidence shows the task's own acceptance criterion is not actually met: a failing check, a bug traced to the change, or a review that finds the work incomplete. The tempting alternative is a quiet fix inside some other task. It works in the short term and corrupts the record: the original task still says DONE, its evidence still looks valid, and anyone asking later why the bug existed finds nothing. Completion is a decision made on the evidence available at the time. When the evidence changes, the decision should be revisited in the open. This workflow covers when to reopen versus open new work, the steps for reopening with evidence, how to handle tasks that depended on the reopened one, and how to keep the history honest. For board states in general, see kanban for AI agents.

Reopen or create new work?

The test is the original acceptance criterion. If the work does not meet the criterion it was accepted against, reopen it. If the work meets its criterion but the criterion was incomplete, or the requirement has changed, create a new task and link it to the original.

Examples. A task said "CSV export rounds to the nearest cent" and the export now truncates: the criterion is not met, so reopen. A task said "add CSV export" and users now want a spreadsheet format too: new task. A task's check passed but a reviewer finds an unhandled error path the task explicitly listed: reopen. An agent fixed a bug and a different bug appears in the same file: new task, unless the second bug was caused by the fix, in which case reopen the fix.

When it is unclear, prefer reopening if the defect was introduced by the closed work. That keeps cause and correction together, which is what you will want when you later ask how often agent work needs a second pass.

What you should not do is fix it inside an unrelated task because that task's agent happens to be working nearby. The fix will be real, but it will be credited and reviewed as part of something else.

Steps for reopening with evidence

Step 1: capture the evidence before touching code. The failing command and its output, the revision it ran on, a reproduction or the bug report. Something another person could rerun.

Step 2: attach the evidence to the closed task, with a line saying why it reopens: "Export check row(1.235) == '124' fails with '123' on commit 7d3e9aa; criterion 'nearest-cent rounding' not met."

Step 3: move the task back to an active or to-do state. Do not delete or rewrite its earlier completion entry. The history should read: completed, then reopened with this evidence.

Step 4: decide who fixes it. The original session had context but also the original blind spot. A fresh session with the evidence in the task text is often better. Either way, the evidence becomes the new failing-first check, as in choosing proportionate checks.

Step 5: complete it again through the same gate, with the new check added to the required set, so the same defect cannot pass a second time unnoticed.

Step 6: if a different task caused the defect, link the two. The cause may need reopening too, as covered in when a fix breaks another feature.

Check what depended on the reopened task

A reopened task is a signal for everything downstream. Tasks that depended on it were unblocked on the assumption that it was done, and parent or delivery tasks may have been accepted on top of it.

Walk the dependents. For each, ask whether its own acceptance relied on the reopened behavior. If yes, move it back to verification and rerun its checks once the fix lands. If no, leave it, but note that you looked.

Do not assume your dependency records are complete. In a regression probe on a BRAIN FLUID development build (RC2, October 30, 2026), a shared money helper changed from rounding to truncation and broke a CSV export card that was already DONE. The declared-relationship impact query on that package nominated the checkout card and its parent but not the export card, because the export's import was never recorded, and it reported its coverage as incomplete [D6]. Nothing reopened the export card; that had to be a human decision. A repository search for the helper's name would have found the missing link.

Also check work that is not formally dependent but shares code. The method is in why narrow tests miss regressions.

Keeping the history honest

The point of reopening openly is a record you can learn from. A few rules keep it useful.

Never edit a past completion to make it look like it never happened. Append. A task that was completed, reopened and completed again tells a true story about how the work went.

Keep the reason short and factual. "Reopened: export rounding regression, evidence attached" is better than an essay or a line of blame.

Count reopenings. Over a month, the share of agent-completed tasks that were reopened is one of the more honest quality measures you have. It shows whether your checks are proportionate and whether the completion gate is doing its job. A rising count after a tooling or prompt change is worth investigating.

Distinguish reopen from revert. Reverting the commit may be the right fix, but the task is still reopened: its criterion is unmet until something meets it.

Treat DONE as revisable by design. A board where DONE is final encourages quiet fixes, because reopening feels like admitting failure. A board where reopening is normal gets problems reported when they are found, which is the only time they are cheap.

QUESTIONS

Should I reopen a closed ticket or create a new one for a bug?

Reopen when the closed work fails the acceptance criterion it was accepted against, especially if the closed change introduced the defect. Create a new ticket when the original criterion was met but was incomplete, or the requirement has changed. Link the two either way, so the cause and the correction can be found together.

Is it bad if AI agent work gets reopened often?

A few reopenings are normal and better than quiet fixes. A high or rising rate is a signal about your checks: completion is being accepted on evidence that does not cover the criterion. Look at what the reopened tasks had in common, such as shared code, missing failing-first tests or self-reported passes.

What should happen to dependent tasks when a task is reopened?

Review each dependent and ask whether its acceptance relied on the reopened behavior. If it did, move it back to verification and rerun its checks after the fix. Do not rely only on recorded dependencies, since undeclared imports are common; search the code for the changed functions as well.

RELATED GUIDES

• How to find and organize work across projects
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• kanban for AI agents Kanban for AI agents: the board states that matter when software does the work, including review, blocked and decision owed.
• My AI agent fixed one bug and broke another feature Your AI agent fixed one bug and broke another feature? Find the shared code, find its other consumers, rerun their checks and record it as linked work.
• Why narrow acceptance tests miss AI regressions Why narrow acceptance tests miss AI regressions: a task's check can pass while a shared change breaks another consumer. A worked example and a fix.
• Why a parent task can't be done before its children Why a parent task can't be done before its children: required versus related work, and why finishing a child changes eligibility, not status.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.