## TL;DR
The agent alternates tools because each one's failure looks like a cue to try the other, and neither failure is ever recorded. Replace the ping-pong with a scan plan: each phase, fast sweep then detail, runs once per subnet, records its outcome, and the agent only advances, never alternates.

```text
(agent alternates: masscan fails -> nmap fails -> masscan fails ... same subnet)
```

## Use this when
- The agent log shows nmap and masscan trading off against the same authorized subnet, each failing.
- No phase ever reports completion.

## Not for this skill when
- One tool works and the other is a deliberate fallback. That is a plan, not a loop.
- The subnet is out of scope. Stop entirely, do not replan.

## Steps
1. Confirm the alternation: list the last 10 scan commands in order. Verify: the pattern is A,B,A,B against the same target set.
2. Halt both and record each tool's last failure reason separately. Verify: the state now says "masscan failed" and "nmap failed" with reasons, instead of "not done".
3. Write the scan plan as an ordered phase list: phase 1 masscan sweep once, phase 2 nmap detail once, each with its own success criteria. Verify: the plan has no step that says "if failed, try the other tool".
4. Execute the plan strictly in order, marking each phase complete, partial, or failed with evidence. Verify: a failed phase does not re-trigger the other tool.
5. If both phases fail, escalate the subnet as unscannable with both error logs attached. Verify: the tester gets one clear escalation, not an infinite alternation.

## Variant phrasings
### agent alternates nmap masscan never finishes
The ping-pong phrasing.
### scan plan loops between two tools
The planner phrasing.
### agent fallback loop port scanning
The fallback-logic phrasing.

Compatibility: harness-level fix, any nmap and masscan versions.

## Why it happens
Fallback logic without memory is just a loop with extra steps. "If masscan fails, try nmap" is reasonable once; without recording that nmap already failed too, the rule fires forever in both directions.

## Edge cases / pitfalls
- Partial results are still results: a masscan run that covered half the subnet before dying should feed nmap a smaller target list, not trigger a full re-sweep.
- Time-box each phase. An unbounded phase 1 means phase 2 never starts even without a loop.
- Keep the raw logs from both tools: "unscannable" needs evidence, and the two failure modes together often diagnose the network problem.
- Review the fallback rules after the engagement; every "try the other tool" rule needs a memory of what was already tried.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZiB0KIAMhWXrVtvLCCE8lA