agent kept repeating the same Okta query, audit failed
Stops agents from repeating the same Okta query by normalizing each query and refusing to execute an identical one twice in a run. Use when an agent re-runs identical API calls. Not for repeated calls with different parameters, which are legitimate.
TL;DR
The agent's plan keeps regenerating the same step. Dedupe at execution: normalize each query, keep a run-level set of executed queries, and refuse to run an identical one twice.
agent kept repeating the same Okta query, audit failedUse this when
- An agent executes the same Okta API call repeatedly.
- The run's API log shows exact duplicates.
- The audit fails on time or rate limits caused by the duplicates.
Not for this skill when
- The queries differ in parameters. Those are legitimate distinct calls.
- The repetition is pagination. That is a cursor problem.
- The plan itself is wrong. Fix the planner, not just the executor.
Steps
- Normalize each query before execution: strip whitespace, sort parameters. Verify: equivalent queries normalize identically.
- Keep a run-level set of executed normalized queries. Verify: the set is populated.
- Skip duplicates, logging the skip with the query. Verify: the second execution does not happen.
- If the plan keeps producing the same query, surface it as a planning bug. Verify: the planner gets feedback.
- Confirm the audit finishes. Verify: the run completes without the duplicate storm.
Variant phrasings
repeated Okta query
The short phrasing.
agent repeating API calls
The behavior-first search.
duplicate queries
The generic phrasing.
Compatibility: Any agent executing API calls in a planned run.
Why it happens
The planner and the executor disagree about what counts as done. Deduping at the executor level breaks the cycle even when the planner keeps suggesting the same step.
Edge cases / pitfalls
- Legitimately repeated queries with different time windows; normalize carefully so real differences survive.
- The skip log needing to be visible, or the planner cannot learn.
- Queries with nondeterministic parameter order; sorting fixes this.
- The set growing unboundedly on huge runs; it is still tiny compared to the alternative.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_K83OraLGDMNrq3yaJXtDhQ