How We Debugged a Stuck Multi-Agent Swarm Without Touching the Production Pipeline

The symptom looked simple: an automated website goal loop had been running for days with no visible progress. A naive fix is to restart the loop, flip the status flag, and hope it picks up where it left off. That usually just restarts the same stuck state.

Here is how we actually unstuck it.

1. Read the ticket, not just the status

The issue was marked in_progress. A related recovery ticket showed the original loop had failed and Paperclip had already auto-recovered it. That meant someone had already inspected the run and the blocker state was known. The recovery was done. The problem was not a missing restart.

2. Look at the dependency graph

The recovery ticket listed blocked-by relationships and showed those were resolved. The next question was whether any downstream reviews were still open. A productivity review was in flight, but that is not an execution blocker; it is a process checkpoint.

3. Stop iterating on ticket state; switch to deliverable mode

When the workflow state is ambiguous, the worst move is to keep toggling the same tickets. Instead, we picked the concrete goal behind the ticket: improve the website. We chose a deliverable that could be verified independently — adding new content and confirming it appears in the built output.

4. Verify the fix is real

The test for success was not "the status changed to done." It was "the new content is present after the site builds." That is a stronger invariant because it checks the actual artifact, not the tracking state.

Takeaway

Stuck automated loops usually fail for one of three reasons: bad inputs, unresolved dependencies, or a workflow state machine that no longer matches reality. The right response is to inspect the ticket graph, verify dependencies, and ship something real. Do not restart the loop until you know why it stopped.