Thirteen tasks green, then "give up (Recommended)" on the one that needed understanding

An agentic coding loop worked through thirteen tasks of a fourteen-task plan to put pull request preview environments behind an Istio Ambient mesh, then stalled on the fourteenth and offered "give up" as the option labeled Recommended ^[1][2][3]. The thirteen that worked were edits; the fourteenth was verification, and that is the distinction operators should take out of the account.

The method, as the author describes it, was superpowers' subagent-driven development: one implementer subagent per task, one reviewer subagent to check the implementer, the human approving each boundary ^[2]. None of the first thirteen tasks was frictionless. There was an ArgoCD self-heal loop fighting istiod's webhook config, an exhausted sync retry limit, and a waypoint proxy quietly asking for ten times the CPU its namespace quota allowed ^[5]. All resolved, which is the pattern that stops you expecting the last one to behave differently ^[6]. Task 14 asked for proof rather than a change: open a real PR, send a request carrying `x-pr-lane: 1`, confirm it lands on the preview pod instead of the baseline one ^[4]. Every request went to baseline, header or no header, with no error on either side of the route ^[7].

The elimination that followed was not lazy. istio-cni's iptables REDIRECT rule was confirmed catching outbound packets inside the pod's network namespace, `nsenter` and all ^[8]. ztunnel's xDS config was correct, with the waypoint binding present at the Service level ^[9]. The waypoint was reachable, routes programmed, ready, and holding zero connections across three hours of its own logs ^[10]. Swapping the `use-waypoint` label between namespace and Service level changed nothing ^[11]. An upstream Istio issue with the same symptom turned out to have a different root cause, cross-namespace enrollment ^[12]. A host-side tcpdump catching traffic on ztunnel's own tunnel port looked for a while like proof the fault lived inside ztunnel's routing rather than upstream of it, a read the author says was wrong but not obviously wrong at 2 a.m. ^[13].

At 03:08 the agent tried a fix, watched the new packet capture contradict its own diagnosis, reported that the situation was worse than it had looked an hour earlier, and asked whether to keep going ^[14]. The author was asleep for forty-four minutes, then replied: continue ^[15]. At 04:01 it stopped asking. It reported that it had gone through nearly every known and documented possible cause, systematically, and ruled each out, then offered three options: wrap up and mark waypoint L7 routing a known limitation (Recommended); file upstream with Istio, unlikely to get a quick answer; or keep digging, with a success rate already falling and the problem possibly unsolvable ^[16]. Asked what specifically was blocking it, it said the feature's actual selling point, routing a live PR preview by request header through the mesh, was not something it could deliver ^[17]. Fifty-three minutes from self-contradiction to recommended surrender ^[19].

That is a well-formed report reaching the wrong conclusion. The author's own reading is the useful part: a careful, honest elimination of every path you can currently see is not the same as eliminating every path there is, and whatever anchored the investigation at hour one was still anchoring it at hour nine ^[18].

The intervention was not more grinding on the same thread. He dispatched a fresh Opus subagent to investigate independently, handed it the entire trail of hypotheses marked ruled-out or inconclusive, and instructed it not to inherit either party's read, and to redo any upstream verification step it suspected had been done wrong rather than take it on faith ^[20].

Worth watching in your own setup: whether the task list distinguishes tasks whose deliverable is a diff from tasks whose deliverable is evidence, and whether anything in the loop is allowed to invalidate a verification the loop already recorded as passing.