## TL;DR
Inconclusive is a verdict, not an absence of one: it means the service has no reputation for this URL, which for a fresh phishing link is the expected state. An agent that retries until certainty will loop forever. Define the policy up front: inconclusive plus other risk signals means quarantine and submit for detonation; inconclusive alone means tag, deliver with warning per your risk posture, record for later re-check, and move on. Re-check in a later pass when reputation may have formed.

```text
url-reputation API returned inconclusive mid-triage and the agent's verdict loop failed to converge
```

## Use this when
- The agent repeatedly queries the same URL awaiting a firm verdict.
- Runs end with a batch of URLs in a permanent undecided state.

## Not for this skill when
- The API is erroring, not returning inconclusive. Fix the integration error handling.
- The URL is confirmed malicious by another source. Act on that source.

## Steps
1. Log the distribution of API verdicts over a run to confirm inconclusive is a stable category in responses. Verify: the inconclusive rate and the affected URLs are known.
2. Write the decision rule for inconclusive into the agent policy, combining at least one more signal such as sender age, first-seen domain or message context. Verify: every inconclusive case now maps to an action.
3. Add a re-check queue: store inconclusive URLs with a timestamp and re-query them in a later run, applying any firmer verdict retroactively. Verify: re-checks happen without blocking the main sweep.
4. Submit persistently inconclusive campaign URLs for detonation to get a behavioural verdict instead. Verify: detonation is the escalation path, not more reputation polls.
5. Run the agent over the stalled batch. Verify: every URL resolves to an action and the run completes.

## Variant phrasings
### url reputation inconclusive unknown verdict agent policy
The inconclusive policy variant.
### agent verdict loop never converges unknown url
The convergence variant.

Compatibility: URL reputation APIs including VirusTotal and gateway feeds, agent decision policies.

## Why it happens
Reputation is backward-looking, and phishing URLs are born unknown. An agent designed as if every URL has a knowable score has no move for the most important case, so it stalls in the gap between its design and reality.

## Edge cases / pitfalls
- Cap reputation polls per URL per run at one. Anything more is waste disguised as diligence.
- Retroactive verdicts matter: when a re-check turns malicious, purge earlier deliveries automatically.
- Record inconclusive as its own metric. A rising rate often marks a new campaign before any vendor does.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3THSFv-of60n6QUrn8Y0qw