# Fix agent loop re-verifying an already verified domain

## TL;DR
The agent re-verifies because it never persists the verified state and the check runs on a schedule. Record the verification result with a timestamp, skip verified domains, and only re-check when something changes. Verification is a state, not a ritual.

## The error
```text
Agent loop detected
Re-verifying already verified domain, causing verification failure on rate limits.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=agent loop detected re-verifying already verified domain causing verification failure"
```

## Fix it

### Step 1: Stop the verification loop

```bash
Pause the scheduled verification job.
```

Expected: No more redundant checks.

### Step 2: Record the verified state

```bash
Store the domain, verification result, and timestamp durably.
```

Expected: The agent knows what is already verified.

### Step 3: Skip verified domains

```bash
Before verifying, check the stored state and skip when still valid.
```

Expected: Verified domains are not re-checked pointlessly.

### Step 4: Re-check only on change

```bash
Trigger re-verification on DNS changes or expiry, not on a timer.
```

Expected: Checks happen when they matter.

### Step 5: Resume and verify

```bash
Resume the job and watch it skip verified domains.
```

Expected: No redundant verifications and no rate-limit failures.

## When this applies

- Agents re-verify already verified domains
- Verification jobs hit rate limits
- You are building domain verification agents

## When it doesn't

- The domain never verifies (fix the DNS records)
- Verification state is lost (fix the state store)
- The provider requires periodic re-verification (honor their schedule)

## Compatibility

Domain verification flows generally.

## Variant phrasings

### agent re-verifying verified domain

Same loop. Persisted state plus skip logic fixes it.

### domain verification loop agent

Loops come from stateless schedules. Add state.

### verification failure rate limit agent

Rate-limit failures from redundant checks are self-inflicted. Stop the redundancy.

## Why it happens

Verification jobs that run on a cron with no memory re-check everything every time. Providers rate-limit verification attempts, so the redundant checks eventually fail and look like a real problem. The job needs to remember what it already proved.

## Edge cases

- Verification can legitimately expire; store the expiry and re-check only then
- DNS changes should invalidate the cached verification
- Log skip decisions so audits can see why a domain was not re-checked

## If it still fails

- Reproduce with a minimal run: one user, one file, one step.
- Read the agent's full trace, not just the final error; the failure is usually upstream.
- Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
- Reduce concurrency to one and see if the failure persists; races hide as flakes.
- If the run is business-critical, add a human checkpoint before the destructive steps.

## Prevention

- Checkpoint long runs so any failure resumes instead of restarting.
- Cap and back off every retry loop; unbounded retries are outages waiting to happen.
- Validate inputs at each pipeline stage; fail fast with clear errors.
- Log enough context per step that a timeout is diagnosable without rerunning.
- Give destructive steps a human checkpoint or a dry-run mode.

## Provenance

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