Loop guard trips on legitimate repeated job_poll while a detached job runs

[ajianaz]

Context

tole run mission that included a ~14-minute render as a detached job (job_start). The agent polled correctly with job_poll (same job id, same arguments) while the job ran. The loop guard aborted the session:

tole: loop detected — tool `job_poll` called with identical input 3 times in a row (guard trips at 3); resume with: tole resume s-…

The loop guard treats identical consecutive input as a stuck model, but for polling tools identical input is the correct calling pattern: the arguments are the same because they reference the same job; the expected change is in the result (job still running → progress → done).

Impact

Any long-running detached job (renders, builds, test suites) longer than ~3 poll intervals causes the agent turn to abort mid-mission, even though everything was working as designed.

Suggested fix

• Exempt job_poll from the loop guard (or give poll-style tools a higher/looser trip threshold), OR
• Base the guard on consecutive identical results rather than identical inputs (a poll that keeps returning "still running" with progress info is not a loop), OR
• Make the threshold configurable per tool risk class.

Evidence

Session s-1a0b20ae866-42f8 (/tmp/vetio-tole-test/tole-sessions/): mission aborted at the 3rd job_poll while the render job j-1a0b20febe8-42f8 was still progressing normally (job log advanced 300/1599 → 1599/1599 frames after the abort; the detached job finished fine, the agent just could not stay attached to report it).